1

バックグラウンド：

約 60 GB の大きなフラット ファイルがあり、データベースに挿入しています。挿入中にパフォーマンスが徐々に低下しています。

  • 1 億 7,400 万のレコードがあり、さらに 5,000 万のレコードが挿入されると予想されます
  • エンティティ名の最初の 2 文字 (entity_aa、entity_ab ... entity_zz など) に基づいて、メイン テーブルを 1000 以上のテーブルに分割しました。
  • 各挿入中に、3 つのクエリが実行されます (a) 別のテーブルへの範囲ベースの検索、(b) レコードが既に挿入されているかどうかの確認、(c) 詳細 (entity_briefs) テーブルへの挿入
  • 頻繁な検索クエリを処理するために entity_briefs を追加しましたが、データベースに挿入すると、ALTER TABLE エンティティ (または entity_briefs) DISABLE (または ENABLE) KEY に関係なく、徐々に遅くなることに気付きました。
  • マシンには 4 つの CPU、ギグのディスク容量、2GB の RAM があります。オペレーティング システムは Linux CentOS (5.4) 32 ビットです。
  • 4 つの CPU がすべて使用されているわけではないことがわかりました
  • 一度に 4 つのインポート スクリプトを実行しましたが、全体的なパフォーマンスは満足のいくものではありません

問題のあるテーブル

CREATE TABLE `entity_briefs` (
`entity_brief_id` bigint(11) NOT NULL auto_increment,
`entity_id` bigint(11) default NULL,
`entity_table_prefix` char(2) default NULL,
`string_1` varchar(255) default NULL,
`string_2` varchar(255) default NULL,
`zip` varchar(25) default NULL,
`phone` bigint(11) default NULL,
PRIMARY KEY  (`entity_brief_id`),
KEY `idx_entity_id` (`entity_id`),
KEY `idx_entity_table_prefix` (`entity_table_prefix`),
KEY `idx_zip` (`zip`),
KEY `idx_string_1` (`string_1`),
KEY `idx_string_2` (`string_2`),
KEY `idx_phone` (`phone`)
);

mysqltuner.pl 出力:

 >>  MySQLTuner 1.1.1 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: xxxxx
Please enter your MySQL administrative password:xxxxx

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.85-community
[OK] Operating on 32-bit architecture with less than 2GB RAM

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 101M (Tables: 1344)
[!!] InnoDB is enabled but isn't being used
[!!] Total fragmented tables: 1

-------- Security Recommendations  -------------------------------------------
ERROR 1142 (42000) at line 1: SELECT command denied to user 'xxxx'@'localhost' for table 'user'
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 5d 15h 53m 55s (2M q [4.395 qps], 9K conn, TX: 1B, RX: 425M)
[--] Reads / Writes: 51% / 49%
[--] Total buffers: 34.0M global + 2.7M per thread (500 max threads)
[OK] Maximum possible memory usage: 1.3G (67% of installed RAM)
[OK] Slow queries: 0% (9/2M)
[OK] Highest usage of available connections: 1% (5/500)
[!!] Key buffer size / total MyISAM indexes: 8.0M/105.3M
[!!] Key buffer hit rate: 94.1% (72M cached / 4M reads)
[!!] Query cache is disabled
[OK] Temporary tables created on disk: 7% (101 on disk / 1K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 277K opened)
[OK] Open file limit used: 0% (127/18K)
[OK] Table locks acquired immediately: 99% (2M immediate / 2M locks)
[!!] Connections aborted: 38%

-------- Recommendations -----------------------------------------------------
General recommendations:
    Add skip-innodb to MySQL configuration to disable InnoDB
    Run OPTIMIZE TABLE to defragment tables for better performance
    Enable the slow query log to troubleshoot bad queries
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
    Your applications are not closing MySQL connections properly
Variables to adjust:
    key_buffer_size (> 105.3M)
    query_cache_size (>= 8M)
    thread_cache_size (start at 4)
    table_cache (> 64)

要件: 挿入を高速化するには、どの最適化戦略を使用できますか?

4

1 に答える 1

3

私はあなたのための特効薬を持っていないので、いくつかの一般的な提案：

テーブルのサイズが大きくなっても、挿入時に速度がまったく低下しないことは期待できないと思います。データベースの挿入時間は通常、データベースのサイズに応じて変化します。この期待を踏まえて、全体的なパフォーマンスを許容できるものにするのがコツです。

処理速度が低下し、CPUが固定されていない場合は、データベースアクセスにI/Oバウンドがかかっている可能性があります。これが当てはまる場合は、より高速なドライブ、RAID 0、より高速なドライブコントローラーなどを試してみてください。ソリッドステートドライブにデータベースを構築し、作成後に従来のハードにコピーすることを検討することもできます。ドライブ。これらは、ファイルシステム上のmysqlから期待できるランダムアクセスの動作に対してはるかに高速であるはずですが、時間の経過とともに「使い古される」ことは理解しています。それでも、1万ドル未満で1テラバイトのソリッドステートストレージを入手できます。

また、挿入手順の最適化もよく見てください。あなたが言及したように挿入中にインデックスを無効にすると、徐々に遅くなるのを止めることはできませんが、全体的な手順を大幅にスピードアップするはずです。あなたの説明から、フラットファイルの単純なロードではなく、選択と挿入を行うある種の挿入スクリプトロジックがあることがわかります。挿入ごとに3つの異なるクエリを実行しており、クライアントとデータベース間でデータを複数回ラウンドトリップする可能性があります。特にその範囲選択を見て、このクエリだけでテーブルサイズに悪いパフォーマンス特性がないことを確認してください。

別の可能性は、問題でより多くのRAMをスローし、それをディスクキャッシュとして使用することです。それらの範囲が選択する「他のテーブル」がinsertfest中に変更されていない場合、シーク時間が実際にここで制限されるパフォーマンスであると判断した場合は、ドライブシークを削減するためにメモリ内でそれを取得できます。

于 2010-02-05T03:45:32.887 に答える