web-dev-qa-db-ja.com

OOMを取り除き、連続してmysqldがクラッシュする

mysqldサービスに影響を与えていると思われるメモリ不足の問題を取り除こうとしています。サービスは完全にランダムに停止します。週に1回、2日ごとに停止することもあります。

私のVPSには6GBのRAMがあり、スワップファイルはありません（私のプロバイダーはスワップを許可/サポートしていません）。私のアプリケーションはPHPベース（Symfonyフレームワーク）です。 Apache 2.2で実行されます。

今晩、RAM使用量の急増を観察しました。残念ながら、free -mの正確な出力をキャプチャできませんでしたが、列freeの-/+ buffers/cacheは約1Gでした。 RAM使用量は4.8Gから5.2Gに上下していました。

メンテナンスウィンドウ中に、httpd、mysqld、およびmongodをシャットダウンすると、次のfree -m出力が得られます。

[root@XXXYYYZZZ ~]# free -m
             total       used       free     shared    buffers     cached
Mem:          6144       4916       1227          0          0       1207
-/+ buffers/cache:       3709       2434
Swap:            0          0          0

私の質問は、使用済みメモリの3709Mで何が起こっているのかということです。 topコマンドはあまり明らかにしません：

top - 19:54:58 up 3 days,  6:35,  2 users,  load average: 0.00, 0.01, 0.05
Tasks:  21 total,   1 running,  20 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   6291456k total,  5034692k used,  1256764k free,        0k buffers
Swap:        0k total,        0k used,        0k free,  1236060k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    1 root      20   0 19236 1180  932 S  0.0  0.0   0:00.02 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd/23992
    3 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper/23992
  140 root      16  -4 10644  520  248 S  0.0  0.0   0:00.00 udevd
  482 root      20   0  179m 1252  828 S  0.0  0.0   0:00.04 rsyslogd
  493 dbus      20   0 21408  616  376 S  0.0  0.0   0:00.00 dbus-daemon
  510 root      20   0 66632 1232  520 S  0.0  0.0   0:00.00 sshd
  517 root      20   0 22184  904  668 S  0.0  0.0   0:00.00 xinetd
  870 root      20   0 66828  924  276 S  0.0  0.0   0:00.00 saslauthd
  871 root      20   0 66828  680   32 S  0.0  0.0   0:00.00 saslauthd
  886 root      20   0 83080 2664  840 S  0.0  0.0   0:04.99 sendmail
  894 smmsp     20   0 78668 2108  648 S  0.0  0.0   0:00.03 sendmail
  944 root      20   0  114m 1232  628 S  0.0  0.0   0:00.81 crond
  955 root      20   0 88304  21m 1784 S  0.0  0.3   0:05.25 miniserv.pl
22840 root      20   0 96276 4448 3460 S  0.0  0.1   0:00.09 sshd
22842 root      20   0  105m 1988 1524 S  0.0  0.0   0:00.03 bash
22985 root      20   0 96300 4168 3164 S  0.0  0.1   0:00.03 sshd
22987 root      20   0 57848 2340 1624 S  0.0  0.0   0:00.04 sftp-server
23313 root      20   0 96276 4472 3460 S  0.0  0.1   0:00.68 sshd
23315 root      19  -1  105m 2024 1544 S  0.0  0.0   0:00.16 bash
25080 root      19  -1 14900 1220  992 R  0.0  0.0   0:00.00 top

LinuxがRAMでキャッシュを行うことは知っていますが、これはかなり不規則だと思います。私は間違っているかもしれません、そして実際のところ、私は私が間違っていることを願っています。

実行できるdrop_cache呼び出しを注意深く読んだ後、キャッシュを削除しました。これを取得するためだけに、それを試してみることにしました。

[root@XXXYYYZZZ ~]# sync; echo 3 > /proc/sys/vm/drop_caches
-bash: /proc/sys/vm/drop_caches: Permission denied

