【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part18
■ このスレッドは過去ログ倉庫に格納されています
peko作戦について語るスレです。 サーバロケーションPIEに関する話題もこちらで。 <現在の主要なテーマ> ・「Love affair作戦」による、携帯系サーバの大幅強化・外向けdat供給サーバの構築 ・「雪だるま作戦」による、スケーラブルなサーバ群構築 ・BBQの2台体制化・RAID1化 ・FreeBSD 5.4Rの導入検討 ・各種作戦・プロジェクトとの連携 ・FreeBSDのさらなるチューニング詰め <主な関連スレッド> 【Love Affair】携帯からのアクセスに対する考察・次の一手 Part3 http://qb5.2ch.net/test/read.cgi/operate/1095146311/ ■新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!? Part1 http://qb5.2ch.net/test/read.cgi/operate/1105035540/ <主な関連サイト> MRTGによる統計情報: http://mumumu.mu/mrtg/ 2ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html 2ちゃんねる サーバ負荷監視所: http://ch2.ath.cx/load/ 2ch 鯖監視係。: http://sv2ch.baila6.jp/ <前スレ> 【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part17 http://qb5.2ch.net/test/read.cgi/operate/1107376477/ 旧バーチャルホストのmemoriesへの収容に伴い、以下の変更をお願いします。 (現在) +money3.2ch.net:206.223.151.140 (変更後) +money3.2ch.net:206.223.151.230 また、Perl祭りかいな。 /usr/ports/UPDATING 20050624: AFFECTS: users of lang/perl5.8 AUTHOR: tobez@FreeBSD.org lang/perl5.8 has been updated to 5.8.7. You should update everything depending on perl. The easiest way to do that is to use perl-after-upgrade script supplied with lang/perl5.8. Please see its manual page for details. あと、これも影響あり。 20050622: AFFECTS: users of ftp/proftpd-* AUTHOR: flz@FreeBSD.org ProFTPd binary moved from ${PREFIX}/libexec to ${PREFIX}/sbin. People using proftpd with inetd must use ${PREFIX}/sbin/in.proftpd (or ${PREFIX}/sbin/proftpd which is just the same). Read the commit log and diffs for more information. >>781 DB_Fileが最新になるのでほのかに期待(苦笑)@現状1.809→1.811 >>783 banana238ですか。 機を見て、Perl更新してみますかね。 /usr/local/bin/perl-after-upgrade を忘れずによろしく。 man perl-after-upgrade も見てね。 >>785 どもです。>>781 にもあるですね。 perl-after-upgradeのお陰でPerl祭りにならずに済むっぽいです。 あと、perlをportupgradeしたとき最後に自動でperl-after-upgradeが走ってたような気が。 # でもチキンなのでモジュールは全部作り直した。 投入予定のtiger姉妹、Perl祭りに対応中、、、。 結局、ApacheからPHP、net-snmpに至るまで全部入れ替えなので、 トラディショナルな方法(pkg_deleteしてmakeしなおし)で入れなおしと。 ううむ、めんどい。 「portupgrade -fすりゃええやん」(松本人志) うーむ。 PAEありのカーネルは、不安定なようです。 ソフトウェアのコンパイルや、パッケージの追加の際に 突然リブートがかかってしまいます。 リモートコンソール経由でいくつかBIOSの設定を変えてみたりしたのですが、 いまだ問題は解決していません。 ううむ、困った。 ここは思い切って、そういった制限のない64bitOSを入れてもらうべきなのか。 >>790 うん。 普通のは、たぶんそれでいいんだと思うです。 でも、make時にいろいろオプション指定しまくっているnet-snmpとか、 Apacheとかは、どうすればいいのかしら。 # このへん、実はあまり知識がなかったり。 名無しはいまいちなので(理由は前にもどっかで書いたです)、 おじゃまする時は、常にコテハンっすね。 しかも伽羅作れないので、常に同じコテハンで。 で、体調がまだいまいちなんで、とりあえずmake通ったところで今日は寝るです。 >792 >でも、make時にいろいろオプション指定しまくっているnet-snmpとか、 >Apacheとかは、どうすればいいのかしら。 俺は/usr/local/etc/pkgtools.confのMAKE_ARGSに 'www/apache2' => '-DWITHOUT_IPV6', 'net-mgmt/net-snmp' => 'NET_SNMP_SYS_CONTACT="admin@example.jp" NET_SNMP_SYS_LOCATION="JUN, Tokyo"', 'security/hpn-ssh' => 'WITH_OPENSSH_CHROOT=y', みたいに書いている。 あとAFTERINSTALLに後処理ワンライナー書いたり。 >>795 なるほど、pkgtools(5)と/usr/local/etc/pkgtools.conf.sampleを読めとゆってますね。 rubyか、、、。 で、PAEの件ですが、手がかりになるかどうかわかりませんが、 突然リブートがかかった時は、dmesgに、 em0: Link is up 1000 Mbps Full Duplex とかしか、残らないんですよね。 で、panicしてもいないので、savecoreも効かないし。 ううむ、何かデバイスドライバのDMAとかに、虫さんがいるんだろうか。 ちなみにそんなに変な構成ではないです。 Etherはemが2つだし、SCSIはmpt。 >>800 Look at kern.maxvnodes and trim is down to a smaller amount if it's more than about 100,000. This of course depends on your workload. If you really need a lot of cached vnodes, then you'll need to tune elsewhere. Scott で、 %sysctl kern.maxvnodes kern.maxvnodes: 100000 ううむ。 あとはこれか。 /usr/src/sys/i386/conf/NOTES # # Change the size of the kernel virtual address space. Due to # constraints in loader(8) on i386, this must be a multiple of 4. # 256 = 1 GB of kernel address space. Increasing this also causes # a reduction of the address space in user processes. 512 splits # the 4GB cpu address space in half (2GB user, 2GB kernel). # options KVA_PAGES=260 >>802 /* * Size of Kernel address space. This is the number of page table pages * (4MB each) to use for the kernel. 256 pages == 1 Gigabyte. * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). */ #ifndef KVA_PAGES #ifdef PAE #define KVA_PAGES 512 #else #define KVA_PAGES 256 #endif #endif これは、一応適切、、、なようだ。 あと、もう一つ(私のチェックが甘かったのですが)、 2台来たtigerのうち片方(SCSI仕様の方)が、dual CPUを正しく認識していないようです。 切り分けのため、PAEなし、SMPありのカーネルを作って、確認中。 PAEなしSMPありのカーネルを作ったところ、ちゃんとCPUを4つ認識しました。 ううーむ。 もう1回、カーネルづくりをやり直してみるか。 しょぼい、ミスをしていました。 カーネル、作り直し。 SCSI版(姉)も、ちゃんとCPUを4つ認識しました。 これで、再度ソフトウェアの入れなおしをやってみるか。 やはり、落ちますね、、、。 何か、セッティング的に必要かなと。 コンソールを見ると、今度はpanicしたようです。 bufdaemonがpanic: page faultしたと出ているです。 しかし、swap spaceが4Gしかとられていないので、dumpに失敗しました。 で、 Fatal: doule fault: ... boot called on cpu#0 と出て、止まってしまいました。 これになると、電源を切って入れてもらわない限り リモートコンソールがあっても、どうしようもないです。ううむう。 …と書いていたら、リブートしはじめました。 作業できるかも。 上がりました。 まずは、/home があるHDDから5Gほどもらって、クラッシュダンプ用のデバイスを作ろう。 >>812 done. これで、クラッシュダンプはちゃんととれるはず。 妹の方も、この設定入れよう。 もう1回コンパイル。 今度は、普通にpanicしました。 さて、ちゃんと立ち上がるのか。 うーむ、dumpはとれたっぽいんですが、 やはり panic: double fault: になるようです。 …で、止まってしまいました。 supervisor read page not present だそうです。ううむ。 で、数分したところで、リブートが始まりました。 やはり、リブートはかかるみたいです。 で、クラッシュダンプはうまくとれていませんでした。ううむ。 とりあえず、 kern.maxvnodes=64000 にして、再度挑戦中。 …って書いていたら、また死にました。 今度はコンソールにpanicも出ずに、いきなり、、、。 ううむぅ。 よく見たら、画面には k とだけ出ていました。 何か表示しようとはしたみたい。 いずれにせよ、今度は完全にハングアップした模様。 Ctrl-Alt-Delも効かないですね。 さすがに、命運つきたか。 …リブート依頼するです。 で、PAEなしのカーネルに替えて、 makeしなおしが全部通るか、検証するです。 これは、明日以降か、、、。 >>root▲ ★氏 よくわかりませんがお疲れ様でした。 明日以降も頑張ってください。 リブートをかけていただきました。 PAEなしのカーネルに換装して、再度トライ。 PAEありではpanicやハングアップを繰り返し、どうしても通らなかったものが、 (具体的にはPHPと周辺モジュールのmake) PAEなしのカーネルでは、さっくり通りました。 もう2回ぐらい同じことを回してみますが、 原因はやはりPAEな気がします。 うーーーむ。 全部消して全部作り直す、を2周やりました。 特に問題は出ませんでした。 とすると、やはりPAE関連でほぼ確定か。 さて、どうするか。 ttp://www.atm.tut.fi/list-archive/freebsd-stable-2005/msg04807.html この辺はヒントになりますかね? >>826 これっぽいですね。どもです。 あとで、スレッドを読んでみるです。 usbd_enable="YES" これを disable にしろってか。 usbd_enable="NO" にして、PAEありのカーネルに再度換装。 だめですね。いきなり死にました。 usbd.c を読んでいますが、/dev/usb? がなければ、 結局何もしないように見えるし。 もうちょっと調べてみるです。 いきなり => make cleanで消している間にいきなり KVMつないでみたら、パニックしてクラッシュダンプをとっている最中でした。 さて。 クラッシュダンプを書いている途中、4032まで書いたところで、 mpt1: IOC Bus Reset: Port 1 Aborting dump due to I/O error status == 0x59, scsi status == 0x0 とか言って、止まりました。 4G以上のダンプは、とれないのか? いずれにせよ、リブート依頼へと。 もうちょっとやってだめなら、64bit OSを素直に入れてもらうか。 リブート要請しました。 …めしに、いってくるです。 お疲れ様です。中国語のページを翻訳して見ましたが 意味不明でした(汗 うーむ。。。 ttp://www.freebsd.org/cgi/man.cgi?query=pae&sektion=4&manpath=FreeBSD+5.4-RELEASE むしろ中国語を英語に翻訳したほうが文法的にベターだとおもいますが>>836 >>837 ttp://www.mezzofanti.org/translation/ ここを使えばいけますね。 『WorldLingo』を使ってばいいみたい。 >>827 翻訳済み ttp://angler.ddo.jp/image/PAE.txt 会議終わって、座席に戻りました。 リブートいただけていました。 これから、>>839 を読んでみるです。 KVA_PAGES=1024 を入れれと。 で、mpt(4) はいまいちかもしれんと。 >>802-803 がらみですね。 やってみるか。 >>841 を入れました。 ちょっと、空きメモリが減りました。 -avail memory = 4194709504 (4000 MB) +avail memory = 4192100352 (3997 MB) これから、ごにょごにょしてみるです。 panicして落ちるときはいつも、 supervisor read, page not present って言って落ちるですね。 ということで、このパターン。 落ちるけど、クラッシュダンプ(savecore)がとれない、というところまで 全く同じ。 http://lists.freebsd.org/pipermail/freebsd-current/2004-September/038683.html 結構この事例って、報告されているですね。 で、どれも明確な回答がないような。 というか、 ・設定で回避する方がいい なのか、 ・素直に64bit OSを入れたほうがよい (Cobraでは4G memは全く問題なく動いている) のか、っていう話ですね。 で、32bit+PAEで使うメリットは、Apacheをはじめとするコマンドが使う、 メモリの大きさです。 32bit modeの方が、より少ないメモリスペースで一つのhttpdが動きます。 つまり、32bit+PAEにすることで、より多くのhttpdを常駐させられる可能性がある。 今のlive20ではmem=2Gで最大値1024で動かしていますから、 mem=4Gで動かせるなら、単純計算でその倍にできるかもしれないわけです。 64bit modeだと、そうはいかないですね。 というわけで今回の作戦では、できれば32bit mode+PAEを何とかしたいかなと、 思っていたりします。 ただこれは致命傷なわけではなく、64bit modeには64bit modeのよさがあるので、 ある程度試してだめだったら、64bit modeのOSに入れなおしてもらうと思うです。 4Gにチャレンジはまた今度にするに一票 3G でも 3.5Gでもokということで、 姉:64bit 妹:32bit 関係ないけど、そんな事考えてみた >>849 今回は昨年のやつと違って、原因がどこにあるかは マクロ的に概ね見当がついているので、 いまのところは、必要ないかなと。 >>850 もったいないお化けが出る状態で動かす、ってことですか。 つまり、mem 3.5Gで動かすと。 実利的には、それかもですね。 ハードウェア的にはメモリインターリーブ聞くので、問題ないだろうし、 それでもたぶん、httpdは相当増やせるし。 今日私が寝るまでいろいろトライしてだめだったら、 それでいくことにするです。 目的は「雪だるまの構築」ですから、 土台はあとでup gradeもできますし、 了解です。>>855 物理的に障害があるわけでもなく、 64bit modeで動かせば概ね問題なさげなんで、 目的遂行を優先に、動きますか。 で、私は、あそこの >= を > にしてみようかなー、とか、 無謀なことを考え中。 ちょうど 4G だし。 3.5G 32bit でおねがいします。 64bitのデバックは目的じゃないので、 >>857 はい。 > で、私は、あそこの >= を > にしてみようかなー、とか、 は、いま失敗したんで(3.5G状態は変わらなかった、どうも、リザーブをとるようですね)、 従来の仕様(tiger2513等と同じ)、32bit modeで動かすことにするです。 あまり関係ないとは思いますが、貼るだけ貼っときますね。 ttp://h50146.www5.hp.com/products/software/oe/bsd/support/faq_freebsd/freebsd_1.html なにかどこかで、携帯の統計取りはじめたのを耳にしたのですが、 是非 是非 携帯用バーボンを導入してくださいまし。 1) 同じスレとか同じ板に沢山書き込み ↓ 2) そいつの固有番号を BBQ へ自動放り込み というわけで、32bit modeでいくです。 しかし「ちょうど4G」なんだから、 なんとか、BIOSレベルでごにょごにょできないかなー。 あきらめがわるいなー。 でも人生、時には、見切りも必要なんだろうなぁ。 >>862 sec2chdを見ていると、必要なのは広告撃退のしくみ(BBX)と、 連投ペナルティの仕組み(バーボン)な気がしているです。 で、携帯用BBXは、導入しようとしているです。 たぶんわりと簡単にできると思います。 そのうちoperateにスレ立てて、すすめようかと。 携帯用バーボンですか。 ずいぶん昔にメールもらったような気がするので、 それを掘り起こしてみますか。 ちなみに現在は携帯からは無制限のアクセスが可能な状態です 投稿しようが、読み込もうが、 スレ立て規制・samba24は効く、 携帯からの広告爆撃は特に困ってはいない(現在) >>865 > 携帯からの広告爆撃は特に困ってはいない(現在) 相対的にってことですね。 で、どうせ芋掘りして、焼くわけだしと。 てなわけで、バーボンが最優先の課題ということですか。 リロードバーボンは仕込むなら c 側ってことになりますね。 たぶんそれより先に、投稿バーボンを何とかできないかと。 今の投稿バーボンの実装って、BBSからフックしてるんでしたっけ。 だとすると、BBMからフックする形が自然ですね。きっと。 若者も交えて、すすめることになるのかなと。 そですそです < 相対的に それで、期限付き(2hとか)で自動で焼けると良いのだが、 直感的には、 m と m2 で投稿に使われた固有IDの情報を集める x 秒間に y 回以上投稿があったら、z 秒間BBMに突っ込む という実装ですかね。 うーん、3サザン人日ぐらいかなぁ。 >>869 調整次第でしょう。 live系サーバはスルーとか、今のバーボンと同じような調整すればいいんじゃないかなと。 ていうか、いまさらですけど、 「32bit modeのOSだと4GBのメモリがフルに使えないことがある」 という仕様が影響しているような希ガス >>873 ですね。本来は。 5.2.1RのSMPみたいなもので、熟成がいまだ不十分だったと。 今のFreeBSD-current方面って、PAEの開発は盛んなのかしら。 >>874 そうですたか、スマソ>>873 基本的にBSDの中の人はあまり詳しくないもので。 > 5.2.1RのSMPみたいなもので、熟成がいまだ不十分だったと。 あれはたしかにひどかったっすね・・・ c.2ch不具合報告総合スレ3 http://qb5.2ch.net/test/read.cgi/operate/1115382157/826 ということで、c-others系も c-au/d-docomo系と同様、DNSロードバランシングに変更します。 以下のDNSの変更をお願いします。 1行削除、2行追加。 (現在) +c-others.2ch.net:206.223.150.148 (変更後) +c-others.2ch.net:206.223.150.145 +c-others.2ch.net:206.223.150.190 c-others.2ch.net DNS登録情報を変更致しました。 (TTLは1日(=86400)で設定されております。) ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる