2

サイトを最適化するために MySQLTuner.pl を使用していますが、これらの問題のいくつかを解決する方法が完全にはわかりません。

次の MySQL 設定で MySQL に必要な場合は、約 4 GB の RAM を無料で使用できます。

key_buffer      = 100M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 800

myisam-recover         = BACKUP
max_connections        = 750
table_cache            = 125000
thread_concurrency     = 500

query_cache_type=1
query_cache_limit = 128M
query_cache_size        = 128M

tmp_table_size = 300M
max_heap_table_size = 300M
innodb_buffer_pool_size = 2G
innodb_file_per_table = 0
innodb_flush_log_at_trx_commit = 2

これが私のチューナーの出力です

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.24-0ubuntu0.12.04.1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 7K (Tables: 10)
[--] Data in InnoDB tables: 27M (Tables: 5)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 5

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 15d 5h 4m 19s (1B q [1K qps], 208M conn, TX: 172B, RX: 98B)
[--] Reads / Writes: 71% / 29%
[--] Total buffers: 2.5G global + 2.7M per thread (750 max threads)
[OK] Maximum possible memory usage: 4.5G (57% of installed RAM)
[OK] Slow queries: 0% (0/1B)
[OK] Highest usage of available connections: 15% (118/750)
[OK] Key buffer size / total MyISAM indexes: 100.0M/119.0K
[OK] Key buffer hit rate: 100.0% (22M cached / 0 reads)
[!!] Query cache efficiency: 0.1% (703K cached / 519M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (13 temp sorts / 13M sorts)
[OK] Temporary tables created on disk: 25% (4M on disk / 18M total)
[OK] Thread cache hit rate: 99% (752 created / 208M connections)
[OK] Table cache hit rate: 74% (992 open / 1K opened)
[OK] Open file limit used: 0% (68/250K)
[OK] Table locks acquired immediately: 100% (216M immediate / 216M locks)
[OK] InnoDB data size / buffer pool: 27.8M/2.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
Variables to adjust:
query_cache_limit (> 128M, or use smaller result sets)

の出力SHOW STATUS LIKE '%cache%'

Binlog_cache_disk_use   0
Binlog_cache_use    0
Binlog_stmt_cache_disk_use  0
Binlog_stmt_cache_use   0
Com_assign_to_keycache  0
Qcache_free_blocks  19
Qcache_free_memory  134026728
Qcache_hits 704192
Qcache_inserts  143569852
Qcache_lowmem_prunes    0
Qcache_not_cached   11043040
Qcache_queries_in_cache 94
Qcache_total_blocks 217
Ssl_callback_cache_hits 0
Ssl_session_cache_hits  0
Ssl_session_cache_misses    0
Ssl_session_cache_mode  NONE
Ssl_session_cache_overflows 0
Ssl_session_cache_size  0
Ssl_session_cache_timeouts  0
Ssl_used_session_cache_entries  0
Threads_cached  748

パフォーマンスを向上させるために改善できることはありますか?

ありがとうございました

4

1 に答える 1

1

「クエリキャッシュ効率:0.1%(703Kキャッシュ/ 519M選択)」は、キャッシュの有効期間サイクル内に繰り返しクエリがないことを意味します。

これは、次の3つの要因が原因である可能性があります。キャッシュの有効期間が小さすぎて繰り返し表示できないか、クエリが大きすぎるか異なるためキャッシュできません。

たとえば、一部のフレームワークは大規模な実行をSELECT行い、サーバー側で「フィルタリング」します(サーバー側でキャッシュする場合もあります)。MySQLが認識しているのは、キャッシュされていない場合に最適と見なされる可能性のある大きなクエリであり、MySQLの効率は低下しますが、全体的な効率は同じままです。

または、多数の異なるクライアントがあり、それらのすべてがカスタムデータ(メッセージテーブルの内容など)を使用してクエリを実行している場合があります。1000人の顧客がいて、それぞれが1メガバイトを占めており、すべての顧客が1分ごとにメッセージをチェックしている場合、このカテゴリのクエリ専用の1ギガバイトがあると、1時間あたり1,000回のミスと5万9千回のヒットが発生します。ただし、999メガバイトしかない場合、最後のクライアントが最初のクライアントをキャッシュからフラッシュし、最初のクライアントが再び来てミスを取得し、2番目のクライアントをフラッシュします。その同じ1時間で、6万回のミスが発生し、効率が98%から0%に低下します。

したがって、まず最初に、実行しているクエリをしっかりと確認する必要があります。おそらく、それらのいくつかはキャッシュに関して最適化できます。1つの大きなクエリが2回実行され、2つの大きなクエリの代わりに2つの改良が行われ、最初のクエリがキャッシュされます。ただし、将来の効率を犠牲にしてこれを行う可能性があることに注意してください。

あなたの他の結果から、これは事実であるように思われます。たくさんの挿入、たくさんの空きクエリキャッシュメモリがありますが、ヒットはほとんどありません。したがって、明らかにすべてのクエリは互いに異なります。この状況では、クエリキャッシュメモリを減らして、他の目的のためにメモリを解放する必要があります。ヒット数がさらに減少した場合でも、アムダールの法則により、クエリ関連のパフォーマンスはそれほど関連性がなくなります(0.01%の50%を失うと、全体で0.005%を失うことになります。その「50%の損失!」を怖がらせないでください。君)。

Qcache_free_memory  134,026,728
Qcache_hits             704,192
Qcache_inserts      143,569,852

確かに害を及ぼすことができないのは、どのクエリがおそらく価値がないかを確認することであり、それらは。でアップグレードできますSQL_NO_CACHE。それらは依然としてキャッシュミスになりますが、他のクエリのパフォーマンスを低下させることはありません。これにより、より多くのメモリが見つかり、パフォーマンスが向上する可能性があります。これはとにかくコストがかからないので、いつでも実行できます(もちろん、トラブルに見合うだけの大きさのクエリの場合)。

これを行った後、query_cache_sizeパラメーターを試すことができます。他のコンポーネントが使用しているメモリの量と、ファイルシステムキャッシュのパフォーマンスを確認してください。ビューとコントローラーコンポーネントの取得でページが首にかかっているため、クエリを高速化してページが2倍の時間で表示されるのを確認したくありません。

あなたが見たいと思うかもしれないもう一つのことはインデックスです。遅いクエリ制限を下げて、他のクエリよりも大幅に遅いクエリがあるかどうかを確認し、クエリプランを調べてその理由を確認できます。

于 2012-09-13T09:34:05.557 に答える