したがって、キャッシュを削除することも、スワップファイルを作成することもできず、RAM消費量で、太陽の近くを飛んでいます（そして、次の理由で数回の火傷を負っています）。 mysqldがクラッシュします）。

誰かがこれをよりよく調査する方法を知っていますか？

最近かなりイライラしているVPSプロバイダーを倒そうとしている場合、パフォーマンスデータを誤解していないこと、さらに悪いことに、正当なプロセスが実際にその量のRAMを消費していることを証明する必要があります。

どうもありがとう！

更新

virt-whatを実行して、openvzを取得しました

Update2：メッセージからのOOMエントリ：

/var/log/messages-20161009:Oct  2 16:43:43 XXXYYYZZZ kernel: [56050139.271683] Out of memory in UB 23992: OOM killed process 22029 (mysqld) score 0 vm:5044284kB, rss:656944kB, swap:8280kB
/var/log/messages-20161009:Oct  2 16:43:55 XXXYYYZZZ kernel: [56050150.552528] Out of memory in UB 23992: OOM killed process 30486 (mysqld) score 0 vm:310088kB, rss:214456kB, swap:0kB
/var/log/messages-20161009:Oct  5 12:56:17 XXXYYYZZZ kernel: [56295842.893210] Out of memory in UB 23992: OOM killed process 13284 (mysqld) score 0 vm:5066092kB, rss:694760kB, swap:40kB
/var/log/messages-20161023:Oct 22 17:54:09 XXXYYYZZZ kernel: [1219419.032263] Out of memory in UB 23992: OOM killed process 789 (mysqld) score 0 vm:5057832kB, rss:698980kB, swap:0kB
/var/log/messages-20161023:Oct 22 17:54:20 XXXYYYZZZ kernel: [1219428.340161] Out of memory in UB 23992: OOM killed process 21700 (mysqld) score 0 vm:310088kB, rss:271892kB, swap:0kB
/var/log/messages-20161030:Oct 29 12:14:47 XXXYYYZZZ kernel: [1804212.497098] Out of memory in UB 23992: OOM killed process 25691 (mysqld) score 0 vm:5057548kB, rss:690164kB, swap:0kB
/var/log/messages-20161030:Oct 29 12:15:06 XXXYYYZZZ kernel: [1804222.381820] Out of memory in UB 23992: OOM killed process 23659 (mysqld) score 0 vm:310088kB, rss:248376kB, swap:0kB
mysqloutofmemoryerror
1
Jovan Perovic

まず、テストを行っていない限り、yoキャッシュを削除する必要はありません。 Linuxカーネルは、キャッシュに「空き」メモリを使用します。何かがメモリを要求し、それが他の場所で利用できない場合、その要求はキャッシュメモリから満たされます。

問題の解決を開始するには、ログを確認する必要があります。それらには、OOMシステムからの情報が含まれている必要があります。

他の人が示唆しているように、コンテナVPS（openvzなど）を使用しているようです。この場合、実際の解決策は、異なる仮想化テクノロジーを使用する別のVPSに移行することである可能性があります。 KVMなど.

2
user9517

あなたが得たエラー

[root@XXXYYYZZZ ~]# sync; echo 3 > /proc/sys/vm/drop_caches
-bash: /proc/sys/vm/drop_caches: Permission denied

Noclobberが有効になっている結果です（manbashおよび> |の検索）。このようにしてみてください

sync; echo 3 >| /proc/sys/vm/drop_caches

ちなみに、これから始めてみることができます

sync; echo 2 >| /proc/sys/vm/drop_caches

また、slabtopコマンドの出力を表示して、RAMを何が食べているかを確認することもできます。それが大いに役立つというわけではありませんが、少なくともそれがいくつかのスラブキャッシュから来ているかどうかはわかります。
また、sysstatパッケージをインストールし、1分の解像度でsarを有効にして、オンラインでリアルタイムに監視する代わりに、システムパフォーマンスを履歴的に分析できるようにします。

0
Dmitry Zayats