【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part14
レス数が950を超えています。1000を超えると書き込みができなくなります。
peko作戦について語るスレです。
サーバの新ロケーション、PIEに関する話題もこちらで。
現在の主要なテーマは、
・新ロケーション、PIEの安定化
・pekoサーバ突然死の原因究明
となります。
レンタルサーバー maido3.com ２ちゃんねるの転送量: http://server.maido3.com/pie/
MRTGによる統計情報: http://mumumu.mu/mrtg/
２ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html
PINKちゃんねるで現在進行中のama作戦については、こちら。
【Project ama】PINKちゃんねる特化型ｻｰﾊﾞ構築作戦 Part2
http://qb3.2ch.net/test/read.cgi/operate/1082721809/l50
携帯電話特化型サーバ構築作戦については、こちら。
【Love Affair】携帯からのアクセスに対する考察・次の一手 Part1
http://qb5.2ch.net/test/read.cgi/operate/1075887465/
前スレ
【Project peko】2ch特化型サーバ構築作戦 Part13
http://qb5.2ch.net/test/read.cgi/operate/1085678587/ >>848
このところ特によく落ちたので、シングルCPU設定に一時的に変えているせいですね。(>>821 >>824)
シングルCPU設定だとマシンが落ちることはありませんが(LA=600とかなっても落ちない)、
Cobraサーバの場合、半分以下のパフォーマンスしか出ないようです。
これまでのgame6等でのCobraサーバの不安定の原因も、
マルチプロセッサモードでの動作の問題ということで、ほぼ間違いないようです。
これがFreeBSDのバグなのか、サーバのBIOSの問題なのか
(BIOSの更新で直る場合があったらしい)、
あるいは他の原因なのかは、まだわかっていません。
なお、Tigerサーバも同じ傾向の模様(少なくともex7では)であったため、
現在Cobraサーバ同様にシングルCPU設定になっています。
Tigerの場合Cobraほどの激しい性能低下はないみたいですが、
FreeBSD 4.x/HE.NET時代のパフォーマンスは、出ていないです。
オリンピックに向けて、
落ちてもその都度リブートをすればいいということで、
マルチプロセッサモードに設定してみますか？＞live8/live16/live17
そうすれば、今の倍以上はいけるはず。 補足:
携帯用サーバ、BBQ/dnscacheとして使用しているCobraサーバは、
マルチプロセッサモードで動いています。
しかし、BBQ/dnscacheサーバは一度も落ちていないし、
携帯用サーバも、それほど頻繁には落ちていない。
特にread.cgiとの相性が悪い模様。 >>854
perlcc を通した read.cgi という手もあるかもしれないですね。
perlcc された bbs.cgi の実績からして。
read.cgi も configure が付いていると、もうちょっと柔軟にコンパイル出来るのかな？ >>855
ん、Cバージョンをやめると言っています? あとは、read.cgiについてmod_cgidsoを入れてみるという手は、あるかも。 >>858
それやるのなら，一応作者なんでサポートします...... >>847
ttp://www.allbsd.org/~hrs/diary/200408.html#d0801
DragonFly BSDについての日本語情報はこの記述が今のところ一番正確だと思う。 バイナリでも毎回起動コストがかかるCと、
メモリに常駐するPHPだと、PHPのほうがよかったりするのかな、、、
>>861 え〜と......バイナリかつ起動コスト (fork/exec) がかからないのが mod_cgidso なんですが．
http://qb5.2ch.net/test/read.cgi/operate/1087199303/82-n
# うpしてる鯖のIPは 203.205.141.7 になってます． おぉ、すばらしい。。
これって、mod_cgidsoの入ってないサーバでは、
単なるバイナリとして動くんですか？ >>863 mod_cgidso に対応するバイナリは通常の実行ファイルじゃなくて
共有オブジェクト（Windows でいえば DLL のようなもの）なので，
それ単体では実行できませんので，mod_cgidso が入ってなければ
従来の CGI を使ってもらうことになります...... google先生に聞いてもほとんど情報がなかったんですが、、、 >>865 まぁ，積極的にプロモーションしてるものでもないので...... >>867
いやまあ2ch用に◆cZfSunOs.Uさんが作ったものですし。 >>867 (w
まぁ，mod_cgidso 作成の経緯は，元々 read.cgi 改良の目的の一環としてと
いうことだったので，その意味では 2ch 発祥であるとはいえるかと...... >>869
しかし、今までのと変えるとなると、「あっそれっ」と変えれないでしょうね。 mod_cgidso＋改良read.cgiで直ったりして・・・
>>855
automakeとautoconfつかえば作れるはずです。
設定ファイルを多少書く必要がありますが。
参照：autoconf / automake を使ってみよう！
ttp://shimaki-hp.hp.infoseek.co.jp/autoconf/book1.html >>869
もしよろしければメールいただけると嬉しいです。
yakin@80.kg ついでなんでふっときますが、
http://who.sakura.ne.jp/
ここにbbs.cgiの有志開発バージョンあります。 >>874 メール送りました．よろしくお願いします． (>>876 これで事態は大きく進展するのだろうか・・・) とりあえず目に付いた >>861 だけ。
んと、いわゆる中間コードをキャッシュするしくみ(PHP Acceleratorのような)を入れないと、
毎回コンパイルがかかるので、PHPのほうが不利ですね。
(乱暴に言ってしまうと、Cで言うと毎回gccが動くようなもの)
PHP Acceleratorはc系のフロントエンドにも入れてあります。効果はかなり大きいですが、
特にamd64系で、たまに挙動不審になることがあるみたい。 PHPはZend Optimzer使えばまだましな模様。
ちなみにフリー。
ttp://www.zend.com/store/free_download.php?pid=13
ソース：PHP-USER-JP ML
ttp://ns1.php.gr.jp/pipermail/php-users/2001-July/000883.html >>883
PHP関連はc系列でいろんなものを実地に試してみて、
結局APC Acceleratorが一番効果あったので、それにしていたりします。
Zend Optimizerも試してみましたが、それなりに効果あるものの
APC Acceleratorとの併用ができないみたいでした。
これとか、
http://www.php-j.com/tutorial/php/phpA.php >>884
あらら、既に検証済みでしたか、スマソです。
公式メンテナの最適化ツールより効果ありとはね・・・
これ以上やろうとするとバイナリ化でしょうけど、Zend Encorderは高い・・・。
そこでperlccのphpバージョンが無いか探したらこんなんみつけました。
PHPCC ttp://www.phpcc.net/
ただ、サイトがドイツ語なんですけど。。。 >>885
あ、それ以前に
・Zend encoaderはFreeBSD非対応。。。
・phpccはDLに要登録っぽい 9月頭に、つかの間の夏休みを米国西海岸で過ごそうと算段中。
休みの都合で、2泊4日の強行日程だったりして。
完全プライベートなので、今回はこないだの5月よりはまとめて確保できると思っていますが、
滞在中に現地で可能な作業としては、何があるかなと。
- Cobra, TigerのBIOSの更新
- リモートコンソール関連作業
- ちょっと強気なOS(current., snap, beta等)を入れてみる
あと他には↓ >>888
してる暇無いとおもわれ
>>887
強気OS投入するんなら言うまでも無くLive系かexでしょう。。。 > 887
>
> - ちょっと強気なOS(current., snap, beta等)を入れてみる
FreeBSD5/Netnice。
9月頭であれば、現地までお伺いして作業を手伝わせて頂けまつ。
といっても、まず、パッチを作らなければダメですけれども。
今の予定であれば、9月までにはなんとか...。
これ、今の2chでdual CPUでシステムがハングアップしてしまうことと関係あるんだろうか。
今はオフ(FreeBSD 5.2.1のデフォルト)、currentではオンになっているようにみえる。
# ADAPTIVE_MUTEXES changes the behavior of blocking mutexes to spin
# if the thread that currently owns the mutex is executing on another
# CPU.
options ADAPTIVE_MUTEXES >>891
怪しいと思うのであれば適当な鯖でオンにして試験をしてみませう。。。 >>892-893
もうちょっと調べてみてから、ex7で実験してみますか。 tiger509 , 510
到着しました
tiger509 = news19.2ch.net with ジンギスカン予備工事
tiger510 = hobby7.2ch.net with ジンギスカン予備工事
でお願いしますー ということで、
# ADAPTIVE_MUTEXES changes the behavior of blocking mutexes to spin
# if the thread that currently owns the mutex is executing on another
# CPU.
options ADAPTIVE_MUTEXES
の機能を有効にして、
# MUTEX_WAKE_ALL changes the mutex unlock algorithm to wake all waiters
# when a contested mutex is released rather than just awaking the highest
# priority waiter.
options MUTEX_WAKE_ALL
の機能をcurrentから5.2.1Rにバックポートしてみた。
ex7でSMPをオンにして実験開始。さてどうなるか。 さて、儀式いきます。
以下をDNSに追加お願いします。
+news19.2ch.net:206.223.152.65
+hobby7.2ch.net:206.223.152.70 デュアルCPU設定だと、全然強さが違うなぁ。< ex7
さくさくだ。
>>898 が当たりであることを心底から祈っちゃうなぁ。
でも、デュアルCPU(SMP)問題であることがほぼ間違いなくなり、
かつFreeBSD 4.xでは顕在しなかった部分だとすると、
5.xで導入されたmutexまわりというのは、そんなにセンス悪くないような気がするんだけど。 ex7落ちましたな。またシングルに逆戻り(´･ω･｀) ▼ハヽヽ▼
／|＼（ ´ Д ｀） ＜人柱人柱んぁんぁ♪
⌒⌒''（Ｕ 後 ）
▼〜し'~し' やっぱ、ハングした瞬間をDDBとかでとらえられないと、手がかりがなぁ。
そうすると、やはりリモートコンソールってことになるのか。
とりあえず
「デュアルCPU設定だと死ぬ」「同一ハードでもシングルCPU設定なら死なない」
「ACPIは落ちることには関係ない」(以上amd64/i386双方とも)
「options SMPでも、device.hints的にAPICを切れば死なない(amd64の場合)」
「負荷にはあまり関係がないらしい」
というところまで絞れたわけで、全く停滞しているわけではないけど。
で、どうも、プロセスが多く起動・終了されるマシンで、落ちる可能性が上がるように見える。
携帯サーバで使えばLA=50でも死なないのに、掲示板サーバだとLA=2でも死ぬ。 そんなわけで、やはり原因はハードウェアの不良ではなく、
ソフトウェア的問題である可能性が濃厚と。
Googleするとこんな記事があったけど、そんなことあるのかなぁ。
Re: 5.2.1-p9 kernel hang (unknown reason, but more info)
http://lists.freebsd.org/pipermail/freebsd-smp/2004-August/000588.html
>
> In my opinion, it was kern.ipc.nmbclusters causing the problem.
> now I've set it as default: kern.ipc.nmbclusters: 25600 次上がったら、>>915 にあるように kern.ipc.nmbclusters 等の値をデフォルトに戻してみるか。< ex7 新しい技術に挑戦する心意気はいいとおもうけど
人が多いところでわざわざ実験やる意味がわからない
嫌がらせですか？そうですか･･･ なんて嫌味もいいたくなる･･･
まぁとにかく頑張ってなおしてくらはいな ｼｸｼｸ そうやって文句を言ってくれると隔離鯖に押し込んだ甲斐があるというものだ ヽ（`Д´）ﾉｳﾜｧｧｧﾝ みんながいじめるぅ･･･ 人が多いってことは、広告収入源でもあるんじゃありません？
（専用ブラウザ率は多いかもしれないけど）
そういうところの稼働率は高く維持しないとって普通は考えるとおもうんだけど どこかで実験しなきゃね。
>>917は誰がどうやってサーバーを速くできるんだと思っているんだろ。
>>922
じゃあもっと良いアイデアを出してサーバー構築に貢献したら？ 人が多い所で上手くいけば人が少ない所でもたいてい上手くいくって事だからね。
逆は無理だけど。 >>924
２ｃｈの収入源とか気になってたんだけど、
人の多い実況とか、狼とかで
３００レスに１レスくらい広告を挿入すればどう？
このくらいなら文句も出ないと思うけど どこかの企業から金を貰って、ライバル企業を貶めるという
逆CMというビジネスモデルを思いついた 動きが無いのが心配ですが、
復旧がんばってください
ちょっともんくいっちゃいましたが、よろしくお願いします 難民板の惨状ってオカシクねえか？
だいたい普段から常駐してるヤツらの方が板違いだし
管理サイドが板の設定をゆるくしてるんだから
それに見合った使い方をしてくれってことだろ OpenBSDでDualCPU実験希望...... >>933
OpenBSDのネットワークスタックのパフォーマンスについて検索してみ ＞８８７
レイヤーの高い人の承諾があれば
ＢＳＤ４．０ｗｉｔｈTigerでdualの性能をば・・・・
と後戻りちょっとしてみるテスト
といっても、新規導入じゃないと、どうにゅうにもならないのか・・・ﾅ さて、次の一手は。
>>915 あたりを試してみるか。
でも、携帯用サーバ関連のほうが優先度高いかも。 6-CURRENTができて、RELENG_5ができたのかな。 今の私の目標は
http://ch2.ath.cx/load/
ここのグラフで終日全サーバグリーンだったり、 今日は本業が泣ける状態だったりするけど、
自分の手元のマシンにRELENG_5を入れてみたりして。
RELENG_5_2→RELENG_5への更新手順のとても適当なメモ
Version 1.0 2004/8/19 root ★
・Apache等のサービスを落とし、かつ自動で上がらないようにする
・/etc/rc.conf的にkern_securelevel関係を一時的にコメントアウト
・rm -rf /usr/obj
・/usr/src/sys/{i386,amd64}/GENERICからWITNESSとかDDBとかコメントアウト
・vi /usr/src/standard-supfile して、CVSタグをRELENG_5_2からRELENG_5に
・cd /usr/src; make update
・make buildworld
・make buildkernel
・make installkernel
・リブート
・dmesgを確認、保存
・cd /usr/src/usr.sbin/mergemaster; make -m /usr/src/share/mk all install
・mergemaster -p
・make installworld
・mergemaster
・リブート
・dmesgを確認、保存
・kernelカスタマイズ
・リブート
・dmesgを確認、保存
・kern_securelevelを元に戻す
・リブート
・Apache等のサービスを上げて動作確認してみる
・サービスを動作確認して問題なければ、自動で上がるようにする
・最終リブートテスト あとは、
・前の/usr/src/sys/{i386,amd64}/GENERIC をとっておいて比べてみる
・/usr/src/UPDATING に目を通す
・/usr/src/sys/conf/NOTES に目を通す
ぐらいか。
もうすこししごとしてからかえろう。しくしく。 あ、あと、
net.inet.tcp.inflight_enable=1 はいらないみたい。
で、net.inet.tcp.inflight.enable にかわっているみたい。 >>940 をex7とlive8あたりで試してみたい気もするけど、
たぶんそれはPIEに行った時だなぁ。
さて、ぼちぼちかえるかな。 RELENG_5をcvsup中〜
結構時間かかるし、cvsサーバ混んでますね。 allbsdとかもつかえるよ。
あとcvsup-mirrorを一つ建てて置いて管理下のサーバーはそこにcvsupするようにするのが吉。
うーん、uname -rすると、5.3 ALFHAになるぞ
まだ、5-STABLEは先かな？ >>947
さっきCVSupしたら5.3-BETA1になった。
PIEに行く頃にはどうなるかなと。
# めしいってくるか。 そろそろ次スレの季節なので立てようとしてみるテスト レス数が950を超えています。1000を超えると書き込みができなくなります。
