本記事は「KUSANAGI for ConoHaの1Gプラン」限定の話です。
とはいえ、恐らく私みたいなライトユーザーが一番契約しているプランですので、多くの方の参考になるのではないかと。
タイトル通り、MySQLの設定を変更して高速化を図ります。
【2024年9月22日追記】
KUSANAGI9の場合は、まず以下のコマンドを試してみてください。
# kusanagi dbinit # kusanagi php
旧来のconfigureに変わる最適化コマンドです。
これでダメなら本稿を含む他の方法を試すことになります。
アイキャッチの画像はKUSANAGIのイメージキャラクター草薙沙耶 ©PRIME STRATEGY
きっかけは、サイト分離したとき、やけに書き込みも表示も遅かったこと。
こちらのWordPressサイトは高速化を図るために、メインサイト以上の対策を施しています。
それなのに瞬時に表示されない。
元々、この２年くらい、ブログから遠ざかってたんですよね。
メインサイトも重くなっていたような気はしていたのですが、ようやく気のせいでないと理解。
調べてみました。
すると、以下の記事を発見。
kusanagiの記事で見覚えのある顔の方が。
自分のConoHaの環境でも激遅になっていたので、調べてみました。
どうやら、ConoHaの1GBメモリのマシンではKUSANAGI標準設定だとswapが頻発していました。
以前はそんなことなかったのですが。手っ取り早く使用メモリ量を減らすために、以下のようにMySQLの設定(/etc/my.cnf.d/server.cnf)を変更し、MySQLを再起動して下さい。
（変更前）
query_cache_size = 128M
innodb_buffer_pool_size = 384M
（変更後）
query_cache_size = 64M
innodb_buffer_pool_size = 128M
また、4GBメモリのマシンでも変わらないということは、別要因の可能性があります。
以下の情報があると特定がし易いです。kusanagi status の内容
plugin のリスト(できれば)HHVMを使用している場合、プラグインによっては遅くなります。
その場合は該当プラグインを停止するか、PHP7を使用することを検討して下さい。
これは試すべきだと思い、やってみることに。
結果、表示については体感が一気にアップしました。
本来こういうのは速度も計測するべきですが、KUSANAGIは元々体感でわかるレベルで遅い方がおかしいので。
原因の一つであったことは間違いないようです。
書かれている通り、以前は必要なかった作業なんですけどね……。
ただまだ、戻りきってはいないような。
特に記事更新の異様な遅さによる500エラーは解決できていません。
恐らくプラグインが足を引っ張っているかLuxeritasを更新してのチューニングを完全に施していないせいだろうと思います。
そこまでやるには根本的な対策が必要となってくるので、後日に回します。
