【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part14
■ このスレッドは過去ログ倉庫に格納されています
peko作戦について語るスレです。 サーバの新ロケーション、PIEに関する話題もこちらで。 現在の主要なテーマは、 ・新ロケーション、PIEの安定化 ・pekoサーバ突然死の原因究明 となります。 レンタルサーバー maido3.com 2ちゃんねるの転送量: http://server.maido3.com/pie/ MRTGによる統計情報: http://mumumu.mu/mrtg/ 2ちゃんねる/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/ >>800 乙です しかし、男女別ですか・・・・w なお、INDEX丸見えですので早いうちになおしませう >>800 あれれ さっきは見えたんだけどなぁ 今丸見え 一時的にLA=200ぐらいいったけど、それなりにゆとりあったような。< ex7 ジンギスカン(メモリディスク)+思い切ったセッティング(httpdの最大数を増やしてある)の効果か。 live16, live17でsubject.txtの飛びが多発。 mdmfsの設定を変更。 従来: /etc/fstabで以下のように設定。 md /md mfs rw,nosuid,noatime,-s20m,-i2048 0 0 現在: 起動時に以下のコマンドを実行。 これにより以前と比較してmallocベース、softupdateなし、asyncに変更。 mdmfs -M -S -o async,nosuid,noatime -s 20m -i 2048 md0 /md 再度変更。asyncをやめ、sotupdateを復活。 mdmfs -M -o nosuid,noatime -s 20m -i 2048 md0 /md ttp://www.janog.gr.jp/meeting/janog14/abstract.html#07231600 DNS Demystified 〜 あなたの知らないDNSの世界 このPDFは興味深かかったよ。 dnscacheのmultilogは確かに負荷がでかいな。 あとWITH_PERSISTENT_MMAPするとbindと勝負できると思うのだが。 PCI接続のシリコンディスクにdatを置いといてHDDにミラーする というのは素人考え? >>809 ttp://www.cenatek.com/store/category.cfm?Category=15 だと1GBで999ドル、4GBで2999ドル。 懲罰鯖か実況鯖用に1GB入れて実験してみるのもいいのでわ? >>809-810 たぶん1Gもいらないんですよね。 だって、public_html/livecxとかの下をまるごとシリコンに入れることになるだけだから。 今もdatとkako以外を入れてますが、20Mとかで足りています。 kakoはシリコンディスクにする必要ないから、ライブなdatが増えるだけすよね。 ジンギスカンの設定見て「あぁ、おじさんにまたやられた」と思いました。 実はライブな掲示板をライブに動かすだけなら、ディスク容量はそんなに食わないわけです。 >>811 ここ数年の実績からするとスケジュールから大体数ヶ月遅れでリリース >>815 クリスマスプレゼントにでも間に合えば御の字ってとこか? >>817 シリコンディスクというのはCompactFlashではなく DRAMで構築されていますから機械的な寿命というのは実質的にありませんよ。 そりはフラッシュメモリと間違えてない? シリコンぢすくは、余ったDRAMかSRAMをバッテリーバックアップして ATAなりなんなりに変換している。 live8: hint.acpi.0.disabled="1" だと落ちなくなるけど、シングルCPUモード、かつ全然パフォーマンスが出なくなるので、 hint.apic.0.disabled="1" に変更。APICを切ってしまうので、やはりシングルCPUモード。 >>820 ひさしぶりにみたような。 >>821 ひさしぶりに来ましたヾ('-')ノ 久しぶりに来たらシングルCPUになってるのね・・・('-';) >>822 いろいろな道をたどって、 1) read.cgiを起動する状態だと、Cobra/Tigerともに突然死しやすい で、どうやらそれは負荷によらない 2) Tigerサーバ: ACPIを止めてSMP/APICを切り、シングルCPUにする Cobraサーバ: APICを切ってシングルCPUにする ことで、1)の状況は起こらなくなる 3) Cobraサーバは、超高負荷の後の中負荷ぐらいの頃に落ちやすい というところまでわかりました。 個人的には現在、特にCobraサーバのBIOSまわりとか、 FreeBSDのACPI/APICまわりのコードなどを、最も疑っていたりします。 特にFreeBSD 4.x/i386では起こらなかったハングアップが5.x/i386で起きているあたりが(りゃ。 >>811 10月3日リリース予定・・・ですか。 まあ気長に待ちましょう。 RCが出た段階でexを人柱にしてみるテストを実施するのもありかも。 これが出ない限り?は新しいpeko/Cobraは投入できないわけですし・・・。 >>824 はコードの問題<バグ>が最有力でしょうし。 blackgoat.2ch.netサーバのLAがみたいんですけどみれますか? >>824 おつかれさまです('-'=) 違う機種で同じように落ちるのは、OSっぽいって事ですか ついにWindowsServer導入?!ヾ('-')ノ 選択として仮Linuxとかは無しなの?('-'?) そういえば、、、なんでバナーナは落っこちないのー?(?-?) >>829 OSっぽいか、BIOS問題か、あるいはその両方か。 で、結局のところシングルCPUモードに設定すれば落ちないと。< Cobra, Tiger そういえばbananaはPen 4 singleですが、シングルCPU設定(SMP/APICなし)のほうが FreeBSDでは高パフォーマンスで動きますね(手元のマシンでいくつかベンチマークしてみた) Pen4のHTT/FreeBSD 5.xだと、SMPするオーバーヘッドのほうが性能向上を上回っている模様。 Linuxは別にきらいなわけではなく、単純に私の経験値がないだけで。 ACPIなしにするとCobra同様TigerサーバもディスクI/Oのパフォーマンスがとても悪くなるので、 ACPIを有効にした。これで本来予定していたディスクI/O速度になるはず。 ただしAPICを切っているので、あいかわらずシングルCPUモード。< Cobra/Tiger >>831 えーと去年の秋ぐらいにも同じことを聞いたかもしれませんが、念のためってことで。 HyperThread有効のときは/etc/sysctl.confで machdep.cpu_idle_hlt=1 machdep.hlt_logical_cpus=0 をしてますよね? >>833 FreeBSD 5.2.1なので、上記はデフォルトで1かと。 %sysctl -a | grep machdep.cpu machdep.cpu_idle_hlt: 1 下は、FreeBSD 5.2.1にはないような。 あ、そっか。 今options SMPを切っているので、出ないです。< 下 HTバナナーのパフォーマンスアップの可能性?ヾ('-')ノ 今のbananaは全部HTT切ってある気がします。>>836 machdep.cpu_idle_hltは非SMPの時はデフォルトで1なのですが、SMP時はデフォルト0に。 あと後藤大地さんの去年の冬あたりのUNIX USER記事にいろいろとHTT時の最適化は書いて有りましたね。 5.2.1Rの機能紹介記事だったかな。 >>828 教えてくださってありがとうございました >>787 マンコって言わせたいんだな。いいでしょう! 言ってみます、マンコ! >>842 ( ´д)ヒソ(´д`)ヒソ(д` ) >>807 ようやく読みました。とても面白いですね。 DNS/BINDの内部を(しかも軽視されがちなDNSキャッシュサーバの振る舞いについて) ここまできちんと調査した結果は、初めて見たかもしれません。 2ちゃんねるの場合DNSキャッシュサーバを軽くできると、 それはそのままbbs.cgiの軽量化に直結するわけで、 このあたりはいずれまた、じっくり試してみることにします。 >>840 ちょっと前から話題のしろものですか。 「FreeBSD 3.xは間違いだった、FreeBSD 5.xはさらなる間違いだ」でしたっけ。 意外にFreeBSD6とかあたりで、DragonflyBSDで入った機能が相当取り込まれたりして。 live8 ですが先日までは 450/min の書き込みをこなしていたのに 現在は 200/min でへこたれるのはなぜなんでしょか? http://ch2.ath.cx/load/live8.html >>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をオンにして実験開始。さてどうなるか。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる