削除。
以下の URL は削除しました。
http://blog.yuhisa.com/news/dat/1149078453.dat
http://blog.yuhisa.com/news/dat/1149165160.dat
以下の URL は削除しました。
http://blog.yuhisa.com/news/dat/1149078453.dat
http://blog.yuhisa.com/news/dat/1149165160.dat
ひっそりと、新サーバーへ移行完了していたりします。
スペックは安鯖でお馴染みだった、標準の Express5800/110Ge に
Seagate の ST31000528 をソフトウェアRAID1構成で入れて、
メモリは NonECC な CFD の W2U800CQ-1GLZJ (2GB) が入ってます。
CPU は、 標準構成のままなので、Celeron 430 (1.8GHz) ですが、
120,000 アクセス/day のがっくしメニューを淡々と処理したり、
その10分の1のバックエンドのアクセスも難なく処理できているので十分じゃないでしょうか。
ルーターは、先月下旬から BUFFALO の WRZ-HP-G54 (2048セッション) に代わり
NTT-ME の MN8300 (4096セッション) がサーバー用として動いてます。
ちなみに、 YAMAHA の X10 も 4096 セッションだったり。
以前は、 MN8300 をサーバー用に使うと応答なしになったりすることが多かったのですが、
今のところ順調に動いてくれているようで、何よりです。
残念だけど、なかなか思ったようには行ってくれなかった。
BBX も、BBQ も、すぱむちゃんぷるーも駄目となると…。
ちょっと考えよう。
気分が乗ってないけど、メールサーバーを立てました。
回線を乗り換えたときから OP25B を気にしなくて良くなってたんで、
リレー設定とかが簡単で済みました。
So-net で立てているときは、 Postfix の設定ファイルに
みたいな一行が必要です。
気分が乗ってたので、新鯖 ( 新鯖か? ) に DNS サーバーを立てました。
といっても、30分あればすぐ出来てしまうわけですが。
Apache と Toritonn ( MySQL ) は既に入れてあって、
テーブルも一応 10月分ぐらいまでは、マージしてあるはず。
登録件数は、2,731,083 件。データベースを構成するファイルの合計は 4.5GB。
現状でも、 API 叩けば、ちゃんとデータが表示されているので、特に問題はなさそう。
(まだ外部からは使えるようにしていないけど)
ただ、>>1 の本文と、スレタイを同じテーブルに入れちゃったせいで、
スレタイだけから検索したいときに遅くなるのが 失敗したなーと思った。
分割して、MERGE テーブル出来るようにしていればなぁ。
うーん、ここに書くのもなんだか久しぶり。
大量のスパムが入ってたので、対策してみたんですけど、どうでしょう?
もっと、根本的に解決できれば良いんですけどねぇー。
使っていただいてるのに、これ以上強いるのも・・・。
「猫のアイコンを選んでね!」とか、やります?
[12/Aug/2009:17:34:50 +0900] “GET /tmp/denylist.php HTTP/1.1″ 200 2729
(・∀・)ニヤニヤ
CentOS はどうやら Dovecot が MySQL を使うタイプのパッケージみたいで、
MySQL の 依存がありますね。
先に Toritonn を入れてしまえば問題ないのですが、 Dovecot を先に入れてしまうと、
MySQL を抜くときに Dovecot まで一緒に抜けてしまいます。
とりあえず、構築が終わったサーバーは、 DNS と FTP と MySQL で、
MySQL だけデータ を流し込んで再構築しないといけない。
未テストなのは、Postfix と Dovecot で、これはポートの関係上テストしづらい。
あとは Apache が終われば良いんだけど、ちょっとファイルの構成が複雑で、
それらの整理に手間取ってる。
blog.yuhisa.com 以下は、MySQL も絡んでくるので、またまた面倒。
でもまぁ、この作業が全部終われば、ウィークリーバックアップ以外ほとんど必要なくなるわけで、
HDD が2個空くことになるのかな?
併せても 300GB いかないだろうけど、消費電力は減りそう。
Apache や PHP の設定になってきて、このあたりはもうなれたものだと思っていたのですが、
eAccelerator をパッケージからインストールしたら、 /etc/php.d/ の中に
eaccelerator.ini とかいうファイルを勝手に作ってくれちゃったんですね。
Zend Optimizer 使用者にとってはこれはやっかいで、
eAccelerator の設定より後に Zend Optimizer の設定を書かないといけないんです。
ところが、 eaccelerator.ini というファイルがあるせいで、 Zend Optimizer の設定が優先され、
php -v とかやっても
PHP Fatal error: [eAccelerator] eAccelerator 0.9.5.2 can not be loaded twice in Unknown on line 0
と怒られる始末。
今までは、確かソースから入れていたのでこんなことにはならなかったのですが、
いやー、詰まった詰まった。30分ぐらいググったね。
で、念のためファイル構成を調べるためにパッケージのファイルを表示させたら
eaccelerator.ini がいやがると。