2010年05月21日　(2010/05/21 23:59 )

ルータ置き換えで通信遮断は解決？ほかサーバ安定化作業

　カテゴリ : デジモノ　タグ :

■2010/04/24 [ルータ置き換え続報(OPT100E⇒XR510/C)、一応通信遮断は無くなった・・・？]
ひとまずちょっと落ち着きそうな雰囲気にはなってきました。
というお話をしていた例の通信遮断の件ですが、4月中旬にルータを
OPT100E から XR-510/C に置き換えてからはや1ヵ月、どうやら
それらしい通信遮断は確認されなくなりました。
　

　
はっきりした原因は特定できませんが、特定の通信が大量に
発生することによる、ルータ(OPT100E)側の 暴走だった可能性
が高いような気がします。まずはこれでほっとひと安心です。
　
なお、これとは別にサーバ負荷の面から数分～10分くらいのレスポンス悪化が発生するケースは何度か見受けられます。皆さまにはご迷惑をお掛けして大変申し訳ございません。こちらは全く別の問題ですので、それも含めてサーバの安定運用のための工夫を続けていきたいと思います。。。
という件についても色々と原因の調査と対処を検討していたのですが、
これに関してはあまともの価格チェックプログラムが高速化したことが
主な原因だったことが分かりました。
　
■2010/03/01 [Amazon APIの”ItemLookup”は、ItemIdを複数指定できたというお話]
　
APIコールで 1回あたり10件 の価格を取得できることが判明し、
早速10件ずつ取得するように変更しました。AmazonのAPIは目安として
1秒に1回までという頻度上限がありますのでそれを守っているのですが、
これによって1件/秒⇒10件/秒まで速度が向上したことになります。
　
ところが、価格チェックプログラムでは各商品について 「最終確認日時」
という日付をアップデートしている部分があり、この部分が
「1秒に1レコード更新」だったところが 「1秒に10レコード更新」
へと化け、これが ディスクI/O にかなりの負荷を掛ける状態になっていました。
　
結局この「最終確認日時」のレコードは 1分ぶん(600件) を
まとめてアップデートするように変更したところ、
ディスクI/Oに起因する負荷はほぼ収まった状態となりました。
　

　
この場合、もしプロセスが途中で落ちたりすると「本当はチェックした
はずなのに日付が更新されていない」という 不整合 が発生するのですが、
冷静に考えてみると、価格が更新されたときならともかく、価格が更新
されていないときのチェック日時がちょっと更新されなかったからといって
サービスに大した影響があるわけではありません。ということでしばらく
このまま運用してみようと思っています。
　
ちなみに上記グラフを見ると、午前3～7時頃に異常に高い負荷の時間が
続いているほうが気になりますが、これはコミックダッシュ！の各種の
オススメ（レコメンド） をバッチで計算しているときの負荷だったりします。
こういうのも真剣に見直せばもっと色々減らせるのかもしれません。
　

　
このマシンは2006年に組み立てたもので、さすがにそろそろ最新の
サーバマシンを1台組み立てたいなと思っていたり、どうせやるなら
SSD も使いたいけど高いよな、とかアレコレ妄想してみたりする日々
なのでありますが、こうやってみると新しいハードを欲しがる前に、
まだまだできることは一杯あるのだなということが身に沁みてわかります。。。