read.cgiの片隅に表示されている関連キーワードを
きちんとメンテナンスしてみようなスレッド。
関連キーワードをなんとかしようスレ
■ このスレッドは過去ログ倉庫に格納されています
>>43
> いつの間にか p2 が p に戻ってたんですが......重かったからかな？
きっと、あっちの繁盛しているスレの作業と、
更新作業がバッティングしたんではないかと。
で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。
http://mumumu.mu/mrtgi/
> いつの間にか p2 が p に戻ってたんですが......重かったからかな？
きっと、あっちの繁盛しているスレの作業と、
更新作業がバッティングしたんではないかと。
で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。
http://mumumu.mu/mrtgi/
> じゃあちょろさんにお願いすればいいのか．
作業がバッティングしないのであれば、
更新はたんたんとやってしまってよいと思われ。
作業がバッティングしないのであれば、
更新はたんたんとやってしまってよいと思われ。
48動け動けウゴウゴ２ちゃんねる
2006/12/19(火) 19:51:45ID:FsmnSRUQ0 サンプル
http://book3.2ch.net/test/read.cgi/juvenile/1089140209/l50
とりあえず2ちゃんねる全体でその話題を独占しているようなスレだと
殆ど役に立たないような
http://book3.2ch.net/test/read.cgi/juvenile/1089140209/l50
とりあえず2ちゃんねる全体でその話題を独占しているようなスレだと
殆ど役に立たないような
それで、PHP は少なくとも今は使わないかんじみたいなので
(SunOS さんからによると)、
とりあえず、はずしておきます。< [pc]2.2ch.io
# PHP + eAccelerator なので、メモリをかなり食っているため。
(SunOS さんからによると)、
とりあえず、はずしておきます。< [pc]2.2ch.io
# PHP + eAccelerator なので、メモリをかなり食っているため。
さて，p2 に戻すことができますた．ついでにテストのため時間制限も外してみた，とｗ
-M8 を -M32 ぐらいにしてもいいかも。
で、PHP はずして楽になったので、
httpd の数をもう少し増やしておきます。 < p2.2ch.io
で、PHP はずして楽になったので、
httpd の数をもう少し増やしておきます。 < p2.2ch.io
ちと、p2 の httpd とめます。
再挑戦。
SuExec はずした。
SuExec はずした。
落ち着いたかな。
これだけアクセスが多いと、suexec のオーバーヘッドがばかにできないですね。
これだけアクセスが多いと、suexec のオーバーヘッドがばかにできないですね。
>>55-56 乙です．まぁ PHP なしなら worker MPM にするってのもありでしょうし．
>>58 配布は dso 上でしかやってませんです．
>>59
了解です。
了解です。
きついかも、、、。
KeepAlive Off にしてみた。
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 exceeded; see tuning(7)
kern.ipc.maxpipekva exceeded; see tuning(7)
...
と出ているですね。
できる範囲で、ちと大きくします。
kern.ipc.maxpipekva=41943040
にしようかと思いましたが、ちょっと怖いですね。
メモリ4Gのサーバでは実績ありますが(雪だるまtiger/cobra)、
それ以外ではやったことがあったかどうか。
にしようかと思いましたが、ちょっと怖いですね。
メモリ4Gのサーバでは実績ありますが(雪だるまtiger/cobra)、
それ以外ではやったことがあったかどうか。
>>63-64 乙です．しかし，p2 は httpd だけで苦しいとなると，DB 鯖は独立させた方がいいかもですね．
c2 は c2 でパーサが重くなりそうだし．あと，c2 のトラフィック見ると
やはり 10M 近辺で張り付いてますね......
c2 は c2 でパーサが重くなりそうだし．あと，c2 のトラフィック見ると
やはり 10M 近辺で張り付いてますね......
これは、大変ですね。
ちょっとオフラインになるので、いったん撤退に一票かな。
SpeedyCGI でももたないと。
ちょっとオフラインになるので、いったん撤退に一票かな。
SpeedyCGI でももたないと。
というか管理人からは「どこまでいけるかを見極める」ことも目的だから、
いきなりほぼ全サーバに敷衍して負けだった、ということがわかった、
ということなのかなと。
で、>>65 にもありますが、可能であればデータリングは
100Mbps にしてもらったほうがよさそうなかんじですね。
# もう少ししたら、ちとオフライン。
いきなりほぼ全サーバに敷衍して負けだった、ということがわかった、
ということなのかなと。
で、>>65 にもありますが、可能であればデータリングは
100Mbps にしてもらったほうがよさそうなかんじですね。
# もう少ししたら、ちとオフライン。
>>66 時間制限も復活させました．で，今の時間は一休み，と......
で、p2 の httpd が売り切れにならないように、
起動されるやつをできるだけ軽く、コンパクトにするかんじかなと。
起動されるやつをできるだけ軽く、コンパクトにするかんじかなと。
>>69 ですかね，ともあれ乙ですた．
とりあえずわかったことは
・ p2 の httpd を何とかしなければ......
・ NIC のスピードも 100Mbps にしないと......
・ crawld 自体は能力的にはまずまず，か......
とりあえずわかったことは
・ p2 の httpd を何とかしなければ......
・ 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 だとダメですが）．
ついでに......これ見るとなんか面白いですねｗ
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/
昨晩は 21 時過ぎぐらいにやめたので p2 のトラフィックもそれとほぼ同じぐらいに
沈静化してますが，c2 の方は 10 Mbps の天井に抑え付けられてたために
22 時半ぐらいまで続いていたと......
柔軟にいじりにくくなるのがマイナスかも？（まぁ最終手段としてはそれしかないでしょうけど）
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 だとダメですが）．
ついでに......これ見るとなんか面白いですねｗ
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/
昨晩は 21 時過ぎぐらいにやめたので p2 のトラフィックもそれとほぼ同じぐらいに
沈静化してますが，c2 の方は 10 Mbps の天井に抑え付けられてたために
22 時半ぐらいまで続いていたと......
# for mod_speedycgi
<IfModule speedycgi_module>
<Files むぎゅ>
SetHandler speedycgi-script
</Files>
</IfModule>
にしてみた。
<IfModule speedycgi_module>
<Files むぎゅ>
SetHandler speedycgi-script
</Files>
</IfModule>
にしてみた。
あと、10Mbps => 100Mbps の作業中は、
当然サーバ落ちますが、その間 read.cgi の動作に影響ないのかしら。
あるなら、その間は一時的にはずす必要あり?
当然サーバ落ちますが、その間 read.cgi の動作に影響ないのかしら。
あるなら、その間は一時的にはずす必要あり?
>>78
> <iframe> の中身が読めないだけで，read.cgi 出力の表示そのものは可能ですね．
…であれば、NIC の速度を変えるぐらいの作業なら
そのまま動かしてもとりあえず問題なさげですね。
> <iframe> の中身が読めないだけで，read.cgi 出力の表示そのものは可能ですね．
…であれば、NIC の速度を変えるぐらいの作業なら
そのまま動かしてもとりあえず問題なさげですね。
あいあい
今、トラフィック的に「フルスペック」なんでしたっけ。
もしそうなら、まずは 10Mbps で動かしてみて、
どうなるのか見てみようかなと。
もしそうなら、まずは 10Mbps で動かしてみて、
どうなるのか見てみようかなと。
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/
昨晩は，20:20 頃〜21:10 頃に放り込まれた URL を処理するために
22:30 頃まで crawld が働き通しだった模様ですが，時間制限や
鯖名による選別も撤廃した場合，次の日のピーク時間までに
処理し終えるかどうか......まぁ実験としては面白いですがｗ
昨晩は，20:20 頃〜21:10 頃に放り込まれた URL を処理するために
22:30 頃まで crawld が働き通しだった模様ですが，時間制限や
鯖名による選別も撤廃した場合，次の日のピーク時間までに
処理し終えるかどうか......まぁ実験としては面白いですがｗ
まぁ，ともあれ mod_speedycgi は今のところかなり効果あるっぽいですね．
昨日の今頃の時間は Load Avg. 軽く二桁超えてましたが，今は1未満ですし＜p2
昨日の今頃の時間は Load Avg. 軽く二桁超えてましたが，今は1未満ですし＜p2
1日強程度動かしただけで，もう /home 半分近く消費してますね．
まぁ単にテストで動かしてるだけなんで，頃合い見計らってごっそり消してもいいんですが．
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/amrd0s1g 23793186 10653300 11236432 49% /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 単位とかになったりしてｗ
外す前 Load Avg. は 1 未満だったのが 2〜3 台ぐらいになってますが，昨晩のように
破綻寸前なんてことはなく，十分捌ききれる範囲って感じしますね．
ちなみに c2 の方は 0.1〜0.2 前後．トラフィックは急に跳ね上がって，
また 10 Mbps の天井に抑え付けられてるようで．URL をキューイングするため
プロセスサイズは肥大化してきてますね＜crawld 現在 36 MB ぐらいですが，
増加のペースは結構速い...... GB 単位とかになったりしてｗ
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/access/p22chioaccess.html
制限撤廃後 450 アクセス / 秒ぐらいまで逝ってますが，
比較的無難にこなしていたようですね＜p2
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/
c2 のトラフィックは意外と早く天井から離れてる......
ずっと動かし続けてれば 304 レスポンスが増えてくるからかな．
crawld のプロセスサイズは 359MB になってますがｗ
とはいえ，今はまだ dso から read.cgi を配布できる鯖の分だけなんですよね．
Apache 2.2 の鯖の分は live22（というか live24b）から配布でいいんですかね？
制限撤廃後 450 アクセス / 秒ぐらいまで逝ってますが，
比較的無難にこなしていたようですね＜p2
http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/
c2 のトラフィックは意外と早く天井から離れてる......
ずっと動かし続けてれば 304 レスポンスが増えてくるからかな．
crawld のプロセスサイズは 359MB になってますがｗ
とはいえ，今はまだ dso から read.cgi を配布できる鯖の分だけなんですよね．
Apache 2.2 の鯖の分は live22（というか live24b）から配布でいいんですかね？
>>87
cgi 起動数が多い場合には、
CGIモード→Apacheモジュールモード への変更の効果は絶大みたいですね。
> Apache 2.2 の鯖の分は live22（というか live24b）から配布でいいんですかね？
live24b になります。
既に配布リストは更新しました。
ソースを dso からコピーして、コンパイル・配布すれば OK です。
あ、そか。
雪だるまフロントに例の /i を作らないといけないかも。
cgi 起動数が多い場合には、
CGIモード→Apacheモジュールモード への変更の効果は絶大みたいですね。
> Apache 2.2 の鯖の分は live22（というか live24b）から配布でいいんですかね？
live24b になります。
既に配布リストは更新しました。
ソースを dso からコピーして、コンパイル・配布すれば OK です。
あ、そか。
雪だるまフロントに例の /i を作らないといけないかも。
>>87
> c2 のトラフィックは意外と早く天井から離れてる......
> ずっと動かし続けてれば 304 レスポンスが増えてくるからかな．
ふむ、、、。100Mbps にすれば解決できそうですかね。
> crawld のプロセスサイズは 359MB になってますがｗ
trim するようなしくみとかはある(or 入れる予定)のかしら。
> c2 のトラフィックは意外と早く天井から離れてる......
> ずっと動かし続けてれば 304 レスポンスが増えてくるからかな．
ふむ、、、。100Mbps にすれば解決できそうですかね。
> crawld のプロセスサイズは 359MB になってますがｗ
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
>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時間でってことですか？
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 の仮説は合っているということなのかも......
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 の仮説は合っているということなのかも......
NIC速度っていつ変わるんでしたっけ？
>>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
----------------------------------------------------------------------
しかし，これもまた......いったんごっそり消しておこうｗ
----------------------------------------------------------------------
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/amrd0s1g 23793186 20773904 1115828 95% /home
----------------------------------------------------------------------
で，やっと処理し終えたようで (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
----------------------------------------------------------------------
しかし，これもまた......いったんごっそり消しておこうｗ
----------------------------------------------------------------------
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/amrd0s1g 23793186 20773904 1115828 95% /home
----------------------------------------------------------------------
>>94
・通信速度のアップグレード
・p2.2ch.io と c2.2ch.io の間の直結(2nd I/F 使用)
を、今メールでお願いしました。
次にリブートすると設定が変わるように /etc/rc.conf を設定して、
スイッチの設定変えたらサーバリセットしてかまわない、
と伝えました。。
・通信速度のアップグレード
・p2.2ch.io と c2.2ch.io の間の直結(2nd I/F 使用)
を、今メールでお願いしました。
次にリブートすると設定が変わるように /etc/rc.conf を設定して、
スイッチの設定変えたらサーバリセットしてかまわない、
と伝えました。。
>>96-99 乙です．
あけましておめでとうございます．本年もよろしくです．
さて，まだ 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
----------------------------------------------------------------------
さて，まだ 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
----------------------------------------------------------------------
2007/01/02(火) 08:54:09ID:JrHqPAKb0
関連キーワードをおすすめ2ちゃんねるみたいにCGIを叩かずに取得できるようにして欲しい。
スレの話題が分かりやすくて便利なので。
スレの話題が分かりやすくて便利なので。
>>102 read.cgi に直接組み込むってことですか？ そうすると read.cgi 自体が重くなる要因になるような......
# p2.2ch.io が重くなっても read.cgi の表示そのものに影響を与えないように今の形になってるんで......
# p2.2ch.io が重くなっても read.cgi の表示そのものに影響を与えないように今の形になってるんで......
2007/01/02(火) 09:40:16ID:37jTXRkI0
>>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 分のキーワードを抽出した，と......
パーサは相変わらずフル回転ですがｗ
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
それはともかく，表示用キーワード抽出を始める前にあらかじめ約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 分のキーワードを抽出した，と......
パーサは相変わらずフル回転ですがｗ
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
2007/01/02(火) 12:28:47ID:JrHqPAKb0
2chブラウザに関連キーワードを組み込むときに、毎回CGIを叩くのは負荷がかかりそう。
別にいいなら今の仕様でもいいんだけど。
別にいいなら今の仕様でもいいんだけど。
2007/01/02(火) 12:38:25ID:37jTXRkI0
リンク先がこんな風になってるのは仕様でしょうか。
http://find.2ch.net/?BBS=ALL&;amp;TYPE=TITLE&ENCODING=SJIS&STR=workers
専ブラで読み込ませたらfindのトップに飛ばされた
http://find.2ch.net/?BBS=ALL&;amp;TYPE=TITLE&ENCODING=SJIS&STR=workers
専ブラで読み込ませたらfindのトップに飛ばされた
iframe が height=15 だと 3pix ほど足りなくて下のほうが欠けています（firefox2@win）
height=18 程度に増やすか、文字を小さくしてもらえないでしょうか？
height=18 程度に増やすか、文字を小さくしてもらえないでしょうか？
>>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; にしますた．
そのうち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; にしますた．
2007/01/02(火) 19:06:51ID:JrHqPAKb0
10個全部表示しちゃえばいいのに
>>110
ありがとうございます♪
ありがとうございます♪
いつの間にか，雪だるまや 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/
ってことは，時間制限なしで 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側でランダム表示にしちゃうとか。
javascript側でランダム表示にしちゃうとか。
2007/01/03(水) 22:24:55ID:sDOHP3VQ0
そもそも、たかが10個のうち7個をランダムで表示する必要があるのだろうか。
100個あるならともかく。
100個あるならともかく。
表示できる文字数の問題だったり。
117動け動けウゴウゴ２ちゃんねる
2007/01/03(水) 23:55:20ID:Dn3KZWNbO テスト
今年もよろしくお願いいたします。
まずは、MySQL のインストールからですね。
普通に 5.x を入れればいいのかしら。
何か特別な設定が必要な場合、ここで教えてくださいです。
まずは、MySQL のインストールからですね。
普通に 5.x を入れればいいのかしら。
何か特別な設定が必要な場合、ここで教えてくださいです。
で、10Mbps → 100Mbps ですが、
どうも依頼がうまく受け付けられていないようなので、
メールでたんたんと依頼(催促)するということで。
どうも依頼がうまく受け付けられていないようなので、
メールでたんたんと依頼(催促)するということで。
5.xの最新のものをいれてくださいー。
tf-idfを2chDB自体を使ってやるとすると、
sennaは必須になりますね。。と。
sennaは必須になりますね。。と。
2007/01/04(木) 16:46:10ID:vF0Lqd4Y0
今年ひろゆき創めてみたわ
>>122
これですか。
Senna 組み込み型全文検索エンジン
http://qwik.jp/senna/FrontPageJ.html
これ入れればいいのかな。
/usr/ports/textproc/senna
MySQL とともに、入れておくです。
これですか。
Senna 組み込み型全文検索エンジン
http://qwik.jp/senna/FrontPageJ.html
これ入れればいいのかな。
/usr/ports/textproc/senna
MySQL とともに、入れておくです。
>>114
HTML モード（鯖側でランダム表示・Last-Modified なし）:
http://p2.2ch.io/getf.cgi?http://qb5.2ch.net/test/read.cgi/operate/1166328527/
JavaScript モード（クライアント側でランダム表示・Last-Modified あり）:
http://p2.2ch.io/getf.cgi?qb5.2ch.net+operate+1166328527
で，とりあえず read.js では JavaScript モードの方を使ってます．
>>118-119 こちらこそよろしくです．で，入れてもらうのは MeCab と MySQL ですね．留意事項ですが
* mecab-0.93
* mecab-perl-0.93
* mecab-ipadic-2.7.0-20060707
MeCab はデフォルトでは EUC-JP を使うのですが，Shift JIS を使うようにビルドして下さい．
その場合，ports だとどうだかわかりませんが，少なくともオリジナル版だと configure 時に
CPPFLAGS=-I/usr/local/include LDFLAGS='-L/usr/local/lib -R/usr/local/lib' を
指定しないと libiconv の存在を認識してくれないので，Shift JIS の辞書を作れません．
で，辞書 (mecab-ipadic) の configure 時に --with-charset=sjis を指定してもらう，と．
* mysql-5.0.27
設定ファイル (my.cnf) は，現在 my-large.cnf をベースにして
[mysqld] のセクションに以下の設定を追加しています．
bind-address = private_address_of_c2.2ch.io
character-set-server = cp932
collation-server = cp932_bin
あと，レプリケーションとかやらなければバイナリログなしでいいのかな．
少なくとも，今のところ MySQL は分散処理とか考えなきゃならんほど重くないですし．
バイナリログなしなら
log-bin=mysql-bin
の行はコメントアウトで．
# バイナリログのサイズもバカにならないんで......
# -rw-rw---- 1 c22chio ch2 1073742810 1 1 12:57 mysql-bin.000001
# -rw-rw---- 1 c22chio ch2 1073741960 1 3 10:33 mysql-bin.000002
# -rw-rw---- 1 c22chio ch2 830519196 1 4 16:56 mysql-bin.000003
あと，すでにこんだけ容量食ってるんで，データディレクトリは /home 配下に作らないと入らないと思います......
654 data/mysql
2 data/test
3136188 data/keywords
6068946 data
HTML モード（鯖側でランダム表示・Last-Modified なし）:
http://p2.2ch.io/getf.cgi?http://qb5.2ch.net/test/read.cgi/operate/1166328527/
JavaScript モード（クライアント側でランダム表示・Last-Modified あり）:
http://p2.2ch.io/getf.cgi?qb5.2ch.net+operate+1166328527
で，とりあえず read.js では JavaScript モードの方を使ってます．
>>118-119 こちらこそよろしくです．で，入れてもらうのは MeCab と MySQL ですね．留意事項ですが
* mecab-0.93
* mecab-perl-0.93
* mecab-ipadic-2.7.0-20060707
MeCab はデフォルトでは EUC-JP を使うのですが，Shift JIS を使うようにビルドして下さい．
その場合，ports だとどうだかわかりませんが，少なくともオリジナル版だと configure 時に
CPPFLAGS=-I/usr/local/include LDFLAGS='-L/usr/local/lib -R/usr/local/lib' を
指定しないと libiconv の存在を認識してくれないので，Shift JIS の辞書を作れません．
で，辞書 (mecab-ipadic) の configure 時に --with-charset=sjis を指定してもらう，と．
* mysql-5.0.27
設定ファイル (my.cnf) は，現在 my-large.cnf をベースにして
[mysqld] のセクションに以下の設定を追加しています．
bind-address = private_address_of_c2.2ch.io
character-set-server = cp932
collation-server = cp932_bin
あと，レプリケーションとかやらなければバイナリログなしでいいのかな．
少なくとも，今のところ MySQL は分散処理とか考えなきゃならんほど重くないですし．
バイナリログなしなら
log-bin=mysql-bin
の行はコメントアウトで．
# バイナリログのサイズもバカにならないんで......
# -rw-rw---- 1 c22chio ch2 1073742810 1 1 12:57 mysql-bin.000001
# -rw-rw---- 1 c22chio ch2 1073741960 1 3 10:33 mysql-bin.000002
# -rw-rw---- 1 c22chio ch2 830519196 1 4 16:56 mysql-bin.000003
あと，すでにこんだけ容量食ってるんで，データディレクトリは /home 配下に作らないと入らないと思います......
654 data/mysql
2 data/test
3136188 data/keywords
6068946 data
>>125
> MeCab はデフォルトでは EUC-JP を使うのですが，Shift JIS を使うようにビルドして下さい．
おぉ、なるほど。
入れなおしっすね。senna もそうかな。
では、そのように。
> MeCab はデフォルトでは EUC-JP を使うのですが，Shift JIS を使うようにビルドして下さい．
おぉ、なるほど。
入れなおしっすね。senna もそうかな。
では、そのように。
* DBD-mysql-4.00
元々 3.0008 が入ってたんですが，いくつか問題があったので自分で入れた 4.00（+ 若干修正）を使ってます．
・ server side prepare を有効にしていると LOAD DATA INFILE が使えない（3.0008 での問題，4.00 は Ok）．
・ server side prepare を有効にしかつ SQL 文中で placeholders を使うと，
2回目以降の execute() で SIGSEGV になる（4.00 でも存在する問題，自分で修正）．
・ CALL ステートメント（stored procedure の呼び出し）で server side prepare が無効にされてしまう（これも自分で修正）．
まぁ，修正といっても微々たるもんですが．
--- DBD-mysql-4.00/dbdimp.c Sun Dec 24 23:04:59 2006
+++ DBD-mysql-4.00/dbdimp.c Sun Dec 31 18:30:00 2006
@@ -2485,2 +2485,3 @@
+#if 0
if ( (tolower(*(str_ptr + 0)) == 'c') &&
@@ -2495,2 +2496,3 @@
}
+#endif
@@ -3766,2 +3768,3 @@
}
+#if 0
/* clean up other statement allocations */
@@ -3779,2 +3782,3 @@
num_fields= DBIc_NUM_FIELDS(imp_sth);
+#endif
あと，c2 の方でも httpd がたくさん立ち上がってるんですが，
こっちは必要最低限の数だけでいいような......
>>122 ん〜と，以前そう言われたことがあってそうしなきゃならんのかなぁ，
と思いつつ考えてたんですが，Senna って全文検索エンジンですよね．
使うとすれば，ドキュメント全体を MySQL に入れるってことでしょうか？
今のやり方は，表示用キーワードとは別に DF 計算用の単語も
登録してるんですが，ドキュメント全体ではなく切り出した単語を
個別に登録してまして，全文検索は行ってません．っていうか，
ドキュメント全体を登録してると HDD 容量が半端ないぐらい必要になるような......
元々 3.0008 が入ってたんですが，いくつか問題があったので自分で入れた 4.00（+ 若干修正）を使ってます．
・ server side prepare を有効にしていると LOAD DATA INFILE が使えない（3.0008 での問題，4.00 は Ok）．
・ server side prepare を有効にしかつ SQL 文中で placeholders を使うと，
2回目以降の execute() で SIGSEGV になる（4.00 でも存在する問題，自分で修正）．
・ CALL ステートメント（stored procedure の呼び出し）で server side prepare が無効にされてしまう（これも自分で修正）．
まぁ，修正といっても微々たるもんですが．
--- DBD-mysql-4.00/dbdimp.c Sun Dec 24 23:04:59 2006
+++ DBD-mysql-4.00/dbdimp.c Sun Dec 31 18:30:00 2006
@@ -2485,2 +2485,3 @@
+#if 0
if ( (tolower(*(str_ptr + 0)) == 'c') &&
@@ -2495,2 +2496,3 @@
}
+#endif
@@ -3766,2 +3768,3 @@
}
+#if 0
/* clean up other statement allocations */
@@ -3779,2 +3782,3 @@
num_fields= DBIc_NUM_FIELDS(imp_sth);
+#endif
あと，c2 の方でも httpd がたくさん立ち上がってるんですが，
こっちは必要最低限の数だけでいいような......
>>122 ん〜と，以前そう言われたことがあってそうしなきゃならんのかなぁ，
と思いつつ考えてたんですが，Senna って全文検索エンジンですよね．
使うとすれば，ドキュメント全体を MySQL に入れるってことでしょうか？
今のやり方は，表示用キーワードとは別に DF 計算用の単語も
登録してるんですが，ドキュメント全体ではなく切り出した単語を
個別に登録してまして，全文検索は行ってません．っていうか，
ドキュメント全体を登録してると HDD 容量が半端ないぐらい必要になるような......
DF 計算用の単語の切り出し方によると思いますが、
母集団を反映してる標本なら、
それでもいいと思いますー。
母集団を反映してる標本なら、
それでもいいと思いますー。
>>128 今は，各 URL ごとに TF が上位 200 までの単語を登録してます．
仕組み的には，この数をもっと増やすことも不可能ではありませんが，
HDD 消費量やパフォーマンスなどとのバランスを考えるとこのぐらいかなぁ，と......
mysql> SELECT (SELECT COUNT(*) FROM urls) 'URL 総数', (SELECT COUNT(*) FROM words) '単語総数', (SELECT COUNT(*) FROM regwords) 'DF 計算用単語の URL との関連付け総数', (SELECT COUNT(*) FROM dispwords) '表示用単語の URL との関連付け総数';
+----------+----------+--------------------------------------+-----------------------------------+
| URL 総数 | 単語総数 | DF 計算用単語の URL との関連付け総数 | 表示用単語の URL との関連付け総数 |
+----------+----------+--------------------------------------+-----------------------------------+
| 465918 | 1064955 | 73515988 | 4320516 |
+----------+----------+--------------------------------------+-----------------------------------+
-rw-rw---- 1 c22chio ch2 108017350 1 4 22:14 dispwords.MYD
-rw-rw---- 1 c22chio ch2 75264000 1 4 22:14 dispwords.MYI
-rw-rw---- 1 c22chio ch2 8632 1 1 20:13 dispwords.frm
-rw-rw---- 1 c22chio ch2 1604234751 1 4 22:14 regwords.MYD
-rw-rw---- 1 c22chio ch2 1312161792 1 4 22:14 regwords.MYI
-rw-rw---- 1 c22chio ch2 8626 1 1 20:19 regwords.frm
-rw-rw---- 1 c22chio ch2 34500696 1 4 22:14 urls.MYD
-rw-rw---- 1 c22chio ch2 20992000 1 4 22:14 urls.MYI
-rw-rw---- 1 c22chio ch2 8694 1 1 20:13 urls.frm
-rw-rw---- 1 c22chio ch2 33554972 1 4 22:14 words.MYD
-rw-rw---- 1 c22chio ch2 44557312 1 4 22:14 words.MYI
-rw-rw---- 1 c22chio ch2 8612 1 1 20:13 words.frm
仕組み的には，この数をもっと増やすことも不可能ではありませんが，
HDD 消費量やパフォーマンスなどとのバランスを考えるとこのぐらいかなぁ，と......
mysql> SELECT (SELECT COUNT(*) FROM urls) 'URL 総数', (SELECT COUNT(*) FROM words) '単語総数', (SELECT COUNT(*) FROM regwords) 'DF 計算用単語の URL との関連付け総数', (SELECT COUNT(*) FROM dispwords) '表示用単語の URL との関連付け総数';
+----------+----------+--------------------------------------+-----------------------------------+
| URL 総数 | 単語総数 | DF 計算用単語の URL との関連付け総数 | 表示用単語の URL との関連付け総数 |
+----------+----------+--------------------------------------+-----------------------------------+
| 465918 | 1064955 | 73515988 | 4320516 |
+----------+----------+--------------------------------------+-----------------------------------+
-rw-rw---- 1 c22chio ch2 108017350 1 4 22:14 dispwords.MYD
-rw-rw---- 1 c22chio ch2 75264000 1 4 22:14 dispwords.MYI
-rw-rw---- 1 c22chio ch2 8632 1 1 20:13 dispwords.frm
-rw-rw---- 1 c22chio ch2 1604234751 1 4 22:14 regwords.MYD
-rw-rw---- 1 c22chio ch2 1312161792 1 4 22:14 regwords.MYI
-rw-rw---- 1 c22chio ch2 8626 1 1 20:19 regwords.frm
-rw-rw---- 1 c22chio ch2 34500696 1 4 22:14 urls.MYD
-rw-rw---- 1 c22chio ch2 20992000 1 4 22:14 urls.MYI
-rw-rw---- 1 c22chio ch2 8694 1 1 20:13 urls.frm
-rw-rw---- 1 c22chio ch2 33554972 1 4 22:14 words.MYD
-rw-rw---- 1 c22chio ch2 44557312 1 4 22:14 words.MYI
-rw-rw---- 1 c22chio ch2 8612 1 1 20:13 words.frm
んでは、SUNOSさんの方式で試してみましょー。
何かゴミデータが混ざってるな，と思ったら...... server side prepare モードは
DBD::mysql の作者もちゃんとテストしてないんですかね．>>127 のパッチからさらに修正．
--- DBD-mysql-4.00/dbdimp.c Sun Dec 24 23:04:59 2006
+++ DBD-mysql-4.00/dbdimp.c Sat Jan 6 06:00:00 2007
@@ -2485,2 +2485,3 @@
+#if 0
if ( (tolower(*(str_ptr + 0)) == 'c') &&
@@ -2495,2 +2496,3 @@
}
+#endif
@@ -3766,2 +3768,3 @@
}
+#if 0
/* clean up other statement allocations */
@@ -3779,2 +3782,3 @@
num_fields= DBIc_NUM_FIELDS(imp_sth);
+#endif
@@ -4457,3 +4461,3 @@
/* Type of column was changed. Force to rebind */
- if (imp_sth->bind[idx].buffer_type != buffer_type)
+ /* if (imp_sth->bind[idx].buffer_type != buffer_type) */
imp_sth->has_been_bound = 0;
DBD::mysql の作者もちゃんとテストしてないんですかね．>>127 のパッチからさらに修正．
--- DBD-mysql-4.00/dbdimp.c Sun Dec 24 23:04:59 2006
+++ DBD-mysql-4.00/dbdimp.c Sat Jan 6 06:00:00 2007
@@ -2485,2 +2485,3 @@
+#if 0
if ( (tolower(*(str_ptr + 0)) == 'c') &&
@@ -2495,2 +2496,3 @@
}
+#endif
@@ -3766,2 +3768,3 @@
}
+#if 0
/* clean up other statement allocations */
@@ -3779,2 +3782,3 @@
num_fields= DBIc_NUM_FIELDS(imp_sth);
+#endif
@@ -4457,3 +4461,3 @@
/* Type of column was changed. Force to rebind */
- if (imp_sth->bind[idx].buffer_type != buffer_type)
+ /* if (imp_sth->bind[idx].buffer_type != buffer_type) */
imp_sth->has_been_bound = 0;
DBD::mysqlってよくつかわれてそうなのに。。
133耐
2007/01/06(土) 19:49:16ID:FcjBKnL90 このやろうなめやがって！！
>>132 DBD::mysql 自体はよく使われてても，server side prepare は
デフォルトでは off なのであまり使われてないのかも......
http://search.cpan.org/~capttofu/DBD-mysql-4.00/lib/DBD/mysql.pm
Prepared statement support (server side prepare)
As of 3.0002_1, server side prepare statements were on by default (if your server was >= 4.1.3).
As of 3.0009, they were off by default again due to issues with the prepared statement API
(all other mysql connectors are set this way until C API issues are resolved).
The requirement to use prepared statements still remains that you have a server >= 4.1.3
To use server side prepared statements, all you need to do is set the variable mysql_server_prepare in the connect:
$dbh = DBI->connect( "DBI:mysql:database=test;host=localhost;mysql_server_prepare=1", "", "", { RaiseError => 1, AutoCommit => 1 } );
* Note: delimiter for this param is ';'
There are many benefits to using server side prepare statements, mostly if you are performing many inserts
because of that fact that a single statement is prepared to accept multiple insert values.
デフォルトでは off なのであまり使われてないのかも......
http://search.cpan.org/~capttofu/DBD-mysql-4.00/lib/DBD/mysql.pm
Prepared statement support (server side prepare)
As of 3.0002_1, server side prepare statements were on by default (if your server was >= 4.1.3).
As of 3.0009, they were off by default again due to issues with the prepared statement API
(all other mysql connectors are set this way until C API issues are resolved).
The requirement to use prepared statements still remains that you have a server >= 4.1.3
To use server side prepared statements, all you need to do is set the variable mysql_server_prepare in the connect:
$dbh = DBI->connect( "DBI:mysql:database=test;host=localhost;mysql_server_prepare=1", "", "", { RaiseError => 1, AutoCommit => 1 } );
* Note: delimiter for this param is ';'
There are many benefits to using server side prepare statements, mostly if you are performing many inserts
because of that fact that a single statement is prepared to accept multiple insert values.
現状ってあとは何が足りないんでしたっけ？
136動け動けウゴウゴ２ちゃんねる
2007/01/08(月) 22:50:59ID:EY1iKiNMP で、>>137 は、たんたんとすすめるです。
よろしくですー。
>>137 そんなところですね．ということでよろしくおながいします．
で，MySQL を入れるのは最初 p2 がいいかなと思ってたんですが，
現状を鑑みれば c2 の方が良さそうという気がしてます．
p2 で mod_speedycgi を使うということで prefork MPM 利用は確定のようですし，
そうなると p2 に MySQL を入れるとなるとメモリやコンテキストスイッチなどの
競合できつくなりそうですし．c2 でもパーサがフル回転してる時は CPU で競合しますが，
データ収集が一巡してからはパーサも常時フル回転ではなくなってますし（で，2日以上経過した
データから順次再クロールする処理も入れますたが，それも比較的余力を持ってこなしてますし）．
p2 でもピーク時間帯はどっちにしろ CPU 食いますし，c2 ではプロセス数の少なさから
メモリやコンテキストスイッチなどで競合しにくいだろう，ってことで．
で，MySQL を入れるのは最初 p2 がいいかなと思ってたんですが，
現状を鑑みれば c2 の方が良さそうという気がしてます．
p2 で mod_speedycgi を使うということで prefork MPM 利用は確定のようですし，
そうなると p2 に MySQL を入れるとなるとメモリやコンテキストスイッチなどの
競合できつくなりそうですし．c2 でもパーサがフル回転してる時は CPU で競合しますが，
データ収集が一巡してからはパーサも常時フル回転ではなくなってますし（で，2日以上経過した
データから順次再クロールする処理も入れますたが，それも比較的余力を持ってこなしてますし）．
p2 でもピーク時間帯はどっちにしろ CPU 食いますし，c2 ではプロセス数の少なさから
メモリやコンテキストスイッチなどで競合しにくいだろう，ってことで．
- 10Mbps → 100Mbps
- p2 ⇔ c2 クロスケーブルで直結
について、再度メールで依頼しました。
関係者に Cc:。
- p2 ⇔ c2 クロスケーブルで直結
について、再度メールで依頼しました。
関係者に Cc:。
2007/01/11(木) 03:08:24ID:VhKIX1KV0
>>135
スレ同士の自動リンクツールとするならもう少し人為を反映する仕様があったほうがいいような
スレ同士の自動リンクツールとするならもう少し人為を反映する仕様があったほうがいいような
2007/01/16(火) 03:57:50ID:kO1prtGV0
今現在までの閉鎖騒動関連スレを幾つか見たけど
「24」を地で行くようなちょろの奮闘が眩しかった。
ひ(ryが2chを、というより、2chがこの男を失うか否かというような。
そんな風に見えなくもない今回の騒動。
「24」を地で行くようなちょろの奮闘が眩しかった。
ひ(ryが2chを、というより、2chがこの男を失うか否かというような。
そんな風に見えなくもない今回の騒動。
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【テレビ】中居正広出演『ザ！世界仰天ニュース4時間SP』日テレ「現時点で変更の予定はございません」 [Ailuropoda melanoleuca★]
- 山陽新幹線で乗客が非常ボタン 車掌に切符の問い合わせしようと [蚤の市★]
- ドイツ、軍拡時代に逆戻りする、米国も国連も頼れないため 軍事力増強に走る [お断り★]
- 【テレビ】中居正広の‟9000万円トラブル“をキー局が報じないウラに「暗黙の紳士協定」という悪癖 [阿弥陀ヶ峰★]
- 【コンビニ】セブン-イレブン「うれしい値！」で客数増加 20代男性と女性の新規顧客を獲得 300品に拡充し今後も継続 [煮卵★]
- 滋賀からもルート再考論 北陸新幹線延伸 衆参議員が「米原」推し 「小浜は京都の理解得られぬ」 [蚤の市★]
- 【NJPW】新日本プロレスワールド part.2196
- 【NJPW】新日本プロレスワールド part.2195
- 中山競馬1回2日目 2
- 中京競馬1回1日目 2
- 競輪実況★1267
- 【ATP】テニス総合実況スレ2025 Part 6【WTA】
- 【実況】博衣こよりのえちえち五目並べ🧪
- 変な🏡
- 知的障害者出禁🙅🏻‍♂🏡
- 【増税】軽自動車の自動車税15%UP もう終わりだよこの国 [754099271]
- 尹大統領、初の支持率40%突破ㅤ [237216734]
- 将棋AI「先手の勝率が7割超えました。後手も公平になるルールを考えてください」 [858219337]