関連キーワードをなんとかしようスレ
■ このスレッドは過去ログ倉庫に格納されています
read.cgiの片隅に表示されている関連キーワードを きちんとメンテナンスしてみようなスレッド。 お、スレ来ましたか。 先日管理人からお誘いがきたです。 もう一人、超強力な人(仮名)が呼ばれている様子。 >>1 スレ立て乙です. で,core 吐くのは何とかなったっぽいですが,Solaris の port_associate() / port_get() 前提に作ったのを FreeBSD の kevent() に対応させた(つもりの)部分の動きが相変わらず怪しいと......<crawld で,truss を使えるように(/proc をマウント?)してもらえると,デバッグがしやすいかなぁ,と...... Mozilla/5.0 (X11; U; SunOS i86pc; ja; rv:1.9a1) Gecko/20061128 Minefield/3.0a1 >>5 超強力な人だ。 これまでの経緯や進捗などについては、 帰宅後にでもここにぼちぼちと。 で、/proc を mount する作業についても、 帰宅後に進めるです。 ■ これまでのまとめ 2006年の4月頃、read.cgi の出力の上のほうに「関連キーワード」を 表示する機能を、管理人がつけました。 http://qb5.2ch.net/operate/kako/1145/11456/1145615267.html の 490- プログラムは管理人が作成したプロトタイプ版でした。 まずプロトタイプ版で動かし将来よくしていこう、という目論見だったようです。 http://qb5.2ch.net/operate/kako/1145/11456/1145615267.html の 496 現在でもこの機能は、一部サーバで動いています。 * 全サーバでの動作はさせていません(負荷問題) * 負荷軽減のため21時から2時まではリクエストの処理をしていません(同上) また、事情により最近立ったスレッドではこの機能は動いていないそうです(by 管理人) * キーワード【準備中】 になっているもの このような状況の中、管理人からSunOSさんと私に、 「これ、やってみませんかー」というオファーが来ました。 そして、相談の結果、オファーを受けてみることとしました。 ■ これまでにすすめたこと ・先日管理人・SunOSさん・私の3人でオフラインで会い、現在の状況の確認をしました。 (管理人が手ずからペンとスケッチブックを持ってきて、絵を描いて説明しました) ・このためのサーバを2台準備し、私がインフラ部分の基本環境を作りました。 p2.2ch.io と c2.2ch.io になります。 ・管理人が今日、このスレを立てました。 そんなわけで例によって、表でわいわいやっていくことになりました。 ・現在 SunOS さんが中身の開発をすすめているところです。 というわけでどんな構想で作っておられるか等については、 ぼちぼちとここでやっていくのがいいのかなと思います。 例によって今後進めていく作業者間の作業連絡等も、 表ででやれるところについては(パスワードとかセキュリティ関係じゃないものとか)、 ここでやっていけるといいのかなと。 こんなところで。 >>12 はい。 組むのはあまり戦力にならないので、 例によってインフラ整備系とかネットワーク系でがんがってみようかと。 SunOS さんからの依頼により、 [cp]2.2ch.io の libcurl を 7.16.0 に更新しました。 >>9-11 ,15 乙です. >>12-13 よろしくです. 構想については管理人さんから大枠が示されていまして シード: 取得する Web ページの URL を保持し,それをクローラに渡す ↓ クローラ: 渡された URL のコンテンツを取得する ↓ パーサ: コンテンツから特徴的なキーワードを抽出する ↓ インデクサ: URL とキーワードの対応テーブルを DB として保持する フロントエンドからは,まずそのスレに対応するキーワードデータがすでに DB に存在するか調べ, あればそのキーワードを使用し,なければシードに URL を渡して上記の処理を行う,と. で,/proc をマウントしてもらったおかげで truss が使えるようになり, かなりデバッグがやりやすくなりました.で,crawld(=クローラ)もだいぶ安定してきたかな. usage: crawld [-fh] [-b host] [-d datadir] [-i interval] [-o unixfile] [-p port] [-s statfile] [-u useragent] -b host: bind UDP socket to this host [0.0.0.0] -d datadir: directory for fetched files [/var/crawld] -f: run in foreground -h: this help -i interval: interval(sec) for a same host [3] -o unixfile: output filenames to this unix domain socket [none] -p port: bind UDP socket to this port [9606] -s statfile: dump statistics to statfile on SIGUSR1 [/dev/null] -u useragent: set User-Agent request header [none] シードからは,crawld が待ち受けしてる UDP ポートに URL を投げ入れると, そのページのコンテンツを取得しデータディレクトリ配下に格納します. crawl.pl という Perl スクリプトを使えば,コマンドラインから URL を渡せます. usage: crawl.pl URL [URL ...] or crawl.pl <file_of_URLs -o オプションを使うと,取得したコンテンツが格納されているファイル名を Unix ドメインソケット経由でパーサに渡すことができます. -i オプションのインターバルは同一ホストに対するもので,別ホストに対してはインターバル指定にかかわらず即時取得します. 2ch 限定で使う分には,とりあえずインターバルを 0 にしてもいいかもですが. 並列度は,URL をどんどん放り込めば,理論上は1プロセスあたりの fd 数の限界に達するまで増えて逝きます. ただし,同一ホストに対するリクエストは Keep-Alive を有効利用できるように直列化されます. んで,crawld の次はパーサになるわけですが......キーワードの妥当性チェックのために Google に問い合わせてヒット数で判断するということが言われてるのですが, 外部のサービスに依存する形になるのはちと危うさがあるかな,という懸念が個人的には...... クローリングしたデータから自前で単語のヒット数のようなデータを蓄積するとか, 自前で完結できる形でできないかなぁ,とも...... 自前で完結するとなると全体のデータの中の単語量を調べるってので、 なんとかなるかもかも。 でも、ある程度大きな規模のデータがないと 結果に偏りが出ると思います。 人が少ないスレ・板だと、やっぱり恥ずかしい思いをすることになるのかな。 >>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 入れる予定)のかしら。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる