06/12/17 13:08:47 0 BE:113292-S★(101667)
read.cgiの片隅に表示されている関連キーワードを
きちんとメンテナンスしてみようなスレッド。
2:動け動けウゴウゴ２ちゃんねる
06/12/17 13:21:13 4jYrj3pWO
2get
3:外出中 ◆MUMUMUhnYI
06/12/17 13:40:53 0jOWSCkU0
お、スレ来ましたか。
先日管理人からお誘いがきたです。
もう一人、超強力な人（仮名）が呼ばれている様子。
4:▲ ◆SANUKI/VII
06/12/17 13:48:55 7/a4LIUQP BE:10872083-DIA(66779)
はろゆき
5: [´・ω・｀] 124-144-98-94.rev.home.ne.jp(124.144.98.94) 株価【1300】 ▲▲▲▲ ◆cZfSunOs.U
06/12/17 13:49:15 wNcpXAtu0
>>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
6:es ◆MUMUMUhnYI
06/12/17 13:59:02 P7zLICKl0
>>5
超強力な人だ。
これまでの経緯や進捗などについては、
帰宅後にでもここにぼちぼちと。
7:es ◆MUMUMUhnYI
06/12/17 14:02:29 EyZpTx1c0
で、/proc を mount する作業についても、
帰宅後に進めるです。
8:動け動けウゴウゴ２ちゃんねる
06/12/17 19:56:03 vlTtZt4FQ
専ブラや携帯でも習得できるといいな
9:root▲ ★
06/12/17 21:20:43 0 BE:1642436-PLT(20123)
>>7 done.
10:root▲ ★
06/12/17 21:58:42 0 BE:5746379-PLT(20123)
■ これまでのまとめ
2006年の4月頃、read.cgi の出力の上のほうに「関連キーワード」を
表示する機能を、管理人がつけました。
URLﾘﾝｸ(qb5.2ch.net) の 490-
プログラムは管理人が作成したプロトタイプ版でした。
まずプロトタイプ版で動かし将来よくしていこう、という目論見だったようです。
URLﾘﾝｸ(qb5.2ch.net) の 496
現在でもこの機能は、一部サーバで動いています。
* 全サーバでの動作はさせていません(負荷問題)
* 負荷軽減のため21時から2時まではリクエストの処理をしていません(同上)
また、事情により最近立ったスレッドではこの機能は動いていないそうです(by 管理人)
* キーワード【準備中】 になっているもの
このような状況の中、管理人からSunOSさんと私に、
「これ、やってみませんかー」というオファーが来ました。
そして、相談の結果、オファーを受けてみることとしました。
11:root▲ ★
06/12/17 22:08:50 0 BE:1641863-PLT(20123)
■ これまでにすすめたこと
・先日管理人・SunOSさん・私の3人でオフラインで会い、現在の状況の確認をしました。
(管理人が手ずからペンとスケッチブックを持ってきて、絵を描いて説明しました)
・このためのサーバを2台準備し、私がインフラ部分の基本環境を作りました。
p2.2ch.io と c2.2ch.io になります。
・管理人が今日、このスレを立てました。
そんなわけで例によって、表でわいわいやっていくことになりました。
・現在 SunOS さんが中身の開発をすすめているところです。
というわけでどんな構想で作っておられるか等については、
ぼちぼちとここでやっていくのがいいのかなと思います。
例によって今後進めていく作業者間の作業連絡等も、
表ででやれるところについては(パスワードとかセキュリティ関係じゃないものとか)、
ここでやっていけるといいのかなと。
こんなところで。
12:ひろゆき＠どうやら管理人 ★
06/12/17 22:14:23 0 BE:189465-S★(101667)
よろしくです。よろしくです。
13:root▲ ★
06/12/17 22:25:03 0 BE:3648285-PLT(20123)
>>12
はい。
組むのはあまり戦力にならないので、
例によってインフラ整備系とかネットワーク系でがんがってみようかと。
14:動け動けウゴウゴ２ちゃんねる
06/12/18 00:52:19 mIMTUYYw0
あんまりガンガリ過ぎない程度にね、、、
15:root▲ ★
06/12/18 15:10:27 0 BE:821333-PLT(20123)
SunOS さんからの依頼により、
[cp]2.2ch.io の libcurl を 7.16.0 に更新しました。
16: 株価【1900】 ▲▲▲▲ ◆cZfSunOs.U
06/12/18 15:32:22 Pg0NFWte0
>>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:ひろゆき＠どうやら管理人 ★
06/12/18 18:39:11 0 BE:265076-S★(101668)
自前で完結するとなると全体のデータの中の単語量を調べるってので、
なんとかなるかもかも。
でも、ある程度大きな規模のデータがないと
結果に偏りが出ると思います。
18:動け動けウゴウゴ２ちゃんねる
06/12/18 19:03:41 VjfjyBvg0
人が少ないスレ・板だと、やっぱり恥ずかしい思いをすることになるのかな。
19: 株価【1280】 ▲▲▲▲ ◆cZfSunOs.U
06/12/18 19:22:56 Pg0NFWte0
>>17 ですねぇ．最初のうちしばらくは，キーワード表示はせず単語データ収集のためだけに動かすとか......
で，クローラをがんがん動かすことになると，バーボンに引っかからないようにしてもらった方がいいのかも．
あと，DB (MySQL) もぼちぼち立ち上げてもらった方がいいのかも．
20:ひろゆき＠どうやら管理人 ★
06/12/18 19:29:44 0 BE:75762-S★(101668)
全体の単語量を調べるのであれば、Ngramのsennaとか入れたほうがいいかもです。
＞MySQL
21:root▲ ★
06/12/18 19:38:41 0 BE:5107878-PLT(20123)
>>19
MySQL は帰宅後にでも。
# なお、私は MySQL のチューニングについてはほとんど素人です。
22:root▲ ★
06/12/18 19:38:59 0 BE:3831067-PLT(20123)
>>20
あとでみてみるです。
23:ひろゆき＠どうやら管理人 ★
06/12/18 19:39:21 0 BE:152238-S★(101668)
MySQLを覚えるいい機会が出来てなによりです。
えぇえぇ。
24:動け動けウゴウゴ２ちゃんねる
06/12/18 19:41:46 RjC/hzvl0
発想が前向きですね
25: 株価【1305】 ▲▲▲▲ ◆cZfSunOs.U
06/12/18 19:42:10 Pg0NFWte0
>>20 これですか． URLﾘﾝｸ(qwik.jp)
>>21 まぁ，パーサはこれから作るって段階なので，急ぎではないです＜MySQL
26:root▲ ★
06/12/18 19:42:36 0 BE:1642829-PLT(20123)
>>23
そうですね、、、。
むぎゅ。
27:root▲ ★
06/12/18 22:24:41 0 BE:4378368-PLT(20123)
>>19
サーバは、p2/c2 どちらで上げましょうか。
28: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/18 23:41:51 Pg0NFWte0
>>27 そうですねぇ......とりあえず p2 の方でおながいします．
29:root▲ ★
06/12/19 00:24:04 0 BE:2736656-PLT(20123)
>>28
了解です。
# ちと明日とても早いので、明日以降に。すんませんです。
30: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 00:43:02 vxArqrvO0
>>29 急ぎではないので，ゆっくりでいいです．
31: 株価【1300】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 09:55:09 nvgnQ4Zi0
試しにクローラ部分だけぶん回す実験をちょっとしてみようとか思ったりも
するんですが，今 read.cgi 画面から読み込まれてる p.2ch.io のやつを
p2.2ch.io に変えちゃったりしてもいいんですかね？
あと，c2.2ch.io をバーボン対象から外さないと引っかかる可能性も
あるかも知れないですが，外してもいいんですかね？
それと......[cp]2.2ch.io には LAN セグメントは1つしかつながってないようですが，
[cp]2.2ch.io 同士のやりとりのためにプライベートアドレスを論理 I/F というか
alias で付与するとかは可能なんですかね......？
32:root▲ ★
06/12/19 10:03:33 0 BE:2189164-PLT(20123)
>>31
> 今 read.cgi 画面から読み込まれてる p.2ch.io のやつを
> p2.2ch.io に変えちゃったりしてもいいんですかね？
様子を見ながらなら、いいんではないでしょうか。
> c2.2ch.io をバーボン対象から外さないと引っかかる可能性も
> あるかも知れないですが，外してもいいんですかね？
リロードバーボンですね。
心配要らないはず。理由は別途メールででも。
> プライベートアドレスを論理 I/F というか
> alias で付与するとかは可能なんですかね......？
できるはず。
ちょっとトライしてみます。
33:root▲ ★
06/12/19 10:06:23 0 BE:821333-PLT(20123)
というか、、、。
p2 と c2 の間の通信って、多くなりそうなのかしら。
それなら 100Mbps に I/F を変更してもらったほうがいいのかなと。
34: 株価【1300】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 10:13:56 nvgnQ4Zi0
>>32-33 乙です．
>リロードバーボンですね。
>心配要らないはず。理由は別途メールででも。
あ，そうだったんですか．
>p2 と c2 の間の通信って、多くなりそうなのかしら。
とりあえず思い付くものとして
・ p2 から c2 にクロールすべき URL を投げる．
・ c2 から p2 にレコード登録のための MySQL のクエリーを投げる．
これらがどの程度か，ってところですかねぇ......
35:root▲ ★
06/12/19 10:15:27 0 BE:6567089-PLT(20123)
[cp]2 にプライベートアドレスを振りました。
いくつを振って、それがどのような名前で参照できるかは、
セキュリティ上ここでは書かないので、
すみませんが該当サーバの /etc/hosts あたりを見ていただけると。
36:root▲ ★
06/12/19 10:18:19 0 BE:3192375-PLT(20123)
>>34
> あ，そうだったんですか．
というか、管理人が自らのためにやるもの(ブラジル等)については、
そもそもリロードバーボンの対象外にする(している)という話ですね。
> とりあえず思い付くものとして
> ...
> これらがどの程度か，ってところですかねぇ......
統計とってみるですかね。
これは別途。
37: 株価【1300】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 10:21:55 nvgnQ4Zi0
>>35 乙です，確認しますた．
38: 株価【1300】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 11:26:46 nvgnQ4Zi0
URLﾘﾝｸ(p2.2ch.io)ｽﾚﾘﾝｸ(operate板)l50
のように呼ぶと crawld に dat の URL 投げるようにしますた．
さて，やってみるかな......＜read.cgi 画面から読み込み
39:ひろゆき＠どうやら管理人 ★
06/12/19 12:56:01 0 BE:397297-S★(101768)
わくわく。
40:root▲ ★
06/12/19 14:50:25 0 BE:5107878-PLT(20123)
おぉ。はじまっている。
crawld を自動起動するしかけ等が必要になったら、
ここでお知らせくださいです。
41: 株価【1300】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 15:26:10 nvgnQ4Zi0
>>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 レスポンスが増えてくると差が縮まって追い付いてきてる感じかなぁ．
これを見ると，ネックはネットワーク帯域？
42:root▲ ★
06/12/19 15:31:38 0 BE:1915373-PLT(20123)
>>41
> これを見ると，ネックはネットワーク帯域？
まずは計測してみるです。
そのうえで、次の手を。
43: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 19:30:07 nvgnQ4Zi0
いつの間にか p2 が p に戻ってたんですが......重かったからかな？
まぁ，c2 が涼しい顔してた一方で p2 は忙しそうでしたが......
getf.cgi はとりあえず SpeedyCGI で書いてたんですが，
DSO にした方がいいのかなぁ......
44:root▲ ★
06/12/19 19:36:30 0 BE:2736656-PLT(20123)
>>43
> いつの間にか p2 が p に戻ってたんですが......重かったからかな？
きっと、あっちの繁盛しているスレの作業と、
更新作業がバッティングしたんではないかと。
で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。
URLﾘﾝｸ(mumumu.mu)
45: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 19:41:23 nvgnQ4Zi0
>>44 あ，じゃあ誰かが意図的に戻したんじゃなかったんですね．
じゃあちょろさんにお願いすればいいのか．
>で、とりあえずトラフィックと httpd へのアクセス数をとりはじめてみた。
乙です．
46:root▲ ★
06/12/19 19:50:09 0 BE:1641863-PLT(20123)
>>45
しばらくはあのスレあたりで「read.cgi 更新しますけどOKでしょうか」とか、
「更新しました」みたいなことをすればいいと思いますです。
今は絶賛上映中みたいなので、幕間にでも。
47:root▲ ★
06/12/19 19:50:59 0 BE:5837388-PLT(20123)
> じゃあちょろさんにお願いすればいいのか．
作業がバッティングしないのであれば、
更新はたんたんとやってしまってよいと思われ。
48:動け動けウゴウゴ２ちゃんねる
06/12/19 19:51:45 FsmnSRUQ0
サンプル
ｽﾚﾘﾝｸ(juvenile板)l50
とりあえず2ちゃんねる全体でその話題を独占しているようなスレだと
殆ど役に立たないような
49:root▲ ★
06/12/19 19:54:49 0 BE:2553874-PLT(20123)
それで、PHP は少なくとも今は使わないかんじみたいなので
(SunOS さんからによると)、
とりあえず、はずしておきます。< [pc]2.2ch.io
# PHP + eAccelerator なので、メモリをかなり食っているため。
50: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 19:57:05 nvgnQ4Zi0
>>46-47 今は，目下 dso でちょろさんらしき人がリアルタイムで
read.cgi の書き換え作業中のようですね．しばらく待ちますか......
>>49 とりあえずそれでいいと思います．
51: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 20:26:24 nvgnQ4Zi0
さて，p2 に戻すことができますた．ついでにテストのため時間制限も外してみた，とｗ
52:root▲ ★
06/12/19 20:27:08 0 BE:1916137-PLT(20123)
-M8 を -M32 ぐらいにしてもいいかも。
で、PHP はずして楽になったので、
httpd の数をもう少し増やしておきます。 < p2.2ch.io
53:root▲ ★
06/12/19 20:31:24 0 BE:5837388-PLT(20123)
ちと、p2 の httpd とめます。
54: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 20:32:17 nvgnQ4Zi0
>>52 乙です．
>-M8 を -M32 ぐらいにしてもいいかも。
そうしてみますた．
55:root▲ ★
06/12/19 20:34:00 0 BE:1916137-PLT(20123)
再挑戦。
SuExec はずした。
56:root▲ ★
06/12/19 20:35:06 0 BE:547632-PLT(20123)
落ち着いたかな。
これだけアクセスが多いと、suexec のオーバーヘッドがばかにできないですね。
57: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 20:37:34 nvgnQ4Zi0
>>55-56 乙です．まぁ PHP なしなら worker MPM にするってのもありでしょうし．
58:root▲ ★
06/12/19 20:38:24 0 BE:547632-PLT(20123)
>>57
今は dso から配ったやつ全部なんでしたっけ。
雪だるまとか news4vip とかはまだと。
59: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 20:41:02 nvgnQ4Zi0
>>58 配布は dso 上でしかやってませんです．
60:root▲ ★
06/12/19 20:42:13 0 BE:5107687-PLT(20123)
>>59
了解です。
61:root▲ ★
06/12/19 20:54:48 0 BE:1641492-PLT(20123)
きついかも、、、。
KeepAlive Off にしてみた。
62: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 20:55:20 nvgnQ4Zi0
ちょっと鯖名による選別も外してみますたが，かなり苦しそうだったのでそれは戻しますた......
63:root▲ ★
06/12/19 20:59:06 0 BE:365322-PLT(20123)
kern.ipc.maxpipekva exceeded; see tuning(7)
kern.ipc.maxpipekva exceeded; see tuning(7)
kern.ipc.maxpipekva exceeded; see tuning(7)
...
と出ているですね。
できる範囲で、ちと大きくします。
64:root▲ ★
06/12/19 21:02:39 0 BE:5837388-PLT(20123)
kern.ipc.maxpipekva=41943040
にしようかと思いましたが、ちょっと怖いですね。
メモリ4Gのサーバでは実績ありますが(雪だるまtiger/cobra)、
それ以外ではやったことがあったかどうか。
65: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 21:04:09 nvgnQ4Zi0
>>63-64 乙です．しかし，p2 は httpd だけで苦しいとなると，DB 鯖は独立させた方がいいかもですね．
c2 は c2 でパーサが重くなりそうだし．あと，c2 のトラフィック見ると
やはり 10M 近辺で張り付いてますね......
66:root▲ ★
06/12/19 21:07:31 0 BE:1368353-PLT(20123)
これは、大変ですね。
ちょっとオフラインになるので、いったん撤退に一票かな。
SpeedyCGI でももたないと。
67:root▲ ★
06/12/19 21:10:01 0 BE:1095326-PLT(20123)
というか管理人からは「どこまでいけるかを見極める」ことも目的だから、
いきなりほぼ全サーバに敷衍して負けだった、ということがわかった、
ということなのかなと。
で、>>65 にもありますが、可能であればデータリングは
100Mbps にしてもらったほうがよさそうなかんじですね。
# もう少ししたら、ちとオフライン。
68: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 21:10:32 nvgnQ4Zi0
>>66 時間制限も復活させました．で，今の時間は一休み，と......
69:root▲ ★
06/12/19 21:11:46 0 BE:3830876-PLT(20123)
で、p2 の httpd が売り切れにならないように、
起動されるやつをできるだけ軽く、コンパクトにするかんじかなと。
70: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/19 21:17:07 nvgnQ4Zi0
>>69 ですかね，ともあれ乙ですた．
とりあえずわかったことは
・ p2 の httpd を何とかしなければ......
・ NIC のスピードも 100Mbps にしないと......
・ crawld 自体は能力的にはまずまず，か......
71:root▲ ★
06/12/19 22:23:17 0 BE:1824645-PLT(20200)
>>70
SunOSさんもおつでした。
> ・ p2 の httpd を何とかしなければ......
どんなかんじですかね。
- SpeedyCGI => dso
- いずれにしても >>69
> ・ NIC のスピードも 100Mbps にしないと......
これは、依頼するかんじで。
> ・ crawld 自体は能力的にはまずまず，か......
いつもながら、さすがですね。
72:ひろゆき＠どうやら管理人 ★
06/12/20 03:40:13 0 BE:126454-S★(101769)
lighthttpdとspeedyとかだとどうなんすかね。
73: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/20 08:03:09 nx7arcHY0
>>71-72 どうしましょうか......まぁ DSO にすれば軽くなるのは確実だとは思いますが，
柔軟にいじりにくくなるのがマイナスかも？（まぁ最終手段としてはそれしかないでしょうけど）
p2 での問題は......
URLﾘﾝｸ(mumumu.mu)
100 回 / 秒を超えるアクセスがほとんど CGI に対するものだ，ってことですかね．
URLﾘﾝｸ(mumumu.mu)
URLﾘﾝｸ(mumumu.mu)
↑なんかと比べると，アクセス数そのものは普通の 2ch の tiger 鯖への
ものと比べてそんなに多いわけではないようですが，静的ファイル + DSO が
多くを占めるか SpeedyCGI が多くを占めるか，というのが違いのようで．
SpeedyCGI 使用を前提に考えるなら，とりあえず speedy プロセスの fork(), exec() 回数が
ものすごいことになっていて，そのオーバヘッドもかなりのものになってそうな気がするので，
mod_speedycgi というのも1つの選択肢かなぁ（ただし worker MPM だとダメですが）．
ついでに......これ見るとなんか面白いですねｗ
URLﾘﾝｸ(mumumu.mu)
昨晩は 21 時過ぎぐらいにやめたので p2 のトラフィックもそれとほぼ同じぐらいに
沈静化してますが，c2 の方は 10 Mbps の天井に抑え付けられてたために
22 時半ぐらいまで続いていたと......
74:root▲ ★
06/12/20 08:54:31 0 BE:5107878-PLT(20200)
>>72
今回のは CGI の、かつ fork/exec の負荷のようですね。
つまり、
>>73
> 静的ファイル + DSO が
> 多くを占めるか SpeedyCGI が多くを占めるか，というのが違いのようで．
なので、
> mod_speedycgi というのも1つの選択肢かなぁ（ただし worker MPM だとダメですが）．
にするというのは、効果ありかも。
75:root▲ ★
06/12/20 09:04:11 0 BE:1824645-PLT(20200)
# for mod_speedycgi
<IfModule speedycgi_module>
<Files むぎゅ>
SetHandler speedycgi-script
</Files>
</IfModule>
にしてみた。
76:root▲ ★
06/12/20 09:05:37 0 BE:1095326-PLT(20200)
>>75
なんとなく、問題なさげ。
CPU idle time が増えたっぽいかな。
77:root▲ ★
06/12/20 09:14:14 0 BE:1916137-PLT(20200)
あと、10Mbps => 100Mbps の作業中は、
当然サーバ落ちますが、その間 read.cgi の動作に影響ないのかしら。
あるなら、その間は一時的にはずす必要あり?
78: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/20 09:18:44 nx7arcHY0
>>75-76 乙です．
>>77 <iframe> の中身が読めないだけで，read.cgi 出力の表示そのものは可能ですね．
ただ，その <iframe> の読み込みが終わらない状態が続くとウザいと感じる利用者は
いるかも知れませんが......
79:root▲ ★
06/12/20 09:22:07 0 BE:3831067-PLT(20200)
>>78
> <iframe> の中身が読めないだけで，read.cgi 出力の表示そのものは可能ですね．
…であれば、NIC の速度を変えるぐらいの作業なら
そのまま動かしてもとりあえず問題なさげですね。
80:ひろゆき＠どうやら管理人 ★
06/12/20 12:38:09 0 BE:76234-S★(101769)
あいあい
81:root▲ ★
06/12/20 12:55:47 0 BE:1460328-PLT(20200)
>>80
作業依頼を出せと、、、。
そんなわけで、こちらはたんたんと。
82:root▲ ★
06/12/20 14:41:44 0 BE:3284249-PLT(20200)
今、トラフィック的に「フルスペック」なんでしたっけ。
もしそうなら、まずは 10Mbps で動かしてみて、
どうなるのか見てみようかなと。
83: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/20 16:57:39 nx7arcHY0
URLﾘﾝｸ(mumumu.mu)
昨晩は，20:20 頃～21:10 頃に放り込まれた URL を処理するために
22:30 頃まで crawld が働き通しだった模様ですが，時間制限や
鯖名による選別も撤廃した場合，次の日のピーク時間までに
処理し終えるかどうか......まぁ実験としては面白いですがｗ
84: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/20 17:15:28 nx7arcHY0
まぁ，ともあれ mod_speedycgi は今のところかなり効果あるっぽいですね．
昨日の今頃の時間は Load Avg. 軽く二桁超えてましたが，今は1未満ですし＜p2
85: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/20 18:02:00 nx7arcHY0
1日強程度動かしただけで，もう /home 半分近く消費してますね．
まぁ単にテストで動かしてるだけなんで，頃合い見計らってごっそり消してもいいんですが．
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/amrd0s1g 23793186 10653300 11236432 49% /home
86: 株価【1310】 ▲▲▲▲ ◆cZfSunOs.U
06/12/20 20:58:40 nx7arcHY0
昨晩に比べると p2 はかなり余裕っぽいんで，また時間制限と鯖名選別を外してみますた．
外す前 Load Avg. は 1 未満だったのが 2～3 台ぐらいになってますが，昨晩のように
破綻寸前なんてことはなく，十分捌ききれる範囲って感じしますね．
ちなみに c2 の方は 0.1～0.2 前後．トラフィックは急に跳ね上がって，
また 10 Mbps の天井に抑え付けられてるようで．URL をキューイングするため
プロセスサイズは肥大化してきてますね＜crawld 現在 36 MB ぐらいですが，
増加のペースは結構速い...... GB 単位とかになったりしてｗ
87: 株価【1400】 ▲▲▲▲ ◆cZfSunOs.U
06/12/21 07:05:22 2HEgFW4O0
URLﾘﾝｸ(mumumu.mu)
制限撤廃後 450 アクセス / 秒ぐらいまで逝ってますが，
比較的無難にこなしていたようですね＜p2
URLﾘﾝｸ(mumumu.mu)
c2 のトラフィックは意外と早く天井から離れてる......
ずっと動かし続けてれば 304 レスポンスが増えてくるからかな．
crawld のプロセスサイズは 359MB になってますがｗ
とはいえ，今はまだ dso から read.cgi を配布できる鯖の分だけなんですよね．
Apache 2.2 の鯖の分は live22（というか live24b）から配布でいいんですかね？
88:root▲▲ ★
06/12/21 09:18:10 0 BE:1094843-PLT(20202)
>>87
cgi 起動数が多い場合には、
CGIモード→Apacheモジュールモード への変更の効果は絶大みたいですね。
> Apache 2.2 の鯖の分は live22（というか live24b）から配布でいいんですかね？
live24b になります。
既に配布リストは更新しました。
ソースを dso からコピーして、コンパイル・配布すれば OK です。
あ、そか。
雪だるまフロントに例の /i を作らないといけないかも。
89:root▲▲ ★
06/12/21 09:20:31 0 BE:2188883-PLT(20202)
>>88
雪だるまでの read.cgi の配布の前に、
かっこいいおにいさんに確認したほうがいいかもです。
これをやると、雪だるまでもおすすめなんたらが有効になるような気がするので。
90:root▲▲ ★
06/12/21 09:25:14 0 BE:5745997-PLT(20202)
>>87
> c2 のトラフィックは意外と早く天井から離れてる......
> ずっと動かし続けてれば 304 レスポンスが増えてくるからかな．
ふむ、、、。100Mbps にすれば解決できそうですかね。
> crawld のプロセスサイズは 359MB になってますがｗ
trim するようなしくみとかはある(or 入れる予定)のかしら。
91: 株価【1400】 ▲▲▲▲ ◆cZfSunOs.U
06/12/21 15:32:37 2HEgFW4O0
>>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 投げるのをやめさせてるんですが，
URLﾘﾝｸ(mumumu.mu)
波形に多少乱れはあるものの，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
92:ひろゆき＠どうやら管理人 ★
06/12/22 00:18:33 0 BE:265267-S★(101770)
URLs: input = 16004864, done = 9492604, error = 546602
49時間でってことですか？
93: 株価【1400】 ▲▲▲▲ ◆cZfSunOs.U
06/12/22 00:39:24 ClN7ImNE0
>>92 そういうことですね．ただ，10 Mbps の天井に抑え付けられたゆえ
input に done が追い付いてないという可能性が高いので，
NIC 速度が速ければ input と done の差はもっと縮まりそうな気がします．
で，昨日 14 時ぐらいから crawld に URL 投げるのをやめていて，
crawld 内部にため込んだキューの URL を黙々と処理している，つまり
p2 の getf.cgi 呼び出し数と c2 のトラフィックは直接関係ないはずですが
URLﾘﾝｸ(mumumu.mu)
振幅こそ小さいものの c2 のトラフィックは p2 の波形と相似してますね．
これは，やはり >>91 の仮説は合っているということなのかも......
94:ひろゆき＠どうやら管理人 ★
06/12/22 01:36:50 0 BE:265267-S★(101770)
NIC速度っていつ変わるんでしたっけ？
95: 株価【1400】 ▲▲▲▲ ◆cZfSunOs.U
06/12/22 07:46:17 ClN7ImNE0
>>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
----------------------------------------------------------------------
96:root▲▲ ★
06/12/22 08:51:39 0 BE:1641863-PLT(20202)
>>94
>>82 の結果「やはり10MBpsではそこの部分が障害となる」ことがわかったので、
私のほうからメールで、以下のオーダー出しておくです。
1) 10Mbps→100Mbpsへの変更
2) p2.2ch.io ⇔ c2.2ch.io 間のクロスケーブルでの直結
97:root▲▲ ★
06/12/22 08:52:15 0 BE:2736656-PLT(20202)
>>96
× 10MBps
○ 10Mbps
98:root▲▲ ★
06/12/22 18:07:04 0 BE:1368353-PLT(20202)
>>94
・通信速度のアップグレード
・p2.2ch.io と c2.2ch.io の間の直結(2nd I/F 使用)
を、今メールでお願いしました。
次にリブートすると設定が変わるように /etc/rc.conf を設定して、
スイッチの設定変えたらサーバリセットしてかまわない、
と伝えました。。
99:root▲▲ ★
06/12/22 18:13:32 0 BE:2462393-PLT(20202)
>>98
× 次にリブートすると設定が変わるように /etc/rc.conf を設定して、
○ 次にリブートすると設定が変わるように /etc/rc.conf を設定してあるので、
100: 株価【1500】 ▲▲▲▲ ◆cZfSunOs.U
06/12/23 12:22:19 emakIOe90
>>96-99 乙です．
101: 【大吉】 【1387円】 株価【1550】 ▲▲▲▲ ◆cZfSunOs.U
07/01/01 01:13:33 8X3UHVsz0
あけましておめでとうございます．本年もよろしくです．
さて，まだ 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
----------------------------------------------------------------------
102:動け動けウゴウゴ２ちゃんねる
07/01/02 08:54:09 JrHqPAKb0
関連キーワードをおすすめ2ちゃんねるみたいにCGIを叩かずに取得できるようにして欲しい。
スレの話題が分かりやすくて便利なので。
103: 株価【1400】 ▲▲▲▲ ◆cZfSunOs.U
07/01/02 09:35:53 YHi+BSTR0
>>102 read.cgi に直接組み込むってことですか？ そうすると read.cgi 自体が重くなる要因になるような......
# p2.2ch.io が重くなっても read.cgi の表示そのものに影響を与えないように今の形になってるんで......
104:動け動けウゴウゴ２ちゃんねる
07/01/02 09:40:16 37jTXRkI0
htmlかなんかとして外部に出力してくれってことじゃない？
これみたいに
URLﾘﾝｸ(qb5.2ch.net)
105: 株価【1400】 ▲▲▲▲ ◆cZfSunOs.U
07/01/02 09:58:50 YHi+BSTR0
>>104 URLﾘﾝｸ(p2.2ch.io)ｽﾚﾘﾝｸ(operate板) とかじゃダメなんですかね？
それはともかく，表示用キーワード抽出を始める前にあらかじめ約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
106:動け動けウゴウゴ２ちゃんねる
07/01/02 12:28:47 JrHqPAKb0
2chブラウザに関連キーワードを組み込むときに、毎回CGIを叩くのは負荷がかかりそう。
別にいいなら今の仕様でもいいんだけど。
107:動け動けウゴウゴ２ちゃんねる
07/01/02 12:38:25 37jTXRkI0
リンク先がこんな風になってるのは仕様でしょうか。
URLﾘﾝｸ(find.2ch.net)
専ブラで読み込ませたらfindのトップに飛ばされた
108: ◆WMaLhm.gkw
07/01/02 16:38:33 28BxkO6Y0
iframe が height=15 だと 3pix ほど足りなくて下のほうが欠けています（firefox2@win）
height=18 程度に増やすか、文字を小さくしてもらえないでしょうか？
109:ひろゆき＠どうやら管理人 ★
07/01/02 16:45:40 0 BE:158055-S★(101778)
>>106
read.cgiに負荷をかけるよりはマシかと。
110: 株価【1400】 ▲▲▲▲ ◆cZfSunOs.U
07/01/02 17:48:42 YHi+BSTR0
>>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; にしますた．
111:動け動けウゴウゴ２ちゃんねる
07/01/02 19:06:51 JrHqPAKb0
10個全部表示しちゃえばいいのに
112: ◆WMaLhm.gkw
07/01/02 19:38:25 O80tqENz0
>>110
ありがとうございます♪
113: 株価【1400】 ▲▲▲▲ ◆cZfSunOs.U
07/01/02 23:41:52 YHi+BSTR0
いつの間にか，雪だるまや 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 のトラフィックは増えてますね．
URLﾘﾝｸ(mumumu.mu)
114:ひろゆき＠どうやら管理人 ★
07/01/03 22:17:55 0 BE:283695-S★(102231)
10個全部を吐くようにして、
javascript側でランダム表示にしちゃうとか。
115:動け動けウゴウゴ２ちゃんねる
07/01/03 22:24:55 sDOHP3VQ0
そもそも、たかが10個のうち7個をランダムで表示する必要があるのだろうか。
100個あるならともかく。
116:ひろゆき＠どうやら管理人 ★
07/01/03 23:53:05 0 BE:202548-S★(102231)
表示できる文字数の問題だったり。
117:動け動けウゴウゴ２ちゃんねる
07/01/03 23:55:20 Dn3KZWNbO
テスト
118:root▲▲ ★
07/01/04 10:49:20 0 BE:729942-PLT(22223)
今年もよろしくお願いいたします。
まずは、MySQL のインストールからですね。
普通に 5.x を入れればいいのかしら。
何か特別な設定が必要な場合、ここで教えてくださいです。
119:root▲▲ ★
07/01/04 10:51:03 0 BE:4469377-PLT(22223)
で、10Mbps → 100Mbps ですが、
どうも依頼がうまく受け付けられていないようなので、
メールでたんたんと依頼(催促)するということで。
120:ひろゆき＠どうやら管理人 ★
07/01/04 16:07:14 0 BE:63825-S★(102231)
5.xの最新のものをいれてくださいー。
121:root▲▲ ★
07/01/04 16:34:41 0 BE:1094843-PLT(22223)
>>120
了解です。それで。
まずは、mecab-0.93 を入れました。
MySQL は本日帰宅後にでも。
122:ひろゆき＠どうやら管理人 ★
07/01/04 16:40:11 0 BE:340496-S★(102231)
tf-idfを2chDB自体を使ってやるとすると、
sennaは必須になりますね。。と。
123:動け動けウゴウゴ２ちゃんねる
07/01/04 16:46:10 vF0Lqd4Y0
今年ひろゆき創めてみたわ
124:root▲▲ ★
07/01/04 16:49:00 0 BE:1642829-PLT(22223)
>>122
これですか。
Senna 組み込み型全文検索エンジン
URLﾘﾝｸ(qwik.jp)
これ入れればいいのかな。
/usr/ports/textproc/senna
MySQL とともに、入れておくです。
125: 株価【2400】 ▲▲▲▲ ◆cZfSunOs.U
07/01/04 16:59:08 kvBClyTd0
>>114
HTML モード（鯖側でランダム表示・Last-Modified なし）:
URLﾘﾝｸ(p2.2ch.io)ｽﾚﾘﾝｸ(operate板)
JavaScript モード（クライアント側でランダム表示・Last-Modified あり）:
URLﾘﾝｸ(p2.2ch.io)
で，とりあえず 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
126:root▲▲ ★
07/01/04 17:04:31 0 BE:4104959-PLT(22223)
>>125
> MeCab はデフォルトでは EUC-JP を使うのですが，Shift JIS を使うようにビルドして下さい．
おぉ、なるほど。
入れなおしっすね。senna もそうかな。
では、そのように。
127: 株価【2400】 ▲▲▲▲ ◆cZfSunOs.U
07/01/04 17:04:54 kvBClyTd0
* 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 容量が半端ないぐらい必要になるような......
128:ひろゆき＠どうやら管理人 ★
07/01/04 20:23:23 0 BE:38232-S★(102333)
DF 計算用の単語の切り出し方によると思いますが、
母集団を反映してる標本なら、
それでもいいと思いますー。
129: 株価【2400】 ▲▲▲▲ ◆cZfSunOs.U
07/01/04 22:18:59 kvBClyTd0
>>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
130:ひろゆき＠どうやら管理人 ★
07/01/04 22:37:16 0 BE:220875-S★(102334)
んでは、SUNOSさんの方式で試してみましょー。
131: 株価【1350】 ▲▲▲▲ ◆cZfSunOs.U
07/01/06 08:37:21 iqmdoHgZ0
何かゴミデータが混ざってるな，と思ったら...... 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;
132:ひろゆき＠どうやら管理人 ★
07/01/06 17:43:25 0 BE:88272-S★(102338)
DBD::mysqlってよくつかわれてそうなのに。。
133:耐
07/01/06 19:49:16 FcjBKnL90
このやろうなめやがって！！
134: 株価【1400】 ▲▲▲▲ ◆cZfSunOs.U
07/01/07 04:55:44 RElzDEdE0
>>132 DBD::mysql 自体はよく使われてても，server side prepare は
デフォルトでは off なのであまり使われてないのかも......
URLﾘﾝｸ(search.cpan.org)
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.
135:ひろゆき＠どうやら管理人 ★
07/01/08 11:10:08 0 BE:283695-S★(102351)
現状ってあとは何が足りないんでしたっけ？
136:動け動けウゴウゴ２ちゃんねる
07/01/08 22:50:59 EY1iKiNMP
>>135
137:root▲▲ ★
07/01/08 23:12:32 0 BE:5837388-PLT(22223)
>>135
・10Mbps→100Mbps
・>>125-126 の作業
- MySQL
- mecab
- c2 の httpd を減らす
あたりですか。
138:root▲▲ ★
07/01/09 00:25:26 0 BE:3284249-PLT(22223)
で、>>137 は、たんたんとすすめるです。
139:ひろゆき＠どうやら管理人 ★
07/01/09 09:34:40 0 BE:302786-S★(102351)
よろしくですー。
140: 株価【1250】 ▲▲▲▲ ◆cZfSunOs.U
07/01/09 10:49:56 IbJP81C20
>>137 そんなところですね．ということでよろしくおながいします．
で，MySQL を入れるのは最初 p2 がいいかなと思ってたんですが，
現状を鑑みれば c2 の方が良さそうという気がしてます．
p2 で mod_speedycgi を使うということで prefork MPM 利用は確定のようですし，
そうなると p2 に MySQL を入れるとなるとメモリやコンテキストスイッチなどの
競合できつくなりそうですし．c2 でもパーサがフル回転してる時は CPU で競合しますが，
データ収集が一巡してからはパーサも常時フル回転ではなくなってますし（で，2日以上経過した
データから順次再クロールする処理も入れますたが，それも比較的余力を持ってこなしてますし）．
p2 でもピーク時間帯はどっちにしろ CPU 食いますし，c2 ではプロセス数の少なさから
メモリやコンテキストスイッチなどで競合しにくいだろう，ってことで．
141:root▲▲ ★
07/01/09 11:56:02 0 BE:1915373-PLT(22223)
- 10Mbps → 100Mbps
- p2 ⇔ c2 クロスケーブルで直結
について、再度メールで依頼しました。
関係者に Cc:。
142:動け動けウゴウゴ２ちゃんねる
07/01/11 03:08:24 VhKIX1KV0
>>135
スレ同士の自動リンクツールとするならもう少し人為を反映する仕様があったほうがいいような
143:動け動けウゴウゴ２ちゃんねる
07/01/16 03:57:50 kO1prtGV0
今現在までの閉鎖騒動関連スレを幾つか見たけど
「24」を地で行くようなちょろの奮闘が眩しかった。
ひ(ryが2chを、というより、2chがこの男を失うか否かというような。
そんな風に見えなくもない今回の騒動。
144: ◆A/T2/75/82
07/01/17 05:32:41 FZgroHfR0
これiframeでやってるのもったいないなぁ
read.cgi直書きになる予定ってないんすかねぇ
145: 株価【1200】 △ ◆cZfSunOs.U
07/01/17 06:17:39 3etJMdTl0
>>144 read.js では iframe ではなく JavaScript による DOM 操作でやってます．
ただ，古いブラウザだと DOM をちゃんと扱えないかも知れないというところで，
read.cgi でその方式にするのは躊躇してます．
あと，管理人さんからは，2ch 専用でしか使えないものではなく
他のところでも汎用的に使い回しができる形で作ってほしいとも言われてたので，
read.cgi に依存する部分は小さくしておきたい，ということもあります．
146: 株価【1650】 △ ◆cZfSunOs.U
07/01/19 15:22:17 xjyXmKyT0
停電の影響ですかね．httpd がちゃんとあがってなかったようです @p2
[Fri Jan 19 13:05:08 2007] [emerg] (2)No such file or directory: Couldn't initialize cross-process lock in child (/md/accept.lock.634) (5)
c2 の方は MySQL とかパーサとか crawld とか手動であげておきますた．
ついでに，my.cnf で log-bin=mysql-bin はコメントアウト，myisam-recover を追加．
# MyISAM だから，いきなり落ちるってのは何となくやな感じではあるんですよね......
070119 13:46:27 [ERROR] /home/c22chio/mysql/bin/mysqld: Table './keywords/urls' is marked as crashed and should be repaired
070119 13:46:27 [Warning] Checking table: './keywords/urls'
070119 13:47:12 [ERROR] /home/c22chio/mysql/bin/mysqld: Table './keywords/dispwords' is marked as crashed and should be repaired
070119 13:47:12 [Warning] Checking table: './keywords/dispwords'
070119 13:47:28 [ERROR] /home/c22chio/mysql/bin/mysqld: Table './keywords/regwords' is marked as crashed and should be repaired
070119 13:47:28 [Warning] Checking table: './keywords/regwords'
070119 13:48:09 [Warning] Recovering table: './keywords/regwords'
070119 13:55:05 [ERROR] /home/c22chio/mysql/bin/mysqld: Table './keywords/words' is marked as crashed and should be repaired
070119 13:55:05 [Warning] Checking table: './keywords/words'
070119 13:55:13 [Warning] Recovering table: './keywords/words'
070119 13:55:13 [Note] Retrying repair of: './keywords/words' with keycache
070119 13:55:52 [Note] Found 1269663 of 1269666 rows when repairing './keywords/words'
147:root▲▲ ★
07/01/20 23:43:04 0 BE:2736465-PLT(22230)
>>146
上げました。
しかし、c2.2ch.io が落ちている予感。
148:root▲▲ ★
07/01/21 00:30:55 0 BE:6566898-PLT(22230)
>>147
復旧した模様。< c2.2ch.io
原因はカーネルパニック(ffs dup alloc)だったもより。
これ、HDD に強烈にアクセスする場合にごくまれに出るですね。
149: 株価【1399】 △ ◆cZfSunOs.U
07/01/21 02:36:41 LxPu/wXQ0
>>147-148 乙です．停電もアレですが，通常運用中にカーネルパニックってのも，ちょっとコワいですね......
# サイズのデカいテーブルが壊れると，リカバリに時間がかってしょうがないですねぇ......
# regwords はまだ半分ぐらいしか終わってない模様......
#
# -rw-rw---- 1 c22chio ch2 1868775426 1 20 23:40 regwords.MYD
# -rw-rw---- 1 c22chio ch2 973602816 1 21 02:34 regwords.TMD
# -rw-rw---- 1 c22chio ch2 1525427200 1 21 02:34 regwords.MYI
150:ひろゆき＠どうやら管理人 ★
07/01/23 10:44:22 0 BE:252858-S★(102442)
URLﾘﾝｸ(www.videoi.co.jp)
2ch.ioがランク入りしてしまった様子。
151:ひろゆき＠どうやら管理人 ★
07/01/23 10:49:04 0 BE:101344-S★(102442)
テーブルって分割できる構造じゃないんでしたっけ？
152: [´・ω・｀] N076052.ppp.dion.ne.jp
07/01/23 10:58:24 iC7aDD4B0
>>150
21位ですか・・・
平均滞在時間は、かなり上位になりますねぇ・・・
153:動け動けウゴウゴ２ちゃんねる
07/01/23 10:59:16 X6iTzN4i0
p2.2ch.io と c2.2ch.io があるのだが。
やっぱ携帯か。
154:動け動けウゴウゴ２ちゃんねる
07/01/23 11:05:01 X6iTzN4i0
んーmixiがランクインしていないのは何故？
155:ひろゆき＠どうやら管理人 ★
07/01/23 11:45:59 0 BE:76043-S★(102442)
ユニークの数の集計だからじゃないすか。
156:動け動けウゴウゴ２ちゃんねる
07/01/23 13:43:32 X6iTzN4i0
なるほどね。
つーことは、あれか？
mixiができたから２ちゃんねるが廃れるとかって今のところは無いのだな。
157:動け動けウゴウゴ２ちゃんねる
07/01/23 20:49:46 X6iTzN4i0
ひろゆき＞
言ったんだが返事が無いなｧ。
ｽﾚﾘﾝｸ(operate板:933番)
ひょっとして相手にされてないのか？
158:動け動けウゴウゴ２ちゃんねる
07/01/23 20:59:34 nBCpy34EP
うぜえ
159:動け動けウゴウゴ２ちゃんねる
07/01/23 22:31:06 ttLdMJWB0
皆でこのアホを通報しよう。２chの癌。
なら俺は風見しんごの娘を殺す
ｽﾚﾘﾝｸ(news4vip板)l50
863 ：動け動けウゴウゴ２ちゃんねる ：2007/01/22(月) 11:36:52 ID:NF9a2QR+0
おじちゃん、殺人予告って2ch運営にはどこに通報すればいいのかしら?
見た感じいろんなところで予告してるみたいよ?
ｽﾚﾘﾝｸ(operate板:619番)
ｽﾚﾘﾝｸ(newsplus板:914番)
864 ：どくどくさぼてん ：2007/01/22(月) 11:41:12 ID:6SRCrGFv0
警察へどうぞ。
いや、ほんとならほんとに。
■警視庁匿名通報フォーム（通報は2chのように書き込むだけ）
URLﾘﾝｸ(ime.nu)
■全国ハイテク警察リンク集 URLﾘﾝｸ(ime.nu)
■警視庁ホームページ URLﾘﾝｸ(www.keishicho.metro.tokyo.jp)
160:動け動けウゴウゴ２ちゃんねる
07/01/23 22:32:03 ALRfqIPI0
そのままコピペかよｗ
161: 株価【1203】 △ ◆cZfSunOs.U
07/01/23 23:37:31 NNoT+9df0
>>150 なるほど......まぁ read.cgi 画面に組み込まれて表示されますからね．
# 今 2ch.io で本格的にやってるサービスは，この関連キーワードぐらいなのかな......？
>>151 MERGE テーブルですね．有用性はあるようなので，ぼちぼち考えますか
（あるいは MyISAM から InnoDB に変えるかどうか，ってのも思案のしどころですが）．
# もっとも，停電で落ちるってのがそもそも起こるべきでないことではありますが......
>>153 c2 ってのは携帯ではないですよ．あくまで裏方の処理をする鯖で，
一般閲覧者が直接アクセスする鯖ではないです．というか，read.cgi を
直接見られるフルブラウザ搭載の携帯って，まだ一部じゃないのかな......
162:root▲▲ ★
07/01/23 23:40:53 0 BE:1460328-PLT(23456)
>>161
きっと c.2ch.net や p2.2ch.net のイメージがあるので、
p2 とか c2 というホスト名だと、携帯関連だと思うんじゃないかなと。
2ch.ioのpとcは、パーサのpとクローラのcだったりする(命名は管理人)。
163: 株価【1203】 △ ◆cZfSunOs.U
07/01/23 23:55:48 NNoT+9df0
>>162
>2ch.ioのpとcは、パーサのpとクローラのcだったりする(命名は管理人)。
そうだったんですかぁ......しかし，現状では
p2: フロントエンド (getf.cgi)
c2: クローラ (crawld), パーサ (parsed.pl), MySQL
なので，c2 は pc2 にした方が「名は体を表す」ですねｗ
# p2 は 'p' が取れて，どうなるんだろ......
164:動け動けウゴウゴ２ちゃんねる
07/01/24 00:20:29 gqpPG0ef0
>>162
むむむの部屋では２ちゃんねる画像掲示板になってるよ。＜up01.2ch.io
この鯖は>>161なのね。
165:root▲▲ ★
07/01/24 00:22:29 0 BE:7387799-PLT(23456)
>>164
あ、up01 ってもうないかも。
更新jしておきます。
166:root▲▲ ★
07/01/24 00:23:30 0 BE:2919348-PLT(23456)
既に削除済みだった。 < up01.2ch.io
# おかしいと思った、、、。
167:動け動けウゴウゴ２ちゃんねる
07/01/24 00:40:10 gqpPG0ef0
ん？よく判らないけどこうなってる。
URLﾘﾝｸ(sv2ch.baila6.jp)
168:動け動けウゴウゴ２ちゃんねる
07/01/24 00:51:14 NH5IBiiS0
・・・・・
169:ひろゆき＠どうやら管理人 ★
07/01/24 18:06:10 0 BE:341069-S★(102442)
たとえば、1日ごとにテーブルを作るようにして、
selectするときは、2週間分をMERGEとかにすると、
鮮度の高いものだけをとれるのと、
検索対象がリニアに大きくなるのは防げるかと。
古いのはdrop tableとかで捨てちゃうとかで。
170:動け動けウゴウゴ２ちゃんねる
07/01/24 19:04:22 gqpPG0ef0
>>169
んーそれってコスト高くない？
171:動け動けウゴウゴ２ちゃんねる
07/01/24 19:48:55 /pXKQOLR0
専ブラ使ってると関係ない感じがひしひしとします
172:ひろゆき＠どうやら管理人 ★
07/01/25 11:33:17 0 BE:252858-S★(102442)
>>170
mergeしようがしまいが、データ量がメモリ内に収まるのであれば、
オンメモリなので、コストはそんなに変わらないです。
データが肥大化してオンメモリで処理できなくなったときに、
ボトルネックが発生するので、
肥大化しないようにするほうがいいと思うのですよ。
173:http:// 244.111.215.220.ap.yournet.ne.jp.2ch.net/
07/01/25 11:50:19 oxnNK9gY0
guest guest
174:動け動けウゴウゴ２ちゃんねる
07/01/25 12:52:45 lJVO0eQF0
2chの未来占いではこんな感じで出てるけど
URLﾘﾝｸ(aglgag.livedoor.biz)
黒幕さんの生年月日も分かればリクエストしたいざんす
175: 株価【1300】 △ ◆cZfSunOs.U
07/01/25 13:16:34 5LW/yCI10
>>169 えとですね，regwords テーブルは登録時のみに使用するもので，getf.cgi での
表示時には使用しません．それ以外の3つのテーブルはそんなに大きくないです．
あと，今は2日以上前の登録データを再クロールするようにしてますが，
dat 落ちしたのは消されるようになってます．なので，古いデータがいつまでも
残るってことは基本的にないかと（流れの遅いスレのデータは残るでしょうけど）．
実際，20日以上前の >>129 と比べても，若干大きくなってるものの膨張一直線って感じではないですし．
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 との関連付け総数 |
+----------+----------+--------------------------------------+-----------------------------------+
| 527930 | 1341210 | 82159070 | 5090686 |
+----------+----------+--------------------------------------+-----------------------------------+
-rw-rw---- 1 c22chio ch2 137734175 1 25 13:13 dispwords.MYD
-rw-rw---- 1 c22chio ch2 103124992 1 25 13:13 dispwords.MYI
-rw-rw---- 1 c22chio ch2 8632 1 20 23:13 dispwords.frm
-rw-rw---- 1 c22chio ch2 1873328877 1 25 13:13 regwords.MYD
-rw-rw---- 1 c22chio ch2 1572448256 1 25 13:13 regwords.MYI
-rw-rw---- 1 c22chio ch2 8626 1 20 23:20 regwords.frm
-rw-rw---- 1 c22chio ch2 41549264 1 25 13:13 urls.MYD
-rw-rw---- 1 c22chio ch2 23207936 1 25 13:13 urls.MYI
-rw-rw---- 1 c22chio ch2 8694 1 20 23:13 urls.frm
-rw-rw---- 1 c22chio ch2 41199816 1 25 13:13 words.MYD
-rw-rw---- 1 c22chio ch2 51624960 1 25 13:13 words.MYI
-rw-rw---- 1 c22chio ch2 8612 1 20 23:13 words.frm
ピーク時間帯で引っかかり感を感じることがあるのは，個人的には
登録処理時にテーブルロックで待たされるのが原因じゃないかと見てます．
URLﾘﾝｸ(mumumu.mu)
のグラフで，c2 のひろゆきさんのヒゲみたいｗなのは再クロール処理によるものですが，
ピーク時間帯では c2 のヒゲと p2 のへこみが連動してるのもそのためではないかと．
InnoDB にすればテーブルロックはなくなる（しかもトランザクションログを使うので
鯖落ち後のリカバリに長時間かかることもなくなるでしょうし），その代わり
全般的に処理は重くなりそう，それで結果的にプラスになるかマイナスになるかは
予測がつかないので，思案のしどころということで......
# まぁ，それ以前にピーク時間帯は再クロールを停止すればいいのかもですがｗ
176: 株価【1300】 △ ◆cZfSunOs.U
07/01/25 14:50:52 5LW/yCI10
ちなみに，getf.cgi でやってるクエリーはこんな感じですが，
特段のネックはないのではないかと......
mysql> EXPLAIN EXTENDED SELECT words.word, UNIX_TIMESTAMP(urls.mtime) FROM urls, dispwords, words WHERE urls.url = 'URLﾘﾝｸ(qb5.2ch.net)' AND dispwords.url_id = urls.id AND words.id = dispwords.word_id;
+----+-------------+-----------+--------+---------------+---------+---------+----------------------------+------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------+--------+---------------+---------+---------+----------------------------+------+-------+
| 1 | SIMPLE | urls | const | PRIMARY,id | PRIMARY | 514 | const | 1 | |
| 1 | SIMPLE | dispwords | ref | url_id | url_id | 8 | const | 17 | |
| 1 | SIMPLE | words | eq_ref | PRIMARY | PRIMARY | 8 | keywords.dispwords.word_id | 1 | |
+----+-------------+-----------+--------+---------------+---------+---------+----------------------------+------+-------+
3 rows in set, 1 warning (0.01 sec)
177:ひろゆき＠どうやら管理人 ★
07/01/25 17:51:53 0 BE:302786-S★(102442)
時代はInnoDBっすよ。
sennaを使うとかでなければ、
myIsamにするメリットってあんまりない気がします。
178: 株価【1300】 △ ◆cZfSunOs.U
07/01/25 18:28:22 5LW/yCI10
>>177 なるほど......やはり機能的にはそうなんですよね．
ただ，MyISAM vs InnoDB のベンチマーク結果の載ってるサイトとか見て回ってると，
パフォーマンス面で一抹の不安があったり......まぁベンチはいろんな条件次第で
結果は変わってくるんで，どっちに転ぶかは実際やってみないとわからないんですけどね．
179:ひろゆき＠どうやら管理人 ★
07/01/25 18:59:41 0 BE:221257-S★(102442)
実際に試してみるほうが早いかもですね。
180: 株価【1300】 △ ◆cZfSunOs.U
07/01/25 19:15:59 5LW/yCI10
>>179 まぁそうですね．やるとすると
1. テーブルの MyISAM -> InnoDB 変換．
2. MyISAM では COUNT(*) が高速ということに依存してる部分があるので，
レコード数を保持するテーブルを新設して COUNT(*) をなくす．
3. 登録時に START TRANSACTION ～ COMMIT を使う
（2. と併せ登録用ストアドプロシージャを変更）．
4. my.cnf に InnoDB 用の設定を入れる．
ってのをやることになりますが，特に 1. とかやると時間がかかりそうなんで，
今夜のピーク時間帯以降にぼちぼちって感じで......
181:ひろゆき＠どうやら管理人 ★
07/01/25 20:08:23 0 BE:89227-S★(102442)
＞3. 登録時に START TRANSACTION ～ COMMIT を使う
使わないほうが早くないすか？
182: 株価【1300】 △ ◆cZfSunOs.U
07/01/25 20:25:26 5LW/yCI10
>>181 いや......現状の登録用ストアドプロシージャは↓のようなものですが，
START TRANSACTION を使わない場合の implicit commit は各 INSERT / UPDATE /
DELETE ごとに行われるので何回も commit することになってしまうのに対し，
全体を START TRANSACTION ～ COMMIT で囲めば commit は１回だけなので．
もちろん，データの一貫性保持の観点からも START TRANSACTION を入れた方がいいですけど．
CREATE PROCEDURE registurl(urlx varchar(256), mtimex int, totalwordsx int unsigned)
BEGIN
DECLARE urlid, totaldocs bigint unsigned;
SELECT id INTO urlid FROM urls WHERE url = urlx;
IF urlid IS NOT NULL THEN
UPDATE regwords, words SET words.df = words.df - 1 WHERE regwords.url_id = urlid AND words.id = regwords.word_id;
DELETE FROM dispwords WHERE url_id = urlid;
DELETE FROM regwords WHERE url_id = urlid;
END IF;
IF totalwordsx IS NULL THEN
DELETE FROM urls WHERE id = urlid;
ELSE
INSERT urls (url, mtime, totalwords) VALUES (urlx, FROM_UNIXTIME(mtimex), totalwordsx)
ON DUPLICATE KEY UPDATE mtime = VALUES(mtime), totalwords = VALUES(totalwords);
IF urlid IS NULL THEN
SET urlid = LAST_INSERT_ID();
END IF;
INSERT words (word) SELECT word FROM tmpwords ON DUPLICATE KEY UPDATE df = words.df + 1;
UPDATE tmpwords JOIN words USING (word) SET tmpwords.id = words.id, tmpwords.df = words.df;
INSERT regwords SELECT urlid, id, tf FROM tmpwords;
SELECT COUNT(*) INTO totaldocs FROM urls;
INSERT dispwords SELECT urlid, id, tf / totalwordsx * (LN(totaldocs / df) + 1) tfidf
FROM tmpwords WHERE totaldocs / df < 100000 ORDER BY tfidf DESC LIMIT 10;
TRUNCATE tmpwords;
END IF;
END
183:ひろゆき＠どうやら管理人 ★
07/01/25 21:19:00 0 BE:302786-S★(102442)
おぉ、、ストアードプロシージャーをすでに使ってるんですかぁ。
ラジャーです。
184:ﾉtasukeruyo
07/01/25 22:12:16 K8P4JlkZ0 BE:11397964-2BP(115)
Operaだと関連キーワードやofuda.ccのあれととスレの一番上の全部や掲示板に戻るが重なって
掲示板に戻るがクリックできない。
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; ja) Opera 9.02
185:動け動けウゴウゴ２ちゃんねる
07/01/26 00:26:59 CxnnXu9Q0
これって、全部、普通のブラウザからの機能ですよね
２ｃｈ専用ブラウザにデータを渡して貰えば、クライアントで処理できるんじゃないの？
話題がそれていたらご免なさい 専用ブラウザ使っているから、見ること無いでね
186:ひろゆき＠どうやら管理人 ★
07/01/26 04:05:53 0 BE:252858-S★(102442)
getf.cgiの使い方を説明すればいいんですかね？
URLﾘﾝｸ(p2.2ch.io)ｽﾚﾘﾝｸ(operate板)
187:動け動けウゴウゴ２ちゃんねる
07/01/26 04:07:25 xv4yZrZ10
XHTMLは扱いづらい
188:動け動けウゴウゴ２ちゃんねる
07/01/26 04:49:18 XaZ1ZGLD0
あ
189:動け動けウゴウゴ２ちゃんねる
07/01/26 07:15:29 G006ntY00
>>185
まー確かに一理あるな。＜２ｃｈブラから情報収集
技術的に可能かどうかより、ひろゆきが望むかどうかなんだが。
190:動け動けウゴウゴ２ちゃんねる
07/01/26 11:07:05 hJoWPiym0
>>189
望むも何も、>>186が答えだろ。
少なくても今の段階では、外部からも自由に使ってみて良いんだと思う。
駄目ならその内アクセス制限掛けるだろうし。
専ブラ側でget.cgiをコールすればキーワードが返ってくるから、
後は専ブラ側でどうぞと。
つう訳で人柱になる専ブラ無いかな。
191:動け動けウゴウゴ２ちゃんねる
07/01/26 12:21:58 G006ntY00
>>190
Jane派生といくつかの2chブラから閲覧はできる。
見るだけならその通り。
2chブラウザからのアクセス統計も集めるかどうかですよ。
192:ひろゆき＠どうやら管理人 ★
07/01/26 12:22:59 0 BE:151283-S★(102442)
専ブラ開発系のスレッドで告知すればいいんですかね？
193:外野ｧｧﾝ
07/01/26 12:25:28 UA1Fteu60
そこでメールマガジンですよ
194:動け動けウゴウゴ２ちゃんねる
07/01/26 12:27:48 G006ntY00
>>192
うーん数多いから面倒だろ
ここで公示すればどうよ。
195:こんなんで良い？
07/01/26 12:46:09 G006ntY00
ひろゆきが2chブラウザから関連キーワードを閲覧できるようにしてちょうだいって言ってる。
ｽﾚﾘﾝｸ(operate板:186番)
186 名前：ひろゆき＠どうやら管理人 ★[] 投稿日：2007/01/26(金) 04:05:53 ID:???0 ?S★(102442)
getf.cgiの使い方を説明すればいいんですかね？
URLﾘﾝｸ(p2.2ch.io)ｽﾚﾘﾝｸ(operate板)
閲覧可能にしてほしいって言ってるだけで、2chブラからの集計はしてないですよ。
196:こんなんで良い？
07/01/26 12:50:06 G006ntY00
>>195の底はおすすめ２ちゃんねるとゴッチャになってた。ｽﾏｿ。
197:動け動けウゴウゴ２ちゃんねる
07/01/26 15:05:09 CxnnXu9Q0
一種の検索ソフトだから、それなりにあるんじゃない？
ググルとか、ヤッホーとか、ＭＳとか やってるからね
専ブラで、負荷分散すればそれなりのが出来るかもしれないけど
上記とぶつかると思うよ
198: 株価【1100】 △ ◆cZfSunOs.U
07/01/26 15:05:12 nob1pVtF0
さて，>>180 をやろうかな......ってことで，しばらく止まります．
>>184 下線付近のごく狭い領域ならクリックできたりしませんか？
199:動け動けウゴウゴ２ちゃんねる
07/01/26 15:09:50 yN4KQ28M0
>>198
出来たり出来なかったりです。
フォーカスがあってもカーソルの形も変わりませんし。
200:動け動けウゴウゴ２ちゃんねる
07/01/26 15:58:14 CxnnXu9Q0
関連キーワードを取得しますか？しませんか？
関連キーワードログを保存しますか？しませんか？
関連キーワード登録しますか？しませんか？
関連キーワードデータをアップロードしますか？しませんか？
パケット課金ユーザーには、無縁の話しかも知れません
あっても良いなの機能ですが
201:動け動けウゴウゴ２ちゃんねる
07/01/26 16:00:03 yN4KQ28M0
まずどういうものか理解しよう。
202: 株価【1100】 △ ◆cZfSunOs.U
07/01/26 16:03:16 nob1pVtF0
innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 20M
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
innodb_file_per_table
InnoDB 用に↑の設定を入れて立ち上げようとしたら......
070126 15:50:04 [ERROR] Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space
mysqld got signal 11;
だそうです......たぶん ulimit の制限に引っかかってるんじゃないかと．
% limit -h datasize
datasize 524288 kbytes
ってことで，これをもっとデカく（物理メモリ上限くらいまで）設定できるようにお願いできればと＞むむむさん
>>199 う～む......そのあたりのは float 使ってるので，それの関係ですかね......
203:動け動けウゴウゴ２ちゃんねる
07/01/26 16:06:55 yN4KQ28M0
>>202
掲示板に戻る、全部等を囲っているspanを消したらクリックできるようになりますから多分そうでしょう。
204:root▲▲ ★
07/01/26 16:58:08 0 BE:2918584-PLT(23456)
>>202
> % limit -h datasize
> datasize 524288 kbytes
FreeBSD/i386 って、これ、増やせるんでしたっけ、、、。
205:root▲▲ ★
07/01/26 17:29:26 0 BE:2188883-PLT(23456)
ちなみに FreeBSD 6.2R/amd64 だと、
datasize 33554432 kbytes
になっているです。
206:root▲▲ ★
07/01/26 17:35:00 0 BE:2189838-PLT(23456)
/usr/src/sys/i386/include/vmparam.h で、
#ifndef MAXDSIZ
#define MAXDSIZ (512UL*1024*1024) /* max data size */
#endif
ってやってて、
/usr/src/sys/kern/subr_param.c で、
maxdsiz = MAXDSIZ;
TUNABLE_ULONG_FETCH("kern.maxdsiz", &maxdsiz);
となっているのか。
207:root▲▲ ★
07/01/26 17:38:58 0 BE:2919348-PLT(23456)
TUNABLE_ULONG_FETCH ってことは、/boot/loader.conf に書いて再起動か。
とりあえず、
kern.maxdsiz="2048m"
とかですかね。
208:root▲▲ ★
07/01/26 17:45:30 0 BE:3192757-PLT(23456)
# Increase maximum data and stack size
kern.maxdsiz="2048m"
kern.maxssiz="1024m"
を /boot/loader.conf に追加して、p2.2ch.io / c2.2ch.io をリブートした。
このように出力されたです。
%limit
cputime unlimited
filesize unlimited
datasize 2097152 kbytes
stacksize 1048576 kbytes
coredumpsize unlimited
memoryuse unlimited
vmemoryuse unlimited
descriptors 65536
memorylocked unlimited
maxproc 7390
sbsize unlimited
209: 株価【1100】 △ ◆cZfSunOs.U
07/01/26 18:00:28 qjITJywp0
>>204-208 乙です．kern.maxdsiz とかは元々なくって，自分で新たに定義するものなんですね．
# どおりで，sysctl -a の出力からそれらしきものを探してもなかったわけだ......
210: 株価【1100】 △ ◆cZfSunOs.U
07/01/26 18:17:21 qjITJywp0
default-storage-engine = InnoDB
>>202 に加え，↑の設定も入れますた．で，MySQL は無事立ち上がり，
現在 MyISAM -> InnoDB にテーブル変換中......
211: 株価【1100】 △ ◆cZfSunOs.U
07/01/26 18:26:52 qjITJywp0
regwords の変換にはどれだけかかるだろう......まぁ最低でも1時間以上はかかるでしょうね......
mysql> alter table dispwords engine InnoDB; alter table urls engine InnoDB; alter table words engine InnoDB; alter table regwords engine InnoDB;
Query OK, 4841616 rows affected (4 min 10.97 sec)
Records: 4841616 Duplicates: 0 Warnings: 0
Query OK, 500065 rows affected (1 min 3.42 sec)
Records: 500065 Duplicates: 0 Warnings: 0
Query OK, 1351479 rows affected (1 min 29.03 sec)
Records: 1351479 Duplicates: 0 Warnings: 0
212:動け動けウゴウゴ２ちゃんねる
07/01/26 19:20:31 Zma3Ljln0
>>186>>190
Janeなら外部コマンドで見れるから
閲覧なら新しく機能つけなくてもいいかと
213:動け動けウゴウゴ２ちゃんねる
07/01/26 22:37:44 txiJMxDB0
それってWebブラウザにURL渡すだけでしょ？
214:動け動けウゴウゴ２ちゃんねる
07/01/26 22:40:22 yN4KQ28M0
$VIEW URLﾘﾝｸ(p2.2ch.io)
とか
$CHOTTO URLﾘﾝｸ(p2.2ch.io)
とか。
215:動け動けウゴウゴ２ちゃんねる
07/01/26 23:02:10 CxnnXu9Q0
jane 使ってみた コマンドを書くの？
タイトルの前に３つ出すの書ける？
216:動け動けウゴウゴ２ちゃんねる
07/01/26 23:19:17 yN4KQ28M0
タイトルの前に３つ出すのってなに？
217: 株価【1100】 △ ◆cZfSunOs.U
07/01/26 23:22:57 qjITJywp0
未だ regwords の変換処理は続いてるわけですが......ただ，それ以外のテーブルの
変換はすでに終わってるので，getf.cgi での表示だけは可能な状態で動いてます．
で，現状ではその変換処理 + getf.cgi からの SELECT クエリー on InnoDB を
平行して捌いてますが，ピーク時間帯になっても c2 は一応無事な状態のようですね．
getf.cgi の表示での引っかかり感もあまりなさそうな感じですし．
あとは，データの登録・更新処理を動かし始めた場合にどうなるか......
last pid: 1646; load averages: 0.62, 0.78, 0.86 up 0+05:36:46 23:20:27
120 processes: 8 running, 112 sleeping
CPU states: 17.8% user, 0.0% nice, 3.3% system, 0.8% interrupt, 78.1% idle
Mem: 420M Active, 1327M Inact, 177M Wired, 75M Cache, 112M Buf, 2996K Free
Swap: 2048M Total, 16K Used, 2048M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
960 c22chio 42 4 0 599M 379M sbwait 0 263:51 51.76% mysqld
218:ひろゆき＠どうやら管理人 ★
07/01/26 23:52:45 0 BE:63252-S★(102442)
InnoDB！InnoDB！
219:動け動けウゴウゴ２ちゃんねる
07/01/27 00:06:44 CxnnXu9Q0
スレ立て人のＣＰＵ借りて結果だけ貰えば？
220:動け動けウゴウゴ２ちゃんねる
07/01/27 13:39:15 gCzMPoiD0 BE:211349344-BRZ(5100)
>>218
>>218
221: 株価【1150】 △ ◆cZfSunOs.U
07/01/27 19:09:39 vVc+ALlX0
Query OK, 78899550 rows affected (5 hours 57 min 6.25 sec)
regwords の変換は↑ということで約6時間かかったと．やはり MyISAM よりはディスク容量食いますね．
-rw-rw---- 1 c22chio ch2 8554 1 27 04:34 count_urls.frm
-rw-rw---- 1 c22chio ch2 98304 1 27 19:06 count_urls.ibd
-rw-rw---- 1 c22chio ch2 8632 1 26 18:10 dispwords.frm
-rw-rw---- 1 c22chio ch2 482344960 1 27 19:07 dispwords.ibd
-rw-rw---- 1 c22chio ch2 8626 1 26 18:17 regwords.frm
-rw-rw---- 1 c22chio ch2 7163871232 1 27 19:07 regwords.ibd
-rw-rw---- 1 c22chio ch2 8694 1 26 18:14 urls.frm
-rw-rw---- 1 c22chio ch2 142606336 1 27 19:07 urls.ibd
-rw-rw---- 1 c22chio ch2 8612 1 26 18:15 words.frm
-rw-rw---- 1 c22chio ch2 146800640 1 27 19:07 words.ibd
んで，登録・再クロール処理も動かし始めますた．今のところ，拍子抜けするぐらい静かな感じですねｗ
last pid: 4972; load averages: 0.66, 0.53, 0.50 up 1+01:24:01 19:07:42
124 processes: 1 running, 123 sleeping
CPU states: 3.8% user, 0.0% nice, 3.6% system, 1.4% interrupt, 91.2% idle
Mem: 512M Active, 931M Inact, 223M Wired, 82M Cache, 112M Buf, 255M Free
Swap: 2048M Total, 20K Used, 2048M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
4821 c22chio 1 4 0 14876K 10680K sbwait 3 1:55 6.98% perl5.8.8
960 c22chio 39 -4 0 604M 383M ufs 0 435:51 5.91% mysqld
4820 c22chio 1 4 0 14236K 10028K sbwait 1 2:03 5.71% perl5.8.8
2772 c22chio 1 4 0 5964K 4700K kqread 0 2:06 1.95% crawld
4822 c22chio 1 4 0 14432K 10280K sbwait 0 1:39 1.17% perl5.8.8
4818 c22chio 1 4 0 14476K 10284K sbwait 2 1:49 0.24% perl5.8.8
222: 株価【1150】 △ ◆cZfSunOs.U
07/01/27 19:11:47 vVc+ALlX0
ただ，InnoDB はロックの粒度が細かいのはいいんですが，注意しないとデッドロックが
発生してしまうという......そのため，登録処理は単純に START TRANSACTION ～ COMMIT で
挟むだけじゃダメですね．words テーブルの書き込みは AUTO-INC のロックと行ロックが交錯するし，
行ロックのかかる順番もまちまちなんで，GET_LOCK() ～ RELEASE_LOCK() で挟んでデッドロック回避．
この GET_LOCK() はテーブルロックとは違うものなので，SELECT での読み出しには影響しません．
CREATE PROCEDURE registurl(urlx varchar(256), mtimex int, totalwordsx int unsigned)
BEGIN
DECLARE urlid, totaldocs bigint unsigned;
START TRANSACTION;
SELECT id INTO urlid FROM urls WHERE url = urlx FOR UPDATE;
IF urlid IS NOT NULL THEN
IF GET_LOCK('keywords.words', 10) THEN
UPDATE regwords, words SET words.df = words.df - 1 WHERE regwords.url_id = urlid AND words.id = regwords.word_id;
DO RELEASE_LOCK('keywords.words');
DELETE FROM dispwords WHERE url_id = urlid;
DELETE FROM regwords WHERE url_id = urlid;
ELSE
ROLLBACK;
TRUNCATE tmpwords;
SET urlid = NULL, totalwordsx = NULL;
START TRANSACTION;
END IF;
END IF;
IF totalwordsx IS NULL THEN
DELETE FROM urls WHERE id = urlid;
UPDATE count_urls SET n = n - 1 WHERE urlid IS NOT NULL;
COMMIT;
ELSE
DO LAST_INSERT_ID(0);
INSERT urls (url, mtime, totalwords) VALUES (urlx, FROM_UNIXTIME(mtimex), totalwordsx)
ON DUPLICATE KEY UPDATE mtime = VALUES(mtime), totalwords = VALUES(totalwords);
IF urlid IS NULL THEN
SET urlid = LAST_INSERT_ID();
UPDATE count_urls SET n = n + 1 WHERE urlid;
END IF;
IF urlid && GET_LOCK('keywords.words', 10) THEN
INSERT words (word) SELECT word FROM tmpwords ON DUPLICATE KEY UPDATE df = words.df + 1;
DO RELEASE_LOCK('keywords.words');
UPDATE tmpwords JOIN words USING (word) SET tmpwords.id = words.id, tmpwords.df = words.df;
INSERT regwords SELECT urlid, id, tf FROM tmpwords;
SELECT n INTO totaldocs FROM count_urls;
INSERT dispwords SELECT urlid, id, tf / totalwordsx * (LN(totaldocs / df) + 1) tfidf
FROM tmpwords WHERE totaldocs / df < 100000 ORDER BY tfidf DESC LIMIT 10;
COMMIT;
ELSE
ROLLBACK;
END IF;
TRUNCATE tmpwords;
END IF;
END
223:動け動けウゴウゴ２ちゃんねる
07/01/27 22:15:46 FzgyxveM0
思い出した 昔、あったな、社会とかのボタン 無くなったんだよな確か？
記憶力弱いんで違ってたらスマソ
３回目か ホリエモンの１クリック程度の価値有ったのだろうか？
意外と進歩してないモンだな
辞書をロカールに於いて、集めてきて賢くするだったかな？
英和、和英何てのも有った 思い出すことは出来ないだろうが
224: 株価【1150】 △ ◆cZfSunOs.U
07/01/27 22:22:23 vVc+ALlX0
>>222 のでもまだデッドロックが起きて...... >>221 の top の表示で余裕に見えたのは，
新規データは登録されるものの，再クロールでの更新データはデッドロックのため
ほとんど登録されず CPU が休んでいたための模様ｗ GET_LOCK() でのロック範囲を広げて
CREATE PROCEDURE registurl(urlx varchar(256), mtimex int, totalwordsx int unsigned)
BEGIN
DECLARE urlid, totaldocs bigint unsigned;
START TRANSACTION;
IF GET_LOCK('keywords.registurl', 10) THEN
SELECT id INTO urlid FROM urls WHERE url = urlx FOR UPDATE;
IF urlid IS NOT NULL THEN
UPDATE regwords, words SET words.df = words.df - 1 WHERE regwords.url_id = urlid AND words.id = regwords.word_id;
DELETE FROM dispwords WHERE url_id = urlid;
DELETE FROM regwords WHERE url_id = urlid;
END IF;
IF totalwordsx IS NULL THEN
UPDATE count_urls SET n = n - 1 WHERE urlid IS NOT NULL;
DO RELEASE_LOCK('keywords.registurl');
DELETE FROM urls WHERE id = urlid;
COMMIT;
ELSE
INSERT urls (url, mtime, totalwords) VALUES (urlx, FROM_UNIXTIME(mtimex), totalwordsx)
ON DUPLICATE KEY UPDATE mtime = VALUES(mtime), totalwords = VALUES(totalwords);
IF urlid IS NULL THEN
SET urlid = LAST_INSERT_ID();
UPDATE count_urls SET n = n + 1;
END IF;
INSERT words (word) SELECT word FROM tmpwords ON DUPLICATE KEY UPDATE df = words.df + 1;
UPDATE tmpwords JOIN words USING (word) SET tmpwords.id = words.id, tmpwords.df = words.df;
DO RELEASE_LOCK('keywords.registurl');
INSERT regwords SELECT urlid, id, tf FROM tmpwords;
SELECT n INTO totaldocs FROM count_urls;
INSERT dispwords SELECT urlid, id, tf / totalwordsx * (LN(totaldocs / df) + 1) tfidf
FROM tmpwords WHERE totaldocs / df < 100000 ORDER BY tfidf DESC LIMIT 10;
COMMIT;
TRUNCATE tmpwords;
END IF;
ELSE
ROLLBACK;
TRUNCATE tmpwords;
END IF;
END;;
にしたら，CPU も働き出した．
225: 株価【1150】 △ ◆cZfSunOs.U
07/01/27 22:24:45 vVc+ALlX0
last pid: 5512; load averages: 3.86, 3.52, 3.20 up 1+04:39:59 22:23:40
132 processes: 5 running, 126 sleeping, 1 stopped
CPU states: 53.0% user, 0.0% nice, 9.6% system, 1.4% interrupt, 36.0% idle
Mem: 615M Active, 920M Inact, 220M Wired, 55M Cache, 112M Buf, 193M Free
Swap: 2048M Total, 20K Used, 2048M Free
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
4820 c22chio 1 121 0 99M 69144K CPU1 1 26:51 63.43% perl5.8.8
4821 c22chio 1 118 0 98M 58500K RUN 0 29:36 59.57% perl5.8.8
4822 c22chio 1 101 0 99M 52608K CPU3 0 29:25 33.35% perl5.8.8
4818 c22chio 1 107 0 99M 48412K CPU2 2 28:46 32.47% perl5.8.8
960 c22chio 46 4 0 603M 383M sbwait 2 494:59 19.97% mysqld
2772 c22chio 1 -8 0 5716K 4440K biord 0 16:46 9.28% crawld
んで，この状態でも getf.cgi 表示の引っかかり感もあまりないようなので，
とりあえず InnoDB への切り替えはプラス側に転んだ，ということでいいのかな．
226:root▲▲ ★
07/01/28 00:06:46 0 BE:1094562-PLT(23456)
おつでした。
しかし InnoDB の本来の力を発揮させるには、
プログラミング上の注意も必要、ということですか。