朝の6時に起きてなにしてんの？と自分ながら思ってしまいますが、サーバがまたもやCPU負荷が異常に上昇してストップしました。CramAVが起動すると負荷がかかるよう。滅多にないウイルス(しかもメールくらいしか外部からファイルは入ってこないのでいらないっちゃいらない)のためにCramAVを起動するのがバカらしくなってきた。止まった、というのは正しくなく正確には動いているけど無反応。やっぱりメモリかな、とこの前Sofmapで3,480円で買ったシリコンパワーの2GB×2をセット。値段の差が戦力の決定的な差でないことを教えてやる！
だが、しかし！
なんとmysqldやspamdなどの重い処理が起動する際にカーネルパニックを起こしやがる…orz
ふ、安物買いの銭失いとなっちまった。Patriotとかにすべきだったか？ML115G1のWiki見たらちゃんと動いている実績あるメモリだったのにぃ。Windowsなら大丈夫なのかな。CPUとの相性？ML115との相性かな。
値段の差が戦力差だったことを思い知らされたぜ。
このBlogは自宅にあるML115G1を使って運営しているのですが、この前CPUをノーマルの3500+から5000BEに変更しました。おかげで処理自体は軽くなったのですが(微々たる差ですが)、その後どうも調子が悪い。一度メモリがいっぱいになってフリーズし、メモリを増設したのですが、そのほうが調子悪いということになりました。CPUを元に戻すことも考えましたが、それもつまらない。
とりあえずメモリ管理で、重要なプロセスを殺してしまいそうなOOM-Killer(メモリが足りないときにプロセスを殺す仕組み)をDisableしようとしました。
最近WordPressにKtai Styleを入れたためか、モバイル側のSpyderアクセスが多いなぁ、と思っていたのですが、こんな感じでBaiduからのアクセスがメチャクチャ多い。
| 2009 年 4 月 25 日 | 01:09:22 | DoCoMo | NEC LCD2190UXi | DoCoMo/2.0 P05A(c100;TB;W24H15) (compatible; BaiduMobaider/1.0; +http://www.baidu.jp/spider/) |
いや、まぁ引っかからないのは寂しいので、ロボットが来るのはかまわないんだが、昨日だけでBaiduのアクセスが3,000件。根こそぎクロールしてくので、うざいったらありゃしない。まあそれほどトラフィックの多いサイトでもないので取りあえず撥ねつけることはしませんけどさ。なんかStatPressで見るときに、一般ユーザの方よりロボットが多いと、少し萎えるんだよねｗ
キャッシュヒットしないページばかりキレイに読んでくれて本当にありがとうよｗ
4/26追記 25日には4,500回もアクセスに来てくれやがりました。なので取りあえずrobots.txtに以下の記述を追加。
User-Agent: BaiduMobaider crawl-delay:300 User-Agent: Baiduspider crawl-delay:300 user-agent: Baiduspider+ crawl-delay:300 user-agent: BaiduImagespider crawl-delay:300
これで少しはアクセス頻度減ってくれるといいのですが。またレポートします。
5/5追記
だめだ、全然へらねぇ…orz。百度が早く日本から撤退しますように。お祈りすることにした。
5/20追記
StatPressを見ると5月7日くらいから減っていって、現在は許せるレベルにまで落ち着きました。robots.txtへの反応遅すぎだろ…。
自分が業務でやってるサービスに百度から、「クロールさせてん」と来たらしい。サーバ管理者は百度を弾いていたらしい(笑)。まぁ、仕事で使ってるサーバは巨大なので百度が来てもそれほど問題にならんでしょーしね。
考えてみれば、一番最初に自分が仕事で使ったWebサーバ(PentiumIIの450MHzでした)より今のML115G1サーバの方が遙かに強力なんだけどねぇ…。
WordPressの動きを見ていて、どーももっさりだな、と思っていました。もっとも記事を閲覧するだけならそれほど影響はないのですが、プラグインのStatPress(アクセス状況を解析するプラグイン)を使っているとレスポンスがあるまでにかなりの時間がかかってしまいます。
そこでWordPressにWP-Super-Cacheをインストールしたのですが、管理者用のコンソールは高速化されるわけがないｗそりゃ、管理系がキャッシュされて最新情報見られなくなったら困りますわな。というわけで、MySQLのキャッシュ設定を見てみると、キャッシュが設定されてないことがわかりました。なので、/etcにあるmy.cnfに以下の一行を追加。
query_cache_size = 32M
これだけでMySQLのキャッシュが始まります。もちろん再起動(reload)しないといけませんが。
[root@main ~]# mysqladmin -u root -p variables | grep query_cache Enter password: | have_query_cache | YES | query_cache_limit | 1048576 | query_cache_min_res_unit | 4096 | query_cache_size | 33554432 | query_cache_type | ON | query_cache_wlock_invalidate | OFF
てな感じで実際にキャッシュが効き始めたかチェックすることができます。
これでだいぶ動きはよくなるかと。そして、動作状況を今度はcactiで確かめたい、ということでMySQLの動作状況をcactiでチェックできるテンプレートを探してみました。色々とあるのですが、簡単に設定できそう、ということでmysql-cacti-templatesというのを使います。このページへアクセスして右側のFeatured Downloadからダウンロードしてください。
今朝方に無事UPSが到着しました。バッテリーが入っているだけあって、重い。取りあえず充電しなければならないので、充電だけして会社へ出勤。ES500は最初充電するのに12時間以上、ということでちょうど帰ってくる頃には満充電になっているはず。
家に帰ってセットアップという楽しいことが待っていると、会社でも楽しく仕事をできますね(棒読み)
さて、自宅にとっとと帰ってすぐにセットアップ開始。取りあえずサーバには接続せず(稼働状態なので明日の朝にでも切り替えるとします)、ES500に付属しているUSBケーブルをサーバであるML115G1に接続してセットアップしようという手順です。
しかしながら、ES500はパーソナル製品なのでLinux用の検知ソフトウェアはメーカからは用意されてません。ただ、apcupsdというソフトウェアがありますので、それを使えばCentOSでも使うことができます。というわけで、さっそくインストールだだだ…。
自分のサーバはSo-netの回線なのですが、14時半ごろに会社で見ているCactiがいきなりつながらなくなりました。あり？と思ってPingをしてもダメ。どうやら回線が死んだようです。千葉でトラブっている、という情報がありましたが、東京も影響したのかな？
回線が復旧したのか、サーバからはメールが届くようになってきたのですが、肝心のWebがつながらない。Dynamic DNSの設定がちゃんとしていないのかしら。つながらないのは仕方ない…家に帰るまで待つか、と思ったのですが、サーバからのメールヘッダにIPアドレスがありました。そのIPアドレスを直打ちしてログイン、と思ったのですが、また回線が再接続くらったらしくログインできない。次の定期メールが来るまで1時間あるので、それを待ち、やっと2時間後にログインまでいきました。
IPアドレス変わったら携帯にメールするような設定にしておこうかな。そうすればトラブルに気づくのも早いし。
回線接続したのに、ネームが引けない理由はサーバの入れ替えをした際に、DiCEの設定しくじっていたためでした。ホスト名に「＊」を指定しないといけないのに、空っぽになっていたために、VALUE-DOMAINのDNS設定がしくじっていたようです。おかげでネームを引くまでに3時間費やしてしまいました。
しかし、常時接続しっぱなしだとSo-netさんはイヤなんでしょうか？一ヵ月に一度くらいは全部リブートしてチェックしてみるかな。