2020/10 サーバのメモリ増加調査

佐々木誠

本番サーバのメモリ量が90%を超えて正常に動作しなくなることがありました。 なぜ90%まで増えるのか原因を突き止めるのに苦労したので紹介します。

slab問題

現象

なぜ気づかなかったか

そんな中、メモリアラート閾値ギリギリのところで、BOTからのアクセスが増え一気にメモリが90%になりサイトが表示されない現象が起きてしましました。

調査

原因にたどり着くまで紆余曲折を経たので、時系列順に調べた内容を紹介します。

1. Laravel

まずはフレームワークのLaravelでメモリリークが発生するケースがないかググりました。 しかし、Laravelについてはメモリリーク事例記事のようなものは一切見当たりませんでした。

比較的新しく、その上人気のあるフレームワークだけあって優秀なんだと感心しました。

2. PHP

次は、Laravel同様にPHPについてググり、php-fpmの設定にたどり着きました。 本サーバでは前段にNginxを使っておりLaravelとの接続にphp-fpmを利用しているので、可能性はありました。

php-fpmの設定について

の2点が怪しかったのですが、適切な設定がされており問題はありませんでした。

また、この調査から例えLaravelや自分達が実装した処理でメモリリークが起きていたとしても、php-fpmは設定されたリクエスト数に達するとプロセスを再起動するのでメモリは解放され、今回のような問題にはならないことがわかりました。

3. Slab

アプリ内に問題が見当たらないため、CPUやメモリの使用状況を確認できるtopコマンドで、メモリを食いつぶいているプロセス(PHP含め)調べてみましたが問題は見当たりませんでした。

KiB Mem :  8009032 total,   227704 free,   849640 used,  6931688 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  6603212 avail Mem

途方に暮れている折、CloudWatchで取得しているメモリ使用割合をtopコマンドのメモリ使用割合が大きく食い違っていることに気付きました。 つまり、topコマンドでは確認したかったメモリ使用状況を表せていない可能性が出てきました。

そして、/proc/meminfoもメモリ使用状況を確認できることがわかり、確認してみると使用割合がCloudWatch同様にメモリが逼迫している結果となり、/proc/meminfoを使えば本現象を計測できることを突き止めました。

Slab:            5027188 kB
SReclaimable:    5003208 kB
SUnreclaim:        23980 kB

さらに/proc/meminfoの出力項目を精査するとSlab値が大きく占有していることがわかりました。

原因

Slabキャッシュとは、スラブアロケータで使用される物理メモリで、カーネルが使用するキャッシュ機構でした。ググると少しづつ圧迫されているという事例記事が色々見つかりました。

本サーバはCloudSearchと連携するためにAWS SDKを利用していたので、AWS SDKが直接の原因である可能性が強くなってきました。

対処

サービスの性質上CloudSearch連携もAWS SDK利用も止めるわけにはいきません。 そこで、Slabキャッシュの解放コマンドを試したところ、一気にメモリ使用量は減りました。

> /bin/echo 2 > /proc/sys/vm/drop_caches
slab対策

1日1回、CRONで解放コマンドを実施することで上記の画像のように、メモリ増加は発生しなくなり問題は解決しました。

本調査から

を学ぶことができました。 もし似たような現象が発生した際には参考にしていただければと思います。

こんな記事も読まれています