関連キーワードをなんとかしようスレ
■ このスレッドは過去ログ倉庫に格納されています
read.cgiの片隅に表示されている関連キーワードを きちんとメンテナンスしてみようなスレッド。 >>17 ですねぇ.最初のうちしばらくは,キーワード表示はせず単語データ収集のためだけに動かすとか...... で,クローラをがんがん動かすことになると,バーボンに引っかからないようにしてもらった方がいいのかも. あと,DB (MySQL) もぼちぼち立ち上げてもらった方がいいのかも. 全体の単語量を調べるのであれば、Ngramのsennaとか入れたほうがいいかもです。 >MySQL >>19 MySQL は帰宅後にでも。 # なお、私は MySQL のチューニングについてはほとんど素人です。 MySQLを覚えるいい機会が出来てなによりです。 えぇえぇ。 >>20 これですか. http://qwik.jp/senna/FrontPageJ.html >>21 まぁ,パーサはこれから作るって段階なので,急ぎではないです<MySQL >>19 サーバは、p2/c2 どちらで上げましょうか。 >>27 そうですねぇ......とりあえず p2 の方でおながいします. >>28 了解です。 # ちと明日とても早いので、明日以降に。すんませんです。 試しにクローラ部分だけぶん回す実験をちょっとしてみようとか思ったりも するんですが,今 read.cgi 画面から読み込まれてる p.2ch.io のやつを p2.2ch.io に変えちゃったりしてもいいんですかね? あと,c2.2ch.io をバーボン対象から外さないと引っかかる可能性も あるかも知れないですが,外してもいいんですかね? それと......[cp]2.2ch.io には LAN セグメントは1つしかつながってないようですが, [cp]2.2ch.io 同士のやりとりのためにプライベートアドレスを論理 I/F というか alias で付与するとかは可能なんですかね......? >>31 > 今 read.cgi 画面から読み込まれてる p.2ch.io のやつを > p2.2ch.io に変えちゃったりしてもいいんですかね? 様子を見ながらなら、いいんではないでしょうか。 > c2.2ch.io をバーボン対象から外さないと引っかかる可能性も > あるかも知れないですが,外してもいいんですかね? リロードバーボンですね。 心配要らないはず。理由は別途メールででも。 > プライベートアドレスを論理 I/F というか > alias で付与するとかは可能なんですかね......? できるはず。 ちょっとトライしてみます。 というか、、、。 p2 と c2 の間の通信って、多くなりそうなのかしら。 それなら 100Mbps に I/F を変更してもらったほうがいいのかなと。 >>32-33 乙です. >リロードバーボンですね。 >心配要らないはず。理由は別途メールででも。 あ,そうだったんですか. >p2 と c2 の間の通信って、多くなりそうなのかしら。 とりあえず思い付くものとして ・ p2 から c2 にクロールすべき URL を投げる. ・ c2 から p2 にレコード登録のための MySQL のクエリーを投げる. これらがどの程度か,ってところですかねぇ...... [cp]2 にプライベートアドレスを振りました。 いくつを振って、それがどのような名前で参照できるかは、 セキュリティ上ここでは書かないので、 すみませんが該当サーバの /etc/hosts あたりを見ていただけると。 >>34 > あ,そうだったんですか. というか、管理人が自らのためにやるもの(ブラジル等)については、 そもそもリロードバーボンの対象外にする(している)という話ですね。 > とりあえず思い付くものとして > ... > これらがどの程度か,ってところですかねぇ...... 統計とってみるですかね。 これは別途。 http://p2.2ch.io/getf.cgi?http ://qb5.2ch.net/test/read.cgi/operate/1166328527/l50 のように呼ぶと crawld に dat の URL 投げるようにしますた. さて,やってみるかな......<read.cgi 画面から読み込み おぉ。はじまっている。 crawld を自動起動するしかけ等が必要になったら、 ここでお知らせくださいです。 >>39-40 ども.まぁ今は getf.cgi に渡された URL を単純に (dat の URL に変換した上で)crawld に投げてるだけなんですが, ---------------------------------------------------------------------- last pid: 74880; load averages: 0.02, 0.06, 0.04 up 15+18:27:52 15:22:53 170 processes: 1 running, 169 sleeping CPU states: 0.2% user, 0.0% nice, 0.5% system, 0.2% interrupt, 99.2% idle Mem: 64M Active, 1659M Inact, 196M Wired, 81M Cache, 112M Buf, 2996K Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 74627 c22chio 1 4 0 5452K 4120K kqread 0 5:37 4.54% crawld ---------------------------------------------------------------------- CPU の能力的には余裕っぽいですね.ただ, ---------------------------------------------------------------------- [crawld statistics] Tue, 19 Dec 2006 14:04:38.945 (JST) user CPU time = 0:00:11.052, system CPU time = 0:00:33.811 elapsed time = 0:13:18.542, CPU load = 5.62% total workers = 8, idle workers = 0 minor page faults = 3656, major page faults = 0, swaps = 0 block inputs = 3837, block outputs = 3329 messages sent = 28359, messages received = 691574 signals = 5, vol ctx switches = 664364, invol ctx switches = 60839 URLs: input = 55614, done = 25802, error = 1445 ---------------------------------------------------------------------- [crawld statistics] Tue, 19 Dec 2006 15:23:19.866 (JST) user CPU time = 0:01:25.717, system CPU time = 0:04:12.259 elapsed time = 1:31:59.462, CPU load = 6.12% total workers = 8, idle workers = 0 minor page faults = 63546, major page faults = 0, swaps = 0 block inputs = 111588, block outputs = 17339 messages sent = 385824, messages received = 3511819 signals = 7, vol ctx switches = 3126563, invol ctx switches = 500464 URLs: input = 376259, done = 355261, error = 20952 ---------------------------------------------------------------------- 動かし始めの dat をガンガン転送してる時は URL の input に対し done が追い付いてない感じ,一方ずっと動かしてて重複した URL への 304 レスポンスが増えてくると差が縮まって追い付いてきてる感じかなぁ. これを見ると,ネックはネットワーク帯域? >>41 > これを見ると,ネックはネットワーク帯域? まずは計測してみるです。 そのうえで、次の手を。 いつの間にか p2 が p に戻ってたんですが......重かったからかな? まぁ,c2 が涼しい顔してた一方で p2 は忙しそうでしたが...... getf.cgi はとりあえず SpeedyCGI で書いてたんですが, DSO にした方がいいのかなぁ...... >>43 > いつの間にか p2 が p に戻ってたんですが......重かったからかな? きっと、あっちの繁盛しているスレの作業と、 更新作業がバッティングしたんではないかと。 で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。 http://mumumu.mu/mrtgi/ >>44 あ,じゃあ誰かが意図的に戻したんじゃなかったんですね. じゃあちょろさんにお願いすればいいのか. >で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。 乙です. >>45 しばらくはあのスレあたりで「read.cgi 更新しますけどOKでしょうか」とか、 「更新しました」みたいなことをすればいいと思いますです。 今は絶賛上映中みたいなので、幕間にでも。 > じゃあちょろさんにお願いすればいいのか. 作業がバッティングしないのであれば、 更新はたんたんとやってしまってよいと思われ。 それで、PHP は少なくとも今は使わないかんじみたいなので (SunOS さんからによると)、 とりあえず、はずしておきます。< [pc]2.2ch.io # PHP + eAccelerator なので、メモリをかなり食っているため。 >>46-47 今は,目下 dso でちょろさんらしき人がリアルタイムで read.cgi の書き換え作業中のようですね.しばらく待ちますか...... >>49 とりあえずそれでいいと思います. さて,p2 に戻すことができますた.ついでにテストのため時間制限も外してみた,とw -M8 を -M32 ぐらいにしてもいいかも。 で、PHP はずして楽になったので、 httpd の数をもう少し増やしておきます。 < p2.2ch.io >>52 乙です. >-M8 を -M32 ぐらいにしてもいいかも。 そうしてみますた. 落ち着いたかな。 これだけアクセスが多いと、suexec のオーバーヘッドがばかにできないですね。 >>55-56 乙です.まぁ PHP なしなら worker MPM にするってのもありでしょうし. >>57 今は dso から配ったやつ全部なんでしたっけ。 雪だるまとか news4vip とかはまだと。 >>58 配布は dso 上でしかやってませんです. きついかも、、、。 KeepAlive Off にしてみた。 ちょっと鯖名による選別も外してみますたが,かなり苦しそうだったのでそれは戻しますた...... kern.ipc.maxpipekva exceeded; see tuning(7) kern.ipc.maxpipekva exceeded; see tuning(7) kern.ipc.maxpipekva exceeded; see tuning(7) ... と出ているですね。 できる範囲で、ちと大きくします。 kern.ipc.maxpipekva=41943040 にしようかと思いましたが、ちょっと怖いですね。 メモリ4Gのサーバでは実績ありますが(雪だるまtiger/cobra)、 それ以外ではやったことがあったかどうか。 >>63-64 乙です.しかし,p2 は httpd だけで苦しいとなると,DB 鯖は独立させた方がいいかもですね. c2 は c2 でパーサが重くなりそうだし.あと,c2 のトラフィック見ると やはり 10M 近辺で張り付いてますね...... これは、大変ですね。 ちょっとオフラインになるので、いったん撤退に一票かな。 SpeedyCGI でももたないと。 というか管理人からは「どこまでいけるかを見極める」ことも目的だから、 いきなりほぼ全サーバに敷衍して負けだった、ということがわかった、 ということなのかなと。 で、>>65 にもありますが、可能であればデータリングは 100Mbps にしてもらったほうがよさそうなかんじですね。 # もう少ししたら、ちとオフライン。 >>66 時間制限も復活させました.で,今の時間は一休み,と...... で、p2 の httpd が売り切れにならないように、 起動されるやつをできるだけ軽く、コンパクトにするかんじかなと。 >>69 ですかね,ともあれ乙ですた. とりあえずわかったことは ・ p2 の httpd を何とかしなければ...... ・ NIC のスピードも 100Mbps にしないと...... ・ crawld 自体は能力的にはまずまず,か...... >>70 SunOSさんもおつでした。 > ・ p2 の httpd を何とかしなければ...... どんなかんじですかね。 - SpeedyCGI => dso - いずれにしても >>69 > ・ NIC のスピードも 100Mbps にしないと...... これは、依頼するかんじで。 > ・ crawld 自体は能力的にはまずまず,か...... いつもながら、さすがですね。 lighthttpdとspeedyとかだとどうなんすかね。 >>71-72 どうしましょうか......まぁ DSO にすれば軽くなるのは確実だとは思いますが, 柔軟にいじりにくくなるのがマイナスかも?(まぁ最終手段としてはそれしかないでしょうけど) p2 での問題は...... http://mumumu.mu/mrtgi/mrtg-rrd.cgi/access/p22chioaccess.html 100 回 / 秒を超えるアクセスがほとんど CGI に対するものだ,ってことですかね. http://mumumu.mu/mrtg/mrtg-rrd.cgi/access/life7access.html http://mumumu.mu/mrtg/mrtg-rrd.cgi/read/life7readdat.html ↑なんかと比べると,アクセス数そのものは普通の 2ch の tiger 鯖への ものと比べてそんなに多いわけではないようですが,静的ファイル + DSO が 多くを占めるか SpeedyCGI が多くを占めるか,というのが違いのようで. SpeedyCGI 使用を前提に考えるなら,とりあえず speedy プロセスの fork(), exec() 回数が ものすごいことになっていて,そのオーバヘッドもかなりのものになってそうな気がするので, mod_speedycgi というのも1つの選択肢かなぁ(ただし worker MPM だとダメですが). ついでに......これ見るとなんか面白いですねw http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/ 昨晩は 21 時過ぎぐらいにやめたので p2 のトラフィックもそれとほぼ同じぐらいに 沈静化してますが,c2 の方は 10 Mbps の天井に抑え付けられてたために 22 時半ぐらいまで続いていたと...... >>72 今回のは CGI の、かつ fork/exec の負荷のようですね。 つまり、 >>73 > 静的ファイル + DSO が > 多くを占めるか SpeedyCGI が多くを占めるか,というのが違いのようで. なので、 > mod_speedycgi というのも1つの選択肢かなぁ(ただし worker MPM だとダメですが). にするというのは、効果ありかも。 # for mod_speedycgi <IfModule speedycgi_module> <Files むぎゅ> SetHandler speedycgi-script </Files> </IfModule> にしてみた。 >>75 なんとなく、問題なさげ。 CPU idle time が増えたっぽいかな。 あと、10Mbps => 100Mbps の作業中は、 当然サーバ落ちますが、その間 read.cgi の動作に影響ないのかしら。 あるなら、その間は一時的にはずす必要あり? >>75-76 乙です. >>77 <iframe> の中身が読めないだけで,read.cgi 出力の表示そのものは可能ですね. ただ,その <iframe> の読み込みが終わらない状態が続くとウザいと感じる利用者は いるかも知れませんが...... >>78 > <iframe> の中身が読めないだけで,read.cgi 出力の表示そのものは可能ですね. …であれば、NIC の速度を変えるぐらいの作業なら そのまま動かしてもとりあえず問題なさげですね。 >>80 作業依頼を出せと、、、。 そんなわけで、こちらはたんたんと。 今、トラフィック的に「フルスペック」なんでしたっけ。 もしそうなら、まずは 10Mbps で動かしてみて、 どうなるのか見てみようかなと。 http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/ 昨晩は,20:20 頃〜21:10 頃に放り込まれた URL を処理するために 22:30 頃まで crawld が働き通しだった模様ですが,時間制限や 鯖名による選別も撤廃した場合,次の日のピーク時間までに 処理し終えるかどうか......まぁ実験としては面白いですがw まぁ,ともあれ mod_speedycgi は今のところかなり効果あるっぽいですね. 昨日の今頃の時間は Load Avg. 軽く二桁超えてましたが,今は1未満ですし<p2 1日強程度動かしただけで,もう /home 半分近く消費してますね. まぁ単にテストで動かしてるだけなんで,頃合い見計らってごっそり消してもいいんですが. Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/amrd0s1g 23793186 10653300 11236432 49% /home 昨晩に比べると p2 はかなり余裕っぽいんで,また時間制限と鯖名選別を外してみますた. 外す前 Load Avg. は 1 未満だったのが 2〜3 台ぐらいになってますが,昨晩のように 破綻寸前なんてことはなく,十分捌ききれる範囲って感じしますね. ちなみに c2 の方は 0.1〜0.2 前後.トラフィックは急に跳ね上がって, また 10 Mbps の天井に抑え付けられてるようで.URL をキューイングするため プロセスサイズは肥大化してきてますね<crawld 現在 36 MB ぐらいですが, 増加のペースは結構速い...... GB 単位とかになったりしてw http://mumumu.mu/mrtgi/mrtg-rrd.cgi/access/p22chioaccess.html 制限撤廃後 450 アクセス / 秒ぐらいまで逝ってますが, 比較的無難にこなしていたようですね<p2 http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/ c2 のトラフィックは意外と早く天井から離れてる...... ずっと動かし続けてれば 304 レスポンスが増えてくるからかな. crawld のプロセスサイズは 359MB になってますがw とはいえ,今はまだ dso から read.cgi を配布できる鯖の分だけなんですよね. Apache 2.2 の鯖の分は live22(というか live24b)から配布でいいんですかね? >>87 cgi 起動数が多い場合には、 CGIモード→Apacheモジュールモード への変更の効果は絶大みたいですね。 > Apache 2.2 の鯖の分は live22(というか live24b)から配布でいいんですかね? live24b になります。 既に配布リストは更新しました。 ソースを dso からコピーして、コンパイル・配布すれば OK です。 あ、そか。 雪だるまフロントに例の /i を作らないといけないかも。 >>88 雪だるまでの read.cgi の配布の前に、 かっこいいおにいさんに確認したほうがいいかもです。 これをやると、雪だるまでもおすすめなんたらが有効になるような気がするので。 >>87 > c2 のトラフィックは意外と早く天井から離れてる...... > ずっと動かし続けてれば 304 レスポンスが増えてくるからかな. ふむ、、、。100Mbps にすれば解決できそうですかね。 > crawld のプロセスサイズは 359MB になってますがw trim するようなしくみとかはある(or 入れる予定)のかしら。 >>88 >cgi 起動数が多い場合には、 >CGIモード→Apacheモジュールモード への変更の効果は絶大みたいですね。 ですね. >>89 ですね,そうする時には...... >>90 >ふむ、、、。100Mbps にすれば解決できそうですかね。 ですかねぇ......というか dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.2.9 ってことは......1Gbps とかも可能だったり? # まぁスイッチとかも対応してないとしょうがないでしょうけど. >trim するようなしくみとかはある(or 入れる予定)のかしら。 使い終わった URL キューは順次 free() するようになってるんですが...... と思って見てみたら......渡された URL を全部捌き切ってないから残ってることが判明. 今は試しに p2 から URL 投げるのをやめさせてるんですが, http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/ 波形に多少乱れはあるものの,c2 のトラフィックは URL 投げるのをやめる前と さほど大きくは変わらない感じですねぇ(以下のように URL の input は変わらず done は増えてます).これをどう解釈すべきか...... ユーザの活動が活発な時間帯は 200 レスポンスが多く,静かな時間帯は 304 レスポンスが多くなる.で,304 レスポンスの場合パケットサイズが 小さくなるので見かけ上のトラフィックは減少する,しかし実際には ネットワーク帯域の天井に抑え付けられてる状態には変わりない. という仮説を考えたりしましたが,さて...... ---------------------------------------------------------------------- [crawld statistics] Thu, 21 Dec 2006 14:56:22.909 (JST) user CPU time = 0:40:40.122, system CPU time = 1:47:09.506 elapsed time = 49:05:02.506, CPU load = 5.02% total workers = 23, idle workers = 3 minor page faults = 494840, major page faults = 1, swaps = 0 block inputs = 4778572, block outputs = 358959 messages sent = 10089189, messages received = 58823961 signals = 23, vol ctx switches = 35525493, invol ctx switches = 7880999 URLs: input = 16004864, done = 9374851, error = 539962 ---------------------------------------------------------------------- [crawld statistics] Thu, 21 Dec 2006 15:21:15.910 (JST) user CPU time = 0:41:39.791, system CPU time = 1:48:28.385 elapsed time = 49:29:55.507, CPU load = 5.06% total workers = 23, idle workers = 2 minor page faults = 495776, major page faults = 1, swaps = 0 block inputs = 4848821, block outputs = 363356 messages sent = 10214877, messages received = 59170017 signals = 24, vol ctx switches = 35671856, invol ctx switches = 8000494 URLs: input = 16004864, done = 9492604, error = 546602 URLs: input = 16004864, done = 9492604, error = 546602 49時間でってことですか? >>92 そういうことですね.ただ,10 Mbps の天井に抑え付けられたゆえ input に done が追い付いてないという可能性が高いので, NIC 速度が速ければ input と done の差はもっと縮まりそうな気がします. で,昨日 14 時ぐらいから crawld に URL 投げるのをやめていて, crawld 内部にため込んだキューの URL を黙々と処理している,つまり p2 の getf.cgi 呼び出し数と c2 のトラフィックは直接関係ないはずですが http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/ 振幅こそ小さいものの c2 のトラフィックは p2 の波形と相似してますね. これは,やはり >>91 の仮説は合っているということなのかも...... >>94 いつでしょうね...... で,やっと処理し終えたようで (16004864 == 14898974 + 1105890). ---------------------------------------------------------------------- [crawld statistics] Fri, 22 Dec 2006 07:37:46.952 (JST) user CPU time = 1:02:36.154, system CPU time = 2:36:48.069 elapsed time = 65:46:26.549, CPU load = 5.56% total workers = 0, idle workers = 0 minor page faults = 513650, major page faults = 1, swaps = 0 block inputs = 7291510, block outputs = 500784 messages sent = 16230355, messages received = 74098823 signals = 28, vol ctx switches = 45133077, invol ctx switches = 12898923 URLs: input = 16004864, done = 14898974, error = 1105890 ---------------------------------------------------------------------- しかし,これもまた......いったんごっそり消しておこうw ---------------------------------------------------------------------- Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/amrd0s1g 23793186 20773904 1115828 95% /home ---------------------------------------------------------------------- >>94 >>82 の結果「やはり10MBpsではそこの部分が障害となる」ことがわかったので、 私のほうからメールで、以下のオーダー出しておくです。 1) 10Mbps→100Mbpsへの変更 2) p2.2ch.io ⇔ c2.2ch.io 間のクロスケーブルでの直結 >>94 ・通信速度のアップグレード ・p2.2ch.io と c2.2ch.io の間の直結(2nd I/F 使用) を、今メールでお願いしました。 次にリブートすると設定が変わるように /etc/rc.conf を設定して、 スイッチの設定変えたらサーバリセットしてかまわない、 と伝えました。。 >>98 × 次にリブートすると設定が変わるように /etc/rc.conf を設定して、 ○ 次にリブートすると設定が変わるように /etc/rc.conf を設定してあるので、 あけましておめでとうございます.本年もよろしくです. さて,まだ 10Mbps のままなんですが,とりあえず試運転ってことでパーサも含め動かし始めてます. # MeCab / MySQL は,とりあえずホームディレクトリに突っ込んでます. しかし,予想通りパーサ,特に MeCab での単語切り分け処理が重いようですね. ---------------------------------------------------------------------- last pid: 80257; load averages: 3.70, 3.92, 3.83 up 28+04:11:24 01:06:25 1375 processes:18 running, 1356 sleeping, 1 lock CPU states: 77.7% user, 0.0% nice, 7.5% system, 1.5% interrupt, 13.3% idle Mem: 666M Active, 916M Inact, 312M Wired, 105M Cache, 112M Buf, 4216K Free Swap: 2048M Total, 132K Used, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 80076 c22chio 1 123 0 78644K 56276K RUN 2 42:24 76.51% perl5.8.8 80077 c22chio 1 120 0 77952K 43544K RUN 0 41:00 63.33% perl5.8.8 80079 c22chio 1 117 0 78168K 49140K CPU3 3 41:25 63.18% perl5.8.8 80078 c22chio 1 115 0 79636K 48336K CPU1 0 41:39 54.00% perl5.8.8 80093 c22chio 1 -16 0 11416K 10124K wdrain 1 9:11 13.43% crawld 67240 c22chio 45 4 0 317M 286M RUN 2 195:25 7.76% mysqld ---------------------------------------------------------------------- perl5.8.8 ってのがパーサなんですが,CPU 4 つなのでプロセス数も 4 にしてます. あと,フロント側はこんな感じ.LA の数値は劇的に高いってほどでもないんですが, getf.cgi の取得で引っかかり感があるかな,と...... ---------------------------------------------------------------------- last pid: 40422; load averages: 2.79, 3.33, 3.66 up 28+06:03:16 01:08:11 1345 processes:26 running, 1319 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 546M Active, 271M Inact, 372M Wired, 5652K Cache, 112M Buf, 807M Free Swap: 2048M Total, 432K Used, 2047M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 40421 p22chio 1 97 0 5560K 4168K select 1 0:00 3.08% speedy_backen 40419 p22chio 1 97 0 5496K 4248K select 3 0:00 2.42% speedy_backen 40417 p22chio 1 96 0 5640K 4432K select 2 0:00 1.88% speedy_backen 40420 p22chio 1 4 0 5500K 4224K sbwait 0 0:00 1.88% speedy_backen 40415 p22chio 1 4 0 6048K 4628K sbwait 3 0:00 1.86% speedy_backen 40418 p22chio 1 96 0 5640K 4468K RUN 0 0:00 1.75% speedy_backen 40403 p22chio 1 96 0 6804K 5524K select 3 0:01 1.55% speedy_backen ---------------------------------------------------------------------- 関連キーワードをおすすめ2ちゃんねるみたいにCGIを叩かずに取得できるようにして欲しい。 スレの話題が分かりやすくて便利なので。 >>102 read.cgi に直接組み込むってことですか? そうすると read.cgi 自体が重くなる要因になるような...... # p2.2ch.io が重くなっても read.cgi の表示そのものに影響を与えないように今の形になってるんで...... >>104 http://p2.2ch.io/getf.cgi?http ://qb5.2ch.net/test/read.cgi/operate/1166328527/ とかじゃダメなんですかね? それはともかく,表示用キーワード抽出を始める前にあらかじめ約26万 URL 分のデータを蓄積してから開始したわけですが mysql> SELECT COUNT(*) FROM urls; +----------+ | COUNT(*) | +----------+ | 377699 | +----------+ 結構たまってきたかな.表示用キーワードが抽出されてない URL 数は mysql> SELECT COUNT(*) FROM urls LEFT JOIN dispwords ON urls.id = dispwords.url_id WHERE dispwords.url_id IS NULL; +----------+ | COUNT(*) | +----------+ | 147607 | +----------+ まで減ってきてるんで,約23万 URL 分のキーワードを抽出した,と...... パーサは相変わらずフル回転ですがw last pid: 86427; load averages: 3.71, 3.81, 3.76 up 29+13:01:16 09:56:17 1376 processes:7 running, 1369 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 859M Active, 743M Inact, 313M Wired, 84M Cache, 112M Buf, 3416K Free Swap: 2048M Total, 60K Used, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 83069 c22chio 1 121 0 128M 98076K CPU3 3 564:41 75.68% perl5.8.8 83068 c22chio 1 123 0 128M 100M RUN 0 565:13 75.20% perl5.8.8 83070 c22chio 1 121 0 129M 104M RUN 2 563:53 71.78% perl5.8.8 83067 c22chio 1 118 0 126M 92476K RUN 0 565:14 67.97% perl5.8.8 67240 c22chio 46 96 0 317M 288M RUN 0 714:55 12.55% mysqld 80093 c22chio 1 4 0 7772K 6532K kqread 0 189:24 5.57% crawld 2chブラウザに関連キーワードを組み込むときに、毎回CGIを叩くのは負荷がかかりそう。 別にいいなら今の仕様でもいいんだけど。 リンク先がこんな風になってるのは仕様でしょうか。 http://find.2ch.net/?BBS=ALL& ;amp;TYPE=TITLE&ENCODING=SJIS&STR=workers 専ブラで読み込ませたらfindのトップに飛ばされた iframe が height=15 だと 3pix ほど足りなくて下のほうが欠けています(firefox2@win) height=18 程度に増やすか、文字を小さくしてもらえないでしょうか? >>106 read.cgiに負荷をかけるよりはマシかと。 >>106 内部的に登録されているキーワードは最大10なんですが, そのうち7つをランダム表示するような仕様になってます. 通常なら,個人的には Last-Modified 吐き + mod_cache 利用推進論者なんですが, キャッシュさせるとランダム表示ができなくなるというのがネックですね. ただ,CGI 側で MySQL のクエリー結果をキャッシュするようにはなってます. # もっとも,そのキャッシュはプロセス単位なんですよね.今は -M32 になってますが, # これを減らした方がキャッシュヒット率は向上するかと思うんですが,さて...... あと,getf.cgi で一番重い処理はその MySQL へのクエリー部分で, それ以外は単純に結果を吐くだけなんで,304 レスポンスを返すようにしても 大して変わらないんじゃないかという感じではあるんで(304 レスポンスを 返すとすると,mtime と If-Modified-Since の比較処理も Perl でやることになるし). >>107 (X)HTML 的には,<a> タグの href 属性中の & は,本来 & のように エスケープすべきものなんです(例えば CGI のパラメータで lt とか gt なんてのが あったらどうなるか......と考えればわかるかと). >>108 font-size: 13px; にしますた. いつの間にか,雪だるまや ex17 などの read.cgi も p2.2ch.io の方を読み込んでますね. ってことは,時間制限なしで 2ch 全鯖対象にしても,少なくとも Load Avg. 的には破綻せず処理できてる,と. 11:38PM up 30 days, 4:33, 1 user, load averages: 2.49, 3.16, 3.20 @c2.2ch.io 11:39PM up 30 days, 4:34, 1 user, load averages: 2.66, 3.15, 3.19 @p2.2ch.io キーワードが蓄積されるに伴い,クローラはあまりファイルを取得しに逝かなくなるので c2 のトラフィックは減ってきてますが,逆にキーワードを表示する p2 のトラフィックは増えてますね. http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/ 10個全部を吐くようにして、 javascript側でランダム表示にしちゃうとか。 そもそも、たかが10個のうち7個をランダムで表示する必要があるのだろうか。 100個あるならともかく。 今年もよろしくお願いいたします。 まずは、MySQL のインストールからですね。 普通に 5.x を入れればいいのかしら。 何か特別な設定が必要な場合、ここで教えてくださいです。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる