アーカイブ

February 2007のアーカイブを表示中です

おっ、JSNの文字が…!

…という訳で、コンビニ決済がスタートします!
これだけ別途手数料(200円)かかってしまいますが、今までもご負担いただいていた銀行での振り込み手数料より安くあがる人は是非是非ご利用ください!*1

  • *1Clearの場合は埼玉りそなのネットバンキングなのでどこへ振り込むにも100円で済みます
この記事はこれで終わりです。

無知は無知と言いたい。無知なくせに知ったかぶりしてお客様に甚大な被害が及ぶより全然マシです。
無知であることを知らしめることは恥ずかしいことではなく、これから吸収する可能性と意欲をあらわしていると、そう思います。(自己弁護w)

さて、本題ですが、Apacheにおける負荷制御のシステムがよく理解できません。
/etc/security/limits.confをいじる方法(ulimitと同じような制限方法だと思う)だと*1、apacheからwrapされるプロセスには働かないようで*2、結局無限ループCGIのプロセスは10個くらい全部立ち上がりました。*3かといって、ユーザーapacheにその制限をかけるとするととんでもなく面倒なことになりそうなのでできないしな…。*4

さくらの人が公開しているmod_access_limitはApache1.3系での実装なんですよね。
Netniceという機構が非常によさそうなのですが、やはりLinuxでの対応はアルファリリースであることを考えると、本運用できないと。(最終更新日が2005年ですし)
とりあえず、Netniceのページで例示されていたいくつかのモジュールを試してみます。

たしかmod_bwshareはJSNでも帯域制限で入れてたはずなので、これで接続数を制限する方向が今のところ妥当な線でしょう。

ただ、これだけでは根本的解決にならないんですよね…。
SpamAssassin→spamc にすることとかもしないとです。*5
というか、メールサーバーを分けたりする方向を訴えているのですが、なかなか通りません*6
今のサーバーは1台でいろんな機能をまかなっているので、重くなる原因がいっぱいある。
これを切り分けできればいろいろと楽になるのですが、ここまで大きくなると集中メンテとかで数時間ダウンさせないと修正できないレベルになってきてますね…。

うお。ここまで書いて気づいた。
同じ内容のエントリーを6月にも書いてますねorz
あ~。懸念事項がやっぱりこうやって現れてきてしまいました。

春休み使って少し案を練ってみます。

  • *1これはApacheというよりもLinuxのシステム的に制限をかける方法です。
  • *2いったんApacheによって起動した後にユーザーに権限を振る?
  • *3そのユーザーには5個の制限をかけてテストしてみたんですが…。
  • *4要するにサーバー全体で立ちあがるCGI数の制御になるので、ユーザーごとの負荷制御にならない
  • *5大々的に書いてますがすぐできるだろ>俺
  • *6予算的に
この記事はこれで終わりです。

懲りずにリニュも計画してたりしますが、とりあえず、3月に入るまでに、もしくは上旬に少しJSNが変わります。
詳細は社長に止められているのですが(万全じゃないから)、お客様にも喜んでいただけるんじゃないかな、と思いますよ。

とりあえず、今はエイプリルフールのページをどうしようか考え中ww
毎回ペパボさんはすごいからね~。あそこはうちらも楽しみにしてますw

とりあえず、Webの現在を風刺しようかな。
サニタイズされているから安心です!とか無断リンク禁止です!とか、グラフにするとJSNの方がむしろ安く感じられるとかwwww
少しネタ古いかww

それと同時に負荷対策を考えています。
負荷が原因のサーバーダウンが多発しています。
負荷が高い場合はリモートでの操作を受け付けてくれなくなってしまうので上位に再起動依頼という手に出ているわけですが、その判断が難しいです。

再起動してしまうのは簡単なのですが、実行中のプロセスが全部ふいになるわけで、ファイルの整合性が取れなくなるおそれもあります。処理中のファイルは破損する可能性が高いでしょう。
たいていは未対処のブログサイトへのトラバ、コメントスパムか、長文のメールをスパムアサシンが頑張ってスパムかどうか判断している感じです。
もちろん、すぐさまサーバーを上位に依頼して再起動かけて復旧コースなら10分くらいで終わるでしょうが、それでは対処療法で根本的な解決にならないんです。
とりあえず、最低動いてるプロセスを把握して、どこに問題があったのか突き止めないと、次も同じ高負荷で落ちる可能性があります。
そのため、申し訳ないのですがお時間をいただいて、高負荷状態のサーバーにリトライを大量にしながら接続を試みてなんとかプロセス状態を引き出そうとしているわけです。
とりあえずつながれば何でもいいので、SSHとWebminを10窓くらい開いてリトライしまくるのですが、ちょっとやそっとでは反応してくれません。
社長と二人で試し、お互いダメだ、これは再起動しかないな…。となった時に再起動依頼をします。

ただ、この対処方法はマズいと思いますので、対処方法というか、未然防止をするためのプランを練っています。
ここは、品質にかかわる部分なのできちんとやります。

CPU使用率制限を様々な角度から検討したり、LAが高くなってきたときに自動でランニングプロセスを記録する処理を組み込むとか、そういった面から始めようと思っています。
また、高負荷をかけているユーザーへの警告、退会勧告、強制退会も今までより厳しくしようかな、と思っています。
今までは結構温情措置が多かったのですが、やっぱり一人のために他の100人近くが被害を被る状態は好ましくないです。

こういった面も含めて、早いうちにいいお知らせができればいいな、と思います。

この記事はこれで終わりです。