さくらインターネットから、「ファイル数多すぎるんで削除してください」という連絡が来たのでなんのこっちゃと調べたら、 この間の設定変更で指定したセッションファイル格納用ディレクトリが溢れているという話らしい。おおっと。 でもって、話をよくよく聞いてみるとセッションが使用不可になったのも共用ディレクトリである「/tmp」に保存できるファイル数が10万ファイルまでに制限されているからだそうな。当たり前か。 本当のことを言うと、そう大したユーザー数がいるとも思えないサービスなのに溢れすぎじゃないかと思うけど、 設定を見返すのは後回しにしてとりあえず現状を改善しないと行けない。 よくよく考えてみて、「/tmp」ディレクトリのパーミッション的に階層化も出来そうにないし、 こりゃセッションデータをMySQLに格納するしかないかなと言うことで以下の設定を。
こちらの件に関連して。 [umbls] ログインできない不具合を修正しました。 – nplll 根本的な理由はさっぱり分からないのですが、なぜかさくらインターネットのサーバにてセッションが使用できなくなっていました。初めはプログラムのバグでログインできないんだと思って、自分が書いたコードやSymfonyの設定周りを洗っていたのですが、なんか何をどうやっても上手くいかない。それどころか、簡単なセッション処理のプログラムすら動かない。session_start()して、$_SESSIONを使って格納しただけなのに、保存されないのね。
<?php
session_start();
echo 'Welcome to page #2';
echo date('Y m d H:i:s', $_SESSION['time']); // 1970 01 01 09:00:00と表示されてしまう
?>crontabを大幅に編集したくなったので、バックアップ取れないかなぁと検索して調べていたのだけど、行き当たった情報見たら何かもの凄く簡単な話だった。あらら。
crontab -l > ~/backup/crontab.20101126crontab ~/backup/crontab.20101126
とあるプログラムでffmpegをコマンドラインで使って3gpファイルを作成するということをしているんですが、ある時期を境に上手く動かなくなってしまっていたんですね。次のコマンドでエラーが出る。
/usr/bin/ffmpeg -y -i original.mp3 -acodec libamr_nb -ac 1 -ar 8000 -ab 7.95k new.3gp
（中略）
Unknown encoder 'libamr_nb'なるほどそうだったのか。 つまり不用意にFFmpegをバージョンアップした俺が悪いんじゃないか…がっかり。。リビジョン11660時点 libamrがnonfreeになったそうで –enable-nonfreeを追加しなければコンパイルできません。 （中略） リビジョン19631頃 amr-wbとamr-nbが消えてopencore-amrを使用するようになりました。 「–enable-libamr-nb –enable-libamr-wb」の代わりに 「–enable-libopencore-amrnb」と「–enable-libopencore-amrwb」を使用しないといけません。
フレームワークを使わない管理から、俺俺フレームワークもどきに移行しかけていたのですが、そもそもフレームワークを設計する技量など無く便利な部分だけを抜き書きしただけ（autoload周りとか）だったので、これ以上カオスな状態にするのは止めようとフレームワーク導入を決定。導入するのは何にするかほんの少し考えたけど、CakePHPとZendFrameworkもよぎりましたが、CakePHPは複数プロジェクトを管理できないっぽかったし、ZendFrameworkは全然わかんないし、そもそもどれも解ってるとは言い難いので、仕事で使ってて少しはなじみがあるSymfonyを入れてみました（ただし、入れたのは1.4系。仕事で使ってるのは1.0系）。 インストールはここを参考にして、PEAR経由で。 さくらインターネットでsymfonyをインストール | ueblog
前からやりたいなぁと思っていたのだけど上手いこと入れることが出来なかったXdebug。
Xdebugを入れると例えばPHPでvar_dumpをしたときに、このようになっていたのが、
こうなります。便利。
改めてやり直してみたら意外にも上手く入ったので以下、メモしておく。
# 正しいかどうかわかりませんので、復旧準備してから試してくださいSubversionでファイルを追加する際にパーミッションの関係でaddに失敗した。パーミッション等確認してから再度updateしたら次のエラー。
ffmpegでストリーミング配信$ svn up www/hoge.php
svn: 作業コピー 'www' はロックされています
svn: ロックを解除するには 'svn cleanup' を実行してください (さらに詳しく知りたいときは 'svn help cleanup' と打ってください)svn cleaup www$ svn cleanup www
svn: 現在のディレクトリ: 'www'
svn: コマンド 'modify-wcprop' を 'www' 内で処理しているときにエラーが発生しました
svn: 'hoge.php' はバージョン管理下におかれていませんwww/.svn/logもう一度、cleanup。
svn cleaup wwwWebサーバが非常にビジーなのは何でなんだぜ？と言えば、リクエスト過多でメモリを食いつぶしてるのが原因だろうというのは見当が付いていたので、リクエストを減らすかメモリを増やすかで、そのリクエストを減らす案の1つとして「ストレージサーバを用意し、HTTP経由でファイルを取得する」という方向で実施してみたらばこれが見事にビンゴ。多分、ただWebサーバをスケールアウトしてもこんなに上手くいかない（サイトの構成上、の話だけど）。 ストレージサーバはHDDが少し多めな他は大体通常のレベル。Apacheの代わりにthttpdを採用しているけれども、sslやkeep-aliveを考慮するとApacheでも別に良かったかも知れない。まぁ今のところ上手くいってるので試すのは得策とは言えないけど、機会があれば試してみたい。
恥ずかしながら、いや本当に恥ずかしながら、ファイルを変更するときのパーミッションにいて混乱してしまったので少しまとめておく。 OSはCentOS 5.2。 まず重要なことはこれ。
ファイルを変更、削除するのに必要なのはそのファイル自体のパーミッションではなく、そのファイルを格納しているディレクトリのパーミッション…。 （そうだったのか…） ディレクトリのパーミッション毎に可能な操作は以下の通り。
現在あるシステムで、memcachedのバックアップとしてTokyoTyrantを利用しています。 以下は、主要な部分だけを抜粋したコードです。
$key = 'hello';
//Pecl::memcached
$value = MyMemcached::get($key);
if($value === false):
//memcacheから取得できないときはTokyoTyrantからの取得を試みる
MyTokyoTyrant::initialize();
if(MyTokyoTyrant::getEnabled() === true):
$value = MyTokyoTyrant::get($key);
$hasTTCache = (!$value) ? false : true;
else:
$hasTTCache = false;
endif;
//TokyoTyrantからも取得できないときはMySQL
if($hasTTCache === false):
$value = self::getByIdWithConnection($key);
MyTokyoTyrant::set($key, $value, 0);
endif;
MyMemcached::set($key, $value);
endif;