MySQLのクラッシュ、oom-killer、メモリ不足、チューニングの問題？
すべてのWebサイトを4GB RAMの新しいサーバーに移動しました。すぐにmysqlがクラッシュし始め、ある時点で再起動せず、大きな停止が発生しました（誰かが指摘するまで気づかなかったため）。
以下は、CRONジョブが削除されたログです。 http://Pastebin.com/9SAUBcFp （Apache2がoom-killerを呼び出した、メモリ不足エラーなど）
df -hの4％を超えるものはありません。
これがfree -mの出力です
total used free shared buffers cached
Mem: 4002 2090 1911 0 168 1015
-/+ buffers/cache: 906 3095
Swap: 255 8 247
Mysqlreportの出力は次のとおりです
__ Key _________________________________________________________________
Buffer used 849.00k of 16.00M %Used: 5.18
Current 2.99M %Usage: 18.71
Write hit 44.87%
Read hit 98.84%
__ Questions ___________________________________________________________
Total 198.55k 33.8/s
QC Hits 147.94k 25.1/s %Total: 74.51
DMS 31.35k 5.3/s 15.79
Com_ 14.20k 2.4/s 7.15
COM_QUIT 5.07k 0.9/s 2.55
-Unknown 9 0.0/s 0.00
Slow 2 s 0 0/s 0.00 %DMS: 0.00 Log: ON
DMS 31.35k 5.3/s 15.79
SELECT 27.65k 4.7/s 13.93 88.19
UPDATE 1.78k 0.3/s 0.89 5.66
INSERT 1.73k 0.3/s 0.87 5.51
DELETE 199 0.0/s 0.10 0.63
REPLACE 0 0/s 0.00 0.00
Com_ 14.20k 2.4/s 7.15
set_option 9.29k 1.6/s 4.68
change_db 4.63k 0.8/s 2.33
show_tables 260 0.0/s 0.13
__ SELECT and Sort _____________________________________________________
Scan 850 0.1/s %SELECT: 3.07
Range 398 0.1/s 1.44
Full join 0 0/s 0.00
Range check 0 0/s 0.00
Full rng join 0 0/s 0.00
Sort scan 1.01k 0.2/s
Sort range 361 0.1/s
Sort mrg pass 0 0/s
__ Query Cache _________________________________________________________
Memory usage 15.09M of 16.00M %Used: 94.30
Block Fragmnt 2.31%
Hits 147.94k 25.1/s
Inserts 21.70k 3.7/s
Insrt:Prune 2.86:1 2.4/s
Hit:Insert 6.82:1
__ Table Locks _________________________________________________________
Waited 0 0/s %Total: 0.00
Immediate 35.51k 6.0/s
__ Tables ______________________________________________________________
Open 400 of 400 %Cache: 100.00
Opened 5.55k 0.9/s
__ Connections _________________________________________________________
Max used 9 of 151 %Max: 5.96
Total 5.07k 0.9/s
__ Created Temp ________________________________________________________
Disk table 554 0.1/s
Table 1.61k 0.3/s Size: 16.0M
File 6 0.0/s
__ Threads _____________________________________________________________
Running 1 of 1
Cached 7 of 8 %Hit: 99.82
Created 9 0.0/s
Slow 0 0/s
__ Aborted _____________________________________________________________
Clients 0 0/s
Connects 5 0.0/s
__ Bytes _______________________________________________________________
Sent 3.57G 607.2k/s
Received 34.01M 5.8k/s
__ InnoDB Buffer Pool __________________________________________________
Usage 98.28M of 127.98M %Used: 76.79
Read hit 99.98%
Pages
Free 1.90k %Total: 23.21
Data 5.61k 68.50 %Drty: 0.00
Misc 679 8.29
Latched 0 0.00
Reads 21.60M 3.7k/s
From file 4.62k 0.8/s 0.02
Ahead Rnd 0 0/s
Ahead Sql 0/s
Writes 10.83k 1.8/s
Flushes 5.27k 0.9/s
Wait Free 0 0/s
__ InnoDB Lock _________________________________________________________
Waits 0 0/s
Current 0
Time acquiring
Total 0 ms
Average 0 ms
Max 0 ms
__ InnoDB Data, Pages, Rows ____________________________________________
Data
Reads 5.57k 0.9/s
Writes 7.95k 1.4/s
fsync 3.10k 0.5/s
Pending
Reads 0
Writes 0
fsync 0
Pages
Created 48 0.0/s
Read 5.56k 0.9/s
Written 5.27k 0.9/s
Rows
Deleted 190 0.0/s
Inserted 242 0.0/s
Read 7.47M 1.3k/s
Updated 1.36k 0.2/s
Mysqltunerの出力は次のとおりです
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.35-0+wheezy1-log
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 1005M (Tables: 335)
[--] Data in InnoDB tables: 143M (Tables: 68)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 76
-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned
-------- Performance Metrics -------------------------------------------------
[--] Up for: 1h 28m 55s (154K q [28.899 qps], 4K conn, TX: 3B, RX: 25M)
[--] Reads / Writes: 83% / 17%
[--] Total buffers: 192.0M global + 2.7M per thread (151 max threads)
[OK] Maximum possible memory usage: 597.8M (14% of installed RAM)
[OK] Slow queries: 0% (0/154K)
[OK] Highest usage of available connections: 5% (9/151)
[OK] Key buffer size / total MyISAM indexes: 16.0M/264.4M
[OK] Key buffer hit rate: 98.8% (77K cached / 912 reads)
[OK] Query cache efficiency: 87.2% (116K cached / 133K selects)
[!!] Query cache prunes per day: 5182
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1K sorts)
[OK] Temporary tables created on disk: 24% (427 on disk / 1K total)
[OK] Thread cache hit rate: 99% (9 created / 4K connections)
[!!] Table cache hit rate: 9% (400 open / 4K opened)
[OK] Open file limit used: 61% (631/1K)
[OK] Table locks acquired immediately: 100% (18K immediate / 18K locks)
[!!] InnoDB data size / buffer pool: 143.3M/128.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (> 16M)
table_cache (> 400)
innodb_buffer_pool_size (>= 143M)
上記の「調整する変数」を考慮して、/ etc/mysqld/my.cnfに次の変更を加えました。
- 追加された行：
key_buffer_size = 280M - 追加された行：
innodb_buffer_pool_size = 150M table_cacheのコメントを外して100に変更しました（400を超えるまで継続的に増やします）query_cache_sizeの値を16Mから32Mに変更しました
ここで私が見落としている明白な問題や、やるべきことはありますか？
あなたの問題は、実際にはサーバーのメモリには多すぎるApacheクライアントだと思います。トラフィックが大幅に増加すると、Apacheプロセスは最終的にすべてのRAMを使い果たします。これにより、OSはプロセスを強制的にスワップインおよびスワップアウトし始め、事態を悪化させる傾向があります。最終的にスワップメモリが不足し、OSが最善と考えるものをすべて強制終了します...この場合は、大量のメモリを使用するため、MySQLです。スワップメモリを増やすと、必然的にクラッシュが遅延することに注意してください。
まず、サーバーの機能に基づいて、ApacheのMAXCLIENTSをより妥当な値に減らします。 topを実行し、httpdプロセスのRES/SHR列を確認することで、大まかな見積もりを行うことができます。それらの違いは、各子プロセスが使用するおおよその量です。たとえば、私のサーバーでは、子供1人あたりの平均メモリ使用量は40MBであり、Apacheに3GBのみを使用させたいので、MAXCLIENTSは75（3000/40）に設定されています。 ApacheがすべてのRAM=を使い果たしてスワップを開始し始めるのを防ぐために、必要に応じてこの値と他のApache接続設定のいくつかを少し試すことができます。
また、Apacheクライアントの数が多い原因を確認することもできます。それが実際のトラフィックの急増/急増である場合は、おそらく、より大きなサーバーまたはより多くのサーバーが必要になるか、キャッシュ層を追加して、Apacheの負荷を減らします。サーバーが通常の数の着信リクエストを処理するのに遅すぎる場合は、ApacheのMAXCLIENTSを、リクエストをバックアップしなくても実際に処理できるレベルまで下げる必要があります。または、サーバー、アプリ、またはデータベースの問題が原因で、ロックやフリーズが発生しているため、検出して修正する必要があります。
スワップはほとんどありません（256M）。一時的な手段として、無駄なI/O待機を回避するために、スワップを追加してswappiness（vm.swappiness）を下げます。 SWAPは低速ですが、PIDSのクラッシュを防ぐことができます。また、OOMをgrepし、タイムスタンプをチェックして、時間の経過とともにクラッシュする規則性があるかどうかを確認します。私は自分の時間の中で、巧妙に作成されていないいくつかのcronジョブに目を通さなければなりませんでした。 RAMが8GB未満の場合は、少なくとも2GBのスワップがあることを確認します。先ほど述べたように、スワップを行うと処理が遅くなりますが、DBをクラッシュさせてトランザクションを失い、起動時にテーブルをチェック/修復する必要があるよりはましです。
メモリを追加するのは論理的な結論のようです。
ところで、ウェブサイトを複数の異なるマシンから1つに統合するのか、またはすべてのウェブサイトを古いメモリ（メモリ容量の）で実行しているのかについては触れませんでした。この情報は非常に役に立ちますが、それでもメモリが足りると思います。