技術
さくらインターネットから住所確認とか来る
DB最適化を自動的にやらせてみる
うちみたいな小さいとこには無関係な予感もするけど、WordPressを使ってるとだんだんMySQLのDBが重くなる場合もあるとか。デーモンが勝手に最適化してくれる設定とか無いんかな。無さそうだな。
対策として、標準添付の最適化ツールをcronで走らす方法や、WordPressのプラグインでやらせる方法が挙げられていた。WordPress標準でWP_ALLOW_REPAIRというオプションもあったけど、特定URLを開いて中のボタン押すと発動、という面倒くささなので見なかったことに。他人が勝手に遊ばないように普段は使用不可にしておいてね、とか出るし。
ちなみに、最新版WordPressなら勝手に最適化とかやってくれてるかも、という甘い夢も見たが、試しに最適化を掛けたら普通に痩せた。夢敗れたり。
で、プラグインをやたらと増やすのはアレなのだが、定評がありそうなWP-DBManagerプラグインをとりあえず試してみる。
ふむふむ。.htaccessを置いてバックアップフォルダへのアクセスを塞いどいてね、とな。
LighttpdやNginxを使うつもりなのでそれじゃ駄目なんだ。わざわざそれ用に鯖設定を書き換える気も無いし。
他に自動的にこなしてくれそうなプラグインも見付からないし、そもそもプラグインを増やせばメモリも食いそうなので、cronでやることにする。一般ユーザのcrontabで十分だな。
試しに、mysqlcheck -o -r -A -u username -p passwordみたいに打つとエラー。ふむ。-uusernameだと動くな。スペース不可なのか。
という訳で、crontab -eして、12 34 * * * /usr/bin/mysqlcheck -o -r -A -uusername -ppassword &>/dev/nullみたいな感じで追加する。crontab書くの久々だけどこれでいいんだっけ。まーいいか。
マビのショートカット設定がまた消える
ファンクションキーとか数字キーとかにスキル割り振るアレですな。
あれ、マビだと鯖保存ですが、たまーに初期状態になる。印象としては年に数回くらい。
ショートカット設定はavatar.mabinogi.jpに保存されてるらしいんだけど、鯖落ちでロード失敗で初期状態になる場合もある。その場合、鯖が復活すれば直るのだが。
今回は、鯖で持ってた情報全部飛んでるくさい。これは過去に一回か二回くらいしか無かった記憶。
で、DNS情報の浸透がアレなので鯖保存機能も死んでます、とか公式にアナウンスされた。つまりIPアドレスも変わったのか。鯖変更だろうか。マイグレーションとかバックアップとか無いのか。
DNSの問題なら何とかなるか、と思ってdig +norec @b.dns.jp mabinogi.jp nsとかやりながら辿ってって権威サーバから最新のAレコードを拾うと、TTLが86400だった。ああ、移行後のTTLなら別にそれでいいか。むしろキャッシュサーバの古いレコードのTTLを見てみるか、と思って叩くと、全く同じ最新のAレコードが得られた。あれ、それなら鯖保存機能が死んでるのは何故？
リゾルバキャッシュもクリアして、再度問い合わせ。つーか8.8.8.8とかにも問い合わせ。みんな新しいAレコードになってる。でもショートカットは保存されない。一応hosts書いてみても駄目。掲示板ではちゃんと保存出来たという書き込みもあるけど、ゲーム内の技術屋系のフレに聞いても全滅。netstatでも正しいIPアドレスに接続されてるし。
えーと。吹っ飛んだ上に、DNS関係無く普通に鯖も死に掛けてる、ということでいいのだろうか。
追記:
何か困ってる人多そうな気がするので、続きを一応書いてみた。
Lighttpd+PHP-FPMを試す
今日もさくらのVPSをだらだらと。
やっぱりApacheはきつい。Lighttpdにすれば改善されるけど、php-cgiの消費がまだ少し重い。どうにかしたい。
どうにかする為にNginxを試す。でも気力が尽き掛けてるので、すぐに諦める弱い気持ちで戦おう。yumで適当に入れてちょちょいと書き換えて、と。バーチャルホストが変な構造なんだよなーうちは。こんなもんかなー。うむ、403か404しか出ないな。よし。諦めたからここで試合終了だ。
だがしかし、Nginxと一緒に導入したPHP-FPMはLighttpdでも使えそうだよなー、と思ったので調べてみる。ふむふむ。使えることは使えるようだけど、相性が微妙っぽいような話もちょいちょいヒットしてるような。けど2008年とかの話みたいだからキニシナイ。
設定自体は至極簡単で、mod_fastcgiのディレクティブのsocketとbin-pathを削ってhostとportの指定に変えてやって、php-fpmをデーモンで動かしておけばいいだけっぽい。多分。ちゃんと動いてる。一見。
ついでに、前に失敗したシングルプロセス設定も復活させてみよう。えーと、/etc/php-fpm.d/www.conf開いて、pm=static、pm.max_children=1、かな。大丈夫かこれ（笑）。まあ、しばらくは試してみたい。これで安定したらだいぶ助かるし。
つーかApacheでもWorker MPMとFastCGIを使えば似たような安心感なのかなあ。コンパイルフリーではなくなりそうだけど、MT SafeなPHPをmod_phpで、が最強なのだろうか、って前にも書いたかもしれない。
とりあえずNginxもいつかは把握したいけど、既にメモリ消費は著しく改善したから、これで安定すれば俺的にはかなり満足。APC入れてWordPress動かして、NSもメールもやって、今のところ385MB空いてるし、ちょっと負荷掛けてもほとんど数字が変わらないのも安心だ。
こうなるとメモリ256MBの安いコースも欲しくなるなあ、とか何とか調子に乗ったり。
とか書いた直後に問題発生。めんどくさ。
ふーむ。MT UnsafeなPHPをアレする以上、多分FPM側もシングルスレッドだろうから、ああ、そうか。遅いPHP踏むと他が動かなくなってまずいな…。
つーことで、pm=dynamicにして、max_children以外全部を2くらいにして、max_childrenを8くらいにしてみるかなあ。これなら応答性もさほど悪くなさそうな気がするけど。一見。
とかやってると、FPM使わない時とあまり変わらなくなってきてる訳ですね。意味無くなってきましたなあ…。MT UnsafeなビルドでPHPがメモリ食うのはどーしょもないのか。
というか、MT SafeでもC10Kには対応出来ないじゃないか。WordPress.comとかどうしてるんだろ。Nginx使ってるらしいけど。普通に分散してるんかなあ。それとも強い鯖ならMTで何とかなってしまうのか。そもそも規模が違いすぎて何の参考にもならんが。
つーかWordPressの話が多い時にMTって書くと、Movable Typeと紛らわしいな。