はじめに
本Webサーバは1台(?)のサーバにApache httpdとMariaDBが同居するという昔ながらの構成で、かつそれを仮想機として運用しています。
一方でFedoraに限らずLinuxのkernelはOOM killerという機能を持っていて、プロセスから要求されたメモリが物理的に確保できなくなってくると、プロセスことに計算されているスコアに基づいてプロセスを強制的にkillしてしまいます。
kernelがそういう機能を持っているということは大量にメモリを使用するプロセスがOOM killerに目をつけられる可能性が高いわけです。事実、この記事を最初に書いている直近の2日間(2018/6/4及び2018/6/5)連続でデータベースに接続することができず、エラーページが表示されてしまいました。(´・ω・`)
というわけで、この記事ではOOM killerの発動状況と、その回避策について書きます。
OOM killerの発動状況
/var/log/messagesに以下のログ(抜粋)が記録されていました。MariaDBのdaemon(プロセス名はmysqld)が狙われたようです。(´・ω・`)
Jun 6 03:31:55 pnr kernel: Out of memory: Kill process 23979 (mysqld) score 118 or sacrifice child
Jun 6 14:15:11 pnr kernel: Out of memory: Kill process 25147 (mysqld) score 124 or sacrifice child
Jun 6 14:15:51 pnr kernel: Out of memory: Kill process 27813 (mysqld) score 72 or sacrifice child
回避策
その1:不要なdaemonを起動させないように設定する。
MariaDBの運用とか設定とかっていうレベルの話ではないですけど、これは意外に効果があります。贅沢は敵です。
本Webサイトが稼働しているサーバでも、不要なdaemonを稼働させていた覚えはなかったのですが、psコマンド等を駆使して調べた結果、以下の不要なdaemonが動いていました。
- libvirtd
- pptpd
- named
1つ目のlibvirtdは今どきのLinuxなら動いてしまっていることの方が多いと思います。2つ目のpptpdは自宅サーバとの間の通信用に使っていたもので、最近OpenVPNに置き換えたために使わなくなったものです。
3つ目のnamedは最近までprimaryのDNSサーバとして運用していたのですが、不要になっていたのを忘れていたので、この機会に止めてしまいます。
不要なdaemonが確認できたところで、root権限で以下のコマンドを実行してこれらのdaemonをただちに停止させ、かつ再起動時にも動作しないようにしておきます。
# systemctl disable libvirtd
# systemctl stop pptpd
# systemctl disable pptpd
# systemctl stop named-chroot
# systemctl disable named-chroot
その2:MariaDBの設定を調整する。
次に、MariaDBの設定を調整します。まず、/etc/my.cnf.d/mariadb-server.cnfの[mysqld]セクションに以下の設定を追加します。
query_cache_limit=4M
query_cache_size=32M
スポンサーリンク
上記の設定を行うことによりクエリキャッシュを有効にすることで、データベースのレスポンスを速くして、データベースサーバがクエリを抱え込む時間を少しでも減らそうという目論見です。
なお、今回はスロークエリの検出に係る設定についてはWordpressの性能を信じて行いませんでした。
[2018/7/17追記] query_cache_sizeの大きさは当初は16Mでしたが、32Mに変更しました。
その3:エラーページに現在の状況の説明文と広告を入れる。
エラーページでも現在の状況を正直に説明してしまいます。
2018年6月5,6日と2日連続でOOM killerにMariaDBのdaemonがkillされてしまったのでこのエラーメッセージが表示されていました。再度このメッセージが表示される時にはMariaDBのdaemonがkillされているのかもしれません。
的な文言を追加しておきます。これにより、「中の人が復旧に向けて頑張っている」感を出すことができると思います。
また、Amazonのバナーを追加しました。
どのバナーが出るのかについては次にデータベース接続エラーが発生したときのお楽しみです。
まとめ
今回の$n$選シリーズは$n = 3$の場合となりました。今回Wordpressの性能を信じて設定を行わなかったスロークエリの検出に係る設定ですが、もう少し落ち着いたところで再度試してみる予定です。また、クエリキャッシュの設定も当面の間上記の設定で様子を見ていきたいと考えています。
この記事は以上です。