WordPress 用 WebサーバーからMySQLサーバーを Raspberry Pi 2 に引っ越した後、約1日経過し、メモリとスワップの必要量が見えてきたので、そのメモ。
結論を書くと、MySQLを分離できたため、Webサーバーはとっても楽になった模様。RPI2（1GB RAM）でもMySQL8.0サーバーは（スワップするものの）リソースに空きがある状態の余裕で動いています。
このサーバーは、Dell Vostro220s Core2Duo + 4GB RAM + HDDを利用していて、これが拡張のほぼ上限。これ以上パワーアップしたいとなると別のマザーボードを使うことになります。
OS再起動時はリソースに余裕がありますが、1週間くらい経過すると、外部からのページアクセスによって、スワップ空間が1GBくらい消費されているのが普通です。スワップ使用料が2GBくらいになるとレスポンスが悪くなるので、あまりに遅くなると手動でサービスを再起動したりしていました。
判っていたことは、だいたい、MySQL データベースが 最大2GBくらいメモリを消費して、残りをWebサーバーやDNSが使っている感じ。主記憶を6GB以上にする（←ハードウェア的に無理だけど）か、MySQLサーバーを外部に引っ越しできれば、Webサーバーは相当楽になるとわかっていたものの、データベースはあまり得意じゃないので、二の足を踏んでいたところ、使用中のMySQL5.7 がサポート終了になり、嫌でも8.0に上げざるを得なくなったわけ。
データベースを直接アップグレードすれば分離する必要はなかったものの、アップデート中はWordPress が使用できないことと、失敗するとすべてのデータを失うことにもつながりかねないため、重い腰を上げ、先月から実験を重ねてきました。
- うまくゆけば、MySQLパッケージを 5.7→8.0に上げるだけ。約10分で終了する。
- 自動のデータベースアップデートに失敗すると、ドツボにハマる。
実験過程で、実際 FreeBSD/aarch64 で MySQL8.0 を起動できなかったし、MySQL8.0が問題なく動作する FreeBSD/arm でも、ちょっとした手順間違いで、MySQLが起動できなかったり、データベースコンバートに失敗した趣旨のログが残ったので、FreeBSD/amd64 本番環境で 5.7→8.0に直接更新するのはやめにしたという具合。本当は、MySQL8.0サーバーにはRaspberry Pi 4 4GBモデルを使いたかったんですけどね。動かないから仕方ない。RPI2 1GB を使うことにしました。RPI2を選択したことによる面倒な点もあるのですけど、それは後日の課題。
丸一日以上 RPI2 で MySQL を動かしてみて、htop で見たリソース利用料が次の図。
MySQL専用なので、メモリは1GBも使っていない。しかし、スワップ領域は300MBくらい消費しています。観察していた感じでは、最初は0で、メモリ使用量が増えるとスワップがジワジワ増えて、メモリ使用量が減ってもスワップは解放されない感じ。なので、とりあえずスワップを確保しておこうという感じで確保されているような印象。WordPressのアクセスに特に遅延は感じない。
WordPress 側の Vostro220s は軽くなった～って印象です。
Webサーバーとデータベースサーバーが同一ハードウェア上にあると、HTTPのピークとデータ検索のピークが同時に発生するので、どうしてもレスポンスが悪かったはず。それを分離できたことで、Webサーバーはデータを送出するだけになり、MySQLサーバーは検索結果を返すだけの別々動作になり、サーバーを操作する私にとって、とっても動作が軽くなった印象。ただ、メンテナンスすべきホストが最低一台増えたので、今後のメンテナンスが課題。
ちなみに、今、MySQLのデータはHDD上に置いています。もう一台のRPI2を使ってマイクロSD上にデータを置くリスクも検証したい。（もう、データだけは置いているけど、運用はまだ。）
とりあえず、Webサーバーとデータベース機能分離1日後のリソース観察メモは、以上。
更に気づきをメモ。
WordPress の動作を軽くするために、wp-super cache を使っています。ダイナミックページを初回アクセス時にレンダリングして、スタティックページとして保存してくれるプラグイン。これでWebサーバーのレスポンスが多少良くなるようです。便利ではありますが、Super cache プラグインが更新される度、（何をやっているのかわかりませんけど、）MySQLが数時間動きっぱなしになっています。HDD負荷が100%になってしまうので、その間は何も作業できなくなり、大量のpage_cleaner が遅いメッセージが残っている。そのため super cache の更新は深夜に行うことにしていました。下のようなラインが大量に発生。
2023-09-03T18:42:17.506107Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4651ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:47:50.048870Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5017ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:47:56.893632Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4009ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:48:05.505884Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4607ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:51:59.605541Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4617ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:52:28.278035Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4008ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:52:51.864440Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4261ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:53:00.519930Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4329ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:53:18.875095Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5029ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:53:30.421353Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4359ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:54:06.548682Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5874ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 2023-09-03T18:57:00.845541Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4603ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.)
データベースサーバーを分離後、初めて super cache プラグイン更新が発生し、アップデート作業を行ったのですが、MySQLサーバーがHDDを激しくアクセスする動作が起こらない！分離したのが良かったのか、分離するために一度 mysqldump でデータベースをきれいにしたのが良かったのか。