(私をバカと呼んだり笑ったりする前に、それは私の側の本当の取引であり、より大きなプロジェクトの一部であるため、この割り当てをキャンセルできないことを覚えておいてください)
私は、サイズが非常に大きく、非常に小さいサーバーで実行されているデータベースサーバーを持っています。 32GB RAM、24コア。週末には、パフォーマンスを整理するまで、18GBのRAMをマシンに追加して、マシンの能力を少し高めます(日中のサーバー負荷は平均80に跳ね上がります!!)。このデータベースを使用するアプリケーションの問題。
空き容量がないため、DBがスワップしていることが原因であると思われますRAM(SWAPでは常に約5GB)。
このデータベースには、複数の小さなテーブルと1つの大きなテーブルがあり、GPSとIOデータの速度は約350,000レコード/時間であり、このテーブルはパーティション/月で分割されています。
Mysqltunerは、すべてのテーブルでoptimizeテーブルを実行することを提案していますが、InnoDBテーブルで実行することは役に立たず、また長い時間がかかることを読みました。
スクリプト出力からの抜粋は次のとおりです。
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Reduce your overall MySQL memory footprint for system stability
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
query_cache_limit (> 16M, or use smaller result sets)
join_buffer_size (> 2.0M, or always use indexes with joins)
tmp_table_size (> 16M)
max_heap_table_size (> 16M)
table_cache (> 4096)
innodb_buffer_pool_size (>= 1726G)
私は盲目的にそれを信頼するべきですか、それともこれを行う別の方法がありますか?
最初にアップグレード後にDBを再構成することですが、他に何を知っておく必要があり、何を試す必要がありますか?ダウンタイムは常に可能な限り短くする必要があるため、5時間連続で実行されるクエリを実行したくありません。
Mysqltunerを忘れて、人間のアドバイスを確認してください。このツールは、役に立たない、場合によっては害を及ぼす可能性のある一般的な推奨事項を示します。最適化テーブルはおそらく役に立たないでしょうが、書き込みのためにテーブルをロックします。コンサルタントは、長期的には時間とお金を節約することができます。
MySQLではスワッピングは不要です。 innodb_buffer_pool_sizeを調整して、スワップせずにメモリ使用量を最大化してください。メモリを使用している他のものがある可能性があることを理解してください:ファイルシステムキャッシュ、ロギングやその他の操作に必要、およびクライアントごとに、結合バッファやソートバッファなどのメモリを使用しました。 MySQL/InnoDBは独自のバッファリング方法を実行するため、全体として使用可能な物理メモリよりも少なくする必要があります。実際にはディスク上にある仮想メモリを使用すると、問題が発生します。
サーバーの完全なレビューなしに、絶対確実な「一般的なアドバイス」を提供することは困難です。しかし、私の経験では、問題の90%は、サーバー構成ではなく、クエリとデータベース設計にあります。
ただし、ここには、優れた人間(Peter Zaitsev)によるMySQL/Innodb構成最適化の優れた入門書があります。それが役に立てば幸い。