usamimi.info

本日(8/14)から来週(8/18)まで、私の職場もお休みです。
短い夏休み、あるだけまだマシだと思っています。

サーバーが置いてある部屋に私のマシンも設置されていて
そこで作業やらゲームやらをしているのですが
エアコンがまったく効果無く、扇風機数台を回しっぱなしにしています。
暑いです。
ダンボールでダクト作ってみたりして地味な努力を続けてみたり・・・

週末には、あのイベントがありますが
今年は参加しない、流れになりそうです。

usamimi.infoに住んでいる方も、もちろん参加する人が居ると思うのですが
usamimi.infoに居を構えるサークルさんってどの位いるんですかね・・・
会いに行ってみたいなぁなんて思いつつ
暑い中作業してます。

職場からコッソリ、ページを見る限りでは、特に繋がり難いという状況は無いように思われますが
報告頂いた中には、携帯で表示し辛い状況にあるようです。
デフォルトまで調整を戻してしまうと、以前のようにセッション数のリソースが枯渇してしまう為
どこまでデフォルトに近い数字まで戻せるのかが鍵になるかと思われます。

現在の調整状況は以下の通り
カッコ内の数字は、通信完了後念の為コネクションを維持しておく時間です。
メインサーバーで20秒（40秒）
各画像処理サーバーで25秒(50秒)
デフォルトでは、30秒(60秒)になります。

行うとすれば、メインサーバーの設定を25秒(50秒)に調整するぐらいかと思われます。
やはり携帯電話のブラウジングは、遅いのでしょうか。
サーバーが重いだけという事もあるかもしれませんが
メインサーバーの負荷はかなり下がってきています。

勢いで取ってしまった、たぶん後悔はしていません
leaf-clover.netと合わせて、まだ用途は決めかねています。

気付いている人もいるかもしれませんが
usamimi.infoのSSL証明書は、とんでもない証明書になっています。
この紅い認証局を、remilia.infoで運用して、誰でもSSL証明書を発行できるようにしようかと思っています。
無論、ベリサイン等のようにブラウザにデフォルトで組み込まれている認証局ではない為
利用する方は、CA証明書をブラウザに組み込まなければならない制約はありますが
一度組み込んでしまえば、同じ認証局から発行されたＳＳＬ証明書は特に警告無く使用できます。

完成は何時になるか分かりませんので、今の所はusamimi.infoと同じようにページが表示できるようになっています。

usamimi.infoといいつつ、うどんの人より紅い悪魔の方が好きなのです。
すみません。

参考URL
http://www.sato-bb.net/archive/tech/tune/time_waitmsl/

CPU負荷も大したことなく、IO負荷も大したこと無い
ルーターに余力が無いわけでもない
それなのに、サーバーに繋がりにくいという事象

時折topコマンドを確認するとsystemの負荷が上がってるように見えます。
原因は定かでは無いですが

ネットワークのコネクション数が負荷に関わりがあるとの事で
上記URLに記載されているコマンドでTIME_WAIT時間を60秒から10秒に変更しました。

結果、詰まったような感じは無くなった様に見えますが
内側からでは、この問題を把握することが出来ず、困りました。

--追記
10秒では生存時間が短すぎて、逆に繋がりにくいのではないかと思い
メインサーバーを20秒、他のサーバーはデフォルトに戻しました。

度重なる不具合から退役するはずだったyukitoが負荷対策の為に駆り出されていましたが
先日、WIND PCを導入、yukariとしてyukitoの機能を全て引き継ぐように、構成しました。
詳細スペックなどは、仕様一覧に載せます。
Intel AtomCPUであり
性能的にはyukitoとほぼ同じ程度になると思われます。
既に引継ぎは済ませ、約5年に渡りusamimi.infoの構成に関わってきたyukitoは停止しました。

構成の変更が発生した為、昼間は繋がりにくい時間帯があったかもしれません。
今後、yukariにはusamimi.infoの一端としてより良い働きをしてくれる事を期待しています。

この所続いている、重たい時間帯があるとの事ですが、usamimi.infoの内側からではその状況が把握できず
CPU負荷が極端に掛かっている等の分かりやすい原因では無い為
何時、どの位重たい時間が発生していたのか、報告して貰えると何か原因が掴めるかも知れません。
何にしても、今は手探りで調整を行っている為、不安定な状態が続いています。

この所、深夜になると、アクセスが重くなるといった症状があるようなのですが
今までは、単にルーターの力不足で、重くなるといった事が普通だった為、調べてみると
3台あるうちの1台、PCルーターのcirnoがかなり厳しい状態にあることが分かりました。
pppの他にnatdも稼動しているのですが、こちらは再起動させう事で、軽くなることを確認していたので
pppの再起動ついでにマシンを再起動させました。
今の所、CPU負荷は、80%近くあったものが、数%まで落ちています。
深夜にならないと結果は分かりませんが、期待はできそうです。
やはり、RTXのような専用機器と違う為なのか、定期的に再起動をかけてあげた方がよさそうです。

この他、yukitoが亡くなって以降
DBサーバーをmarisaに暫定的に移していますが、相当な高スペックである為、特にチューニングは必要ないだろうと
デフォルトで運用していましたが、先日ユーザーのBlogにて、実行時間が長い為に、アクセスが残り続けているような感じになっている事を発見した為
ユーザー自身に対策のお願いと、MySQLサーバーのチューニングを行いました。
割と贅沢にメモリを割り当てたので、負荷の改善に繋がることを期待しています。

負荷は、無いに越したことはありませんが
サーバーにおいて、困る負荷は、短時間(1秒程度？)に高負荷になるようなスクリプトよりも
長時間にわたって、サーバーに残り続けるスクリプトの方が危険になりやすいのです。
っと言うのも、接続しっぱなしになった場合、サーバーの他にルーターのコネクションを掴み続ける為
その接続を維持する為にルーターのメモリも使い続けることから
この状態が多数になった時、他のユーザーの接続が受け入れられなくなったり、CPU負荷が上がって遅くなる為に
接続が遅い、重いなどといった症状がユーザー側で現れるのです。
＜サーバーに負荷が掛かっている事が原因であることもあります

--2008/08/05追記
負荷を調べていった所、IO負荷が大きいかもしれないということが分かりました。
RAIDを構築するか、さもなくばサーバー分割がもっとも効果的であると思われますが
現状そこまで出来る時間も余裕も無いため
画像などを処理しているr-moon、yukitoのメモリキャッシュを増やし、受け入れるクライアント数を増やしました。
--2008/08/09追記
メインサーバーのWEBサーバーをチューニングしました。
受け入れられるクライアントの数を増やし、より待ちの状態になり難いよう設定しました。
ただし、これが原因である可能性は高くは無いと思われます。