最近、メモリ不足が原因でスラッシングの問題が発生しています。 (私のVPSは合計256Mです)
Mysqltuner.plを使用してMySQLを調整しようとしています。次の結果が得られます。
---------一般統計----------------------------------- --------------- [-] MySQLTunerスクリプトのバージョンチェックをスキップしました [OK]現在サポートされているMySQLバージョン5.0.51a-3ubuntu5.4を実行しています-log [OK] 64ビットアーキテクチャで動作しています --------ストレージエンジンの統計情報------------- ------------------------------ [-]ステータス:+ Archive -BDB -Federated -InnoDB- ISAM -NDBCluster [-] MyISAMテーブルのデータ:114M(テーブル:454) [!!]断片化されたテーブルの合計:34 --- -----パフォーマンスメトリクス------------------------------------------- ------ [-]最大:40秒(570 q [14.250 qps]、23接続、TX:154K、RX:23K) [-]読み取り/書き込み:100%/ 0% [-]合計バッファ:338.0Mグローバル+ 2.7M /スレッド(最大20スレッド) [!!]可能な最大メモリ使用量:392.9M(153%搭載RAMの容量) [OK]クエリが遅い:0%(5/570) [OK]利用可能な接続の最大使用量:15%(3/20) [! !]キーバフサイズ/ MyISAMインデックスの合計:8.0M/9.4M [!!]キーバッファーヒット率:57.1%(7キャッシュ/ 3読み取り) [OK]クエリキャッシュ効率:21.9%( 7キャッシュ/ 32選択) [OK] 1日あたりのクエリキャッシュプルーン:0 [OK]一時テーブルを必要とするソート:0%(0一時ソート/ 1ソート) [ OK]ディスク上に作成された一時テーブル:0%(ディスク上0 /合計32) [OK]スレッドキャッシュヒット率:86%(3つ作成/ 23接続) [OK]テーブルキャッシュヒット率:26%(128オープン/ 484オープン) [OK]使用されるオープンファイルの制限:25%(259/1K) [OK]すぐに取得されるテーブルロック:100%(492即時/ 492ロック) --------推奨事項--------------------------- -------------------------- 一般的な推奨事項: OPTIMIZE TABLEを実行してテーブルを最適化し、パフォーマンスを向上させます MySQLは過去24時間以内に開始されました-推奨が不正確な場合があります システムの安定性のために全体的なMySQLメモリフットプリントを削減します 調整する変数:[.__ __。] *** MySQLの最大メモリ使用量が非常に高い*** *** MySQLバッファ変数を増やす前にRAMを追加*** key_buffer_size( > 9.4M)
しかし、私は最大のメモリ使用量を下げる方法について少し混乱していますか? key_bufferとmax_connectionsに基づいているようですが、他にも何か関与している必要がありますか?
my.cnf:
key_buffer = 8M max_allowed_packet = 12M thread_stack = 128K thread_cache_size = 8 max_connections = 20 table_cache = 128 tmp_table_size = 256M max_heap_table_size = 256M join_buffer_size = 256K query_cache_limit = 8M query_cache_size = 64M
私はMySQLのチューニングに関する記事を読み通すように努めてきましたが、彼らはすでに何をしているのかを知っている人を対象としています。任意の助けいただければ幸いです。ありがとう!
256Mのサーバーがありますが、それをすべて使用することはできません。OSのオーバーヘッドが多少あることに注意してください。これに加えて、他の人々が言及しているように、あなたはコミットし過ぎているので、あなたは間違いなくここに打ち込むでしょう。 256Mは小規模なDBにのみ十分であり、20接続は設定した内容で多くなります。
1)最大接続数を4に減らします(20のうち3を使用しています)
2)クエリキャッシュをより最適化します。 8Mは非常に大きく、合計64Mはヒット/プルーンに基づいて多くなります。 4/32コンボを試してみて、どうなるか見てみましょう。本当に私は2/24コンボがうまくいくと思います。
3)一時テーブルを必要とする並べ替えがない場合、そのmax_heap_table_size動詞がそこにあるのはなぜですか?コメントアウト、デフォルトを使用
4)実際に128のテーブルがありますか?そのtable_cacheを半分に64または48にカットしてみてください
5)thread_cache_sizeを4に減らします
6)これらのテーブルを最適化して断片化を減らす
これらは、最初にいくつかのことです。何が必要かを知るための実際のプロファイリングを行わずに設定に多数の数字を投げ、混乱を引き起こしたようです。他のすべてが失敗した場合は、デフォルトに戻ってカスタム設定を削除し、Googleで見つけることができるいくつかのパフォーマンスチューニングガイドを使用してやり直してください。 SHOW VARIABLESとSHOW STATUSの出力を取得し、膨大なチューニングガイドのいずれかを見つけて、実際の実際の数値を方程式に代入すると、構成ファイルに入力する必要がある正確な数字がわかります。
私はMySQLの第一人者ではないため、この情報で問題を診断することはできませんが、ソースコードで式を検索してみました。ここにあります:
server_buffers + total_per_thread_buffers * max_connections
どこ:
server_buffers = key_buffer_size + innodb_buffer_pool_size + innodb_additional_mem_pool_size + innodb_log_buffer_size + query_cache_size
そして:
total_per_thread_buffers = read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + max_allowed_packet + join_buffer_size
次に、これらの各値をチェックして、この膨大な数の原因となっている値を特定する必要があります。そして、このスクリプトを無条件に信頼しないでください-私は自分のDBサーバーの1つでスクリプトを実行してみましたが、最大メモリは物理メモリの総量の140%であると計算されましたが、システムは何年も実行されており、安定性の問題はありません。
幸運を!
私が正しく覚えている場合、MySQL Tunerは次の式を使用して最大使用量を推定します。
read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack + join_buffer_size
MySQLの特定の設定には制限が定義されていないため、これは100%正確ではなく、実際には単なる推定であることに注意してください。
設定ファイルの一部の設定を徐々に下げてチューナーを再度実行することもできますが、my.cnfの変更、再起動してチューナーを実行することに時間を費やす余裕がない場合は、専門家の助けを借りることをお勧めします。
Mysqlcalculator.comソフトウェアを使用すると、多くの時間を節約できます。