新しい職場での仕事の１つに、WordPress のサポートがあるのですが、さっそくトラブルがあったのでそのメモ。
最初は、インターネットで公開しているブログサーバーの応答が異常に遅い、とのクレームがあり対応することに。
先輩社員の助言があり、最初は Disk Full を疑ったのですが（ファイルアップした直後に遅くなった、という話も伝わっていたし）、どうも違うようでした。
サーバーでは、Linux (CentOS)で Apache httpd を使っていたので、error_log を見たところ、頻繁にワーニングが発生している。しかも、 top コマンドで確認すると、ロードアベレージが９０というとんでもないことに。
どうも、何かを繰り返し実行しててプロセスが大量に発生してしまい、スワップまで使っていまったことで、Disk I/Oが追いつかなくなったため、遅延が発生していると思われた。
httpd の error_log で、怪しいのは WordPress のプラグインと解ったので、その対応だけ作成者に依頼し、そのプラグインを停止したら普通に戻りました。
状況はこんな感じですが、実は根が深い問題が。
httpd の error_log を見るかぎり、プラグインによる書き込みができなかったことで、この処理をやり直したようで、プロセスが異常発生している、と判断できる。
まず、このプラグインは書き込みができなかったらエラー表示して、処理を止める仕様になっていない。といことは、同じようなプラグインがあるかもしれない。知らずにそういったプラグインを入れる人がまたいるかもしれない。
そもそもなんで書き込みできななかったのか。
まず、WordPressのシステム領域はユーザーのpublic_htmlにある。このアカウントはバックアップ用で、WordPressシステムはそのアカウントがオーナーになっている。しかし、アップロードしたりプラグインを入れたりするのは、httpd のアカウント （CentOSでは apache ）なので、厳密にいえば WordPressシステムの中に apache が書き込みできないディレクトリが存在する。
プラグイン側で、書き込み可能なディレクトリを使っていれば、今回のような事態は発生しなかったし、httpd のアカウントが、WordPressのシステムを使っているアカウントのディレウトリに書き込み可能になっていれば、問題はなかった。
たぶん、セキュリティを考慮すれば、プラグイン側がまずいような気がするが、妥協して
apache が WordPress システムを書き込みできるようにする必要があった。（そうしないと、WordPress の最新版にユーザーの判断でアップできない）
昔は、チームで作業する人がプロジェクト毎に書き込みできるように、と言われてアカウントのグループ設定がかなり複雑になってしまい苦労した経験がある。WordPressのようななんでも自動でできるブログで、グループの設定で悩むとは思わなかった。
この設定で 2012年から運用してて、よく問題にならなかったものだと、そっちの方にも感心してしまったが。。。
まあ、なんとかしましょう。