関連キーワードをなんとかしようスレ
■ このスレッドは過去ログ倉庫に格納されています
read.cgiの片隅に表示されている関連キーワードを きちんとメンテナンスしてみようなスレッド。 >>94 ・通信速度のアップグレード ・p2.2ch.io と c2.2ch.io の間の直結(2nd I/F 使用) を、今メールでお願いしました。 次にリブートすると設定が変わるように /etc/rc.conf を設定して、 スイッチの設定変えたらサーバリセットしてかまわない、 と伝えました。。 >>98 × 次にリブートすると設定が変わるように /etc/rc.conf を設定して、 ○ 次にリブートすると設定が変わるように /etc/rc.conf を設定してあるので、 あけましておめでとうございます.本年もよろしくです. さて,まだ 10Mbps のままなんですが,とりあえず試運転ってことでパーサも含め動かし始めてます. # MeCab / MySQL は,とりあえずホームディレクトリに突っ込んでます. しかし,予想通りパーサ,特に MeCab での単語切り分け処理が重いようですね. ---------------------------------------------------------------------- last pid: 80257; load averages: 3.70, 3.92, 3.83 up 28+04:11:24 01:06:25 1375 processes:18 running, 1356 sleeping, 1 lock CPU states: 77.7% user, 0.0% nice, 7.5% system, 1.5% interrupt, 13.3% idle Mem: 666M Active, 916M Inact, 312M Wired, 105M Cache, 112M Buf, 4216K Free Swap: 2048M Total, 132K Used, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 80076 c22chio 1 123 0 78644K 56276K RUN 2 42:24 76.51% perl5.8.8 80077 c22chio 1 120 0 77952K 43544K RUN 0 41:00 63.33% perl5.8.8 80079 c22chio 1 117 0 78168K 49140K CPU3 3 41:25 63.18% perl5.8.8 80078 c22chio 1 115 0 79636K 48336K CPU1 0 41:39 54.00% perl5.8.8 80093 c22chio 1 -16 0 11416K 10124K wdrain 1 9:11 13.43% crawld 67240 c22chio 45 4 0 317M 286M RUN 2 195:25 7.76% mysqld ---------------------------------------------------------------------- perl5.8.8 ってのがパーサなんですが,CPU 4 つなのでプロセス数も 4 にしてます. あと,フロント側はこんな感じ.LA の数値は劇的に高いってほどでもないんですが, getf.cgi の取得で引っかかり感があるかな,と...... ---------------------------------------------------------------------- last pid: 40422; load averages: 2.79, 3.33, 3.66 up 28+06:03:16 01:08:11 1345 processes:26 running, 1319 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 546M Active, 271M Inact, 372M Wired, 5652K Cache, 112M Buf, 807M Free Swap: 2048M Total, 432K Used, 2047M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 40421 p22chio 1 97 0 5560K 4168K select 1 0:00 3.08% speedy_backen 40419 p22chio 1 97 0 5496K 4248K select 3 0:00 2.42% speedy_backen 40417 p22chio 1 96 0 5640K 4432K select 2 0:00 1.88% speedy_backen 40420 p22chio 1 4 0 5500K 4224K sbwait 0 0:00 1.88% speedy_backen 40415 p22chio 1 4 0 6048K 4628K sbwait 3 0:00 1.86% speedy_backen 40418 p22chio 1 96 0 5640K 4468K RUN 0 0:00 1.75% speedy_backen 40403 p22chio 1 96 0 6804K 5524K select 3 0:01 1.55% speedy_backen ---------------------------------------------------------------------- 関連キーワードをおすすめ2ちゃんねるみたいにCGIを叩かずに取得できるようにして欲しい。 スレの話題が分かりやすくて便利なので。 >>102 read.cgi に直接組み込むってことですか? そうすると read.cgi 自体が重くなる要因になるような...... # p2.2ch.io が重くなっても read.cgi の表示そのものに影響を与えないように今の形になってるんで...... >>104 http://p2.2ch.io/getf.cgi?http ://qb5.2ch.net/test/read.cgi/operate/1166328527/ とかじゃダメなんですかね? それはともかく,表示用キーワード抽出を始める前にあらかじめ約26万 URL 分のデータを蓄積してから開始したわけですが mysql> SELECT COUNT(*) FROM urls; +----------+ | COUNT(*) | +----------+ | 377699 | +----------+ 結構たまってきたかな.表示用キーワードが抽出されてない URL 数は mysql> SELECT COUNT(*) FROM urls LEFT JOIN dispwords ON urls.id = dispwords.url_id WHERE dispwords.url_id IS NULL; +----------+ | COUNT(*) | +----------+ | 147607 | +----------+ まで減ってきてるんで,約23万 URL 分のキーワードを抽出した,と...... パーサは相変わらずフル回転ですがw last pid: 86427; load averages: 3.71, 3.81, 3.76 up 29+13:01:16 09:56:17 1376 processes:7 running, 1369 sleeping CPU states: % user, % nice, % system, % interrupt, % idle Mem: 859M Active, 743M Inact, 313M Wired, 84M Cache, 112M Buf, 3416K Free Swap: 2048M Total, 60K Used, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 83069 c22chio 1 121 0 128M 98076K CPU3 3 564:41 75.68% perl5.8.8 83068 c22chio 1 123 0 128M 100M RUN 0 565:13 75.20% perl5.8.8 83070 c22chio 1 121 0 129M 104M RUN 2 563:53 71.78% perl5.8.8 83067 c22chio 1 118 0 126M 92476K RUN 0 565:14 67.97% perl5.8.8 67240 c22chio 46 96 0 317M 288M RUN 0 714:55 12.55% mysqld 80093 c22chio 1 4 0 7772K 6532K kqread 0 189:24 5.57% crawld 2chブラウザに関連キーワードを組み込むときに、毎回CGIを叩くのは負荷がかかりそう。 別にいいなら今の仕様でもいいんだけど。 リンク先がこんな風になってるのは仕様でしょうか。 http://find.2ch.net/?BBS=ALL& ;amp;TYPE=TITLE&ENCODING=SJIS&STR=workers 専ブラで読み込ませたらfindのトップに飛ばされた iframe が height=15 だと 3pix ほど足りなくて下のほうが欠けています(firefox2@win) height=18 程度に増やすか、文字を小さくしてもらえないでしょうか? >>106 read.cgiに負荷をかけるよりはマシかと。 >>106 内部的に登録されているキーワードは最大10なんですが, そのうち7つをランダム表示するような仕様になってます. 通常なら,個人的には Last-Modified 吐き + mod_cache 利用推進論者なんですが, キャッシュさせるとランダム表示ができなくなるというのがネックですね. ただ,CGI 側で MySQL のクエリー結果をキャッシュするようにはなってます. # もっとも,そのキャッシュはプロセス単位なんですよね.今は -M32 になってますが, # これを減らした方がキャッシュヒット率は向上するかと思うんですが,さて...... あと,getf.cgi で一番重い処理はその MySQL へのクエリー部分で, それ以外は単純に結果を吐くだけなんで,304 レスポンスを返すようにしても 大して変わらないんじゃないかという感じではあるんで(304 レスポンスを 返すとすると,mtime と If-Modified-Since の比較処理も Perl でやることになるし). >>107 (X)HTML 的には,<a> タグの href 属性中の & は,本来 & のように エスケープすべきものなんです(例えば CGI のパラメータで lt とか gt なんてのが あったらどうなるか......と考えればわかるかと). >>108 font-size: 13px; にしますた. いつの間にか,雪だるまや ex17 などの read.cgi も p2.2ch.io の方を読み込んでますね. ってことは,時間制限なしで 2ch 全鯖対象にしても,少なくとも Load Avg. 的には破綻せず処理できてる,と. 11:38PM up 30 days, 4:33, 1 user, load averages: 2.49, 3.16, 3.20 @c2.2ch.io 11:39PM up 30 days, 4:34, 1 user, load averages: 2.66, 3.15, 3.19 @p2.2ch.io キーワードが蓄積されるに伴い,クローラはあまりファイルを取得しに逝かなくなるので c2 のトラフィックは減ってきてますが,逆にキーワードを表示する p2 のトラフィックは増えてますね. http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/ 10個全部を吐くようにして、 javascript側でランダム表示にしちゃうとか。 そもそも、たかが10個のうち7個をランダムで表示する必要があるのだろうか。 100個あるならともかく。 今年もよろしくお願いいたします。 まずは、MySQL のインストールからですね。 普通に 5.x を入れればいいのかしら。 何か特別な設定が必要な場合、ここで教えてくださいです。 で、10Mbps → 100Mbps ですが、 どうも依頼がうまく受け付けられていないようなので、 メールでたんたんと依頼(催促)するということで。 >>120 了解です。それで。 まずは、mecab-0.93 を入れました。 MySQL は本日帰宅後にでも。 tf-idfを2chDB自体を使ってやるとすると、 sennaは必須になりますね。。と。 >>122 これですか。 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 >>125 > 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 容量が半端ないぐらい必要になるような...... 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 何かゴミデータが混ざってるな,と思ったら...... 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ってよくつかわれてそうなのに。。 >>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. >>135 ・10Mbps→100Mbps ・>>125-126 の作業 - MySQL - mecab - c2 の httpd を減らす あたりですか。 >>137 そんなところですね.ということでよろしくおながいします. で,MySQL を入れるのは最初 p2 がいいかなと思ってたんですが, 現状を鑑みれば c2 の方が良さそうという気がしてます. p2 で mod_speedycgi を使うということで prefork MPM 利用は確定のようですし, そうなると p2 に MySQL を入れるとなるとメモリやコンテキストスイッチなどの 競合できつくなりそうですし.c2 でもパーサがフル回転してる時は CPU で競合しますが, データ収集が一巡してからはパーサも常時フル回転ではなくなってますし(で,2日以上経過した データから順次再クロールする処理も入れますたが,それも比較的余力を持ってこなしてますし). p2 でもピーク時間帯はどっちにしろ CPU 食いますし,c2 ではプロセス数の少なさから メモリやコンテキストスイッチなどで競合しにくいだろう,ってことで. - 10Mbps → 100Mbps - p2 ⇔ c2 クロスケーブルで直結 について、再度メールで依頼しました。 関係者に Cc:。 >>135 スレ同士の自動リンクツールとするならもう少し人為を反映する仕様があったほうがいいような 今現在までの閉鎖騒動関連スレを幾つか見たけど 「24」を地で行くようなちょろの奮闘が眩しかった。 ひ(ryが2chを、というより、2chがこの男を失うか否かというような。 そんな風に見えなくもない今回の騒動。 これiframeでやってるのもったいないなぁ read.cgi直書きになる予定ってないんすかねぇ >>144 read.js では iframe ではなく JavaScript による DOM 操作でやってます. ただ,古いブラウザだと DOM をちゃんと扱えないかも知れないというところで, read.cgi でその方式にするのは躊躇してます. あと,管理人さんからは,2ch 専用でしか使えないものではなく 他のところでも汎用的に使い回しができる形で作ってほしいとも言われてたので, read.cgi に依存する部分は小さくしておきたい,ということもあります. 停電の影響ですかね.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' >>146 上げました。 しかし、c2.2ch.io が落ちている予感。 >>147 復旧した模様。< c2.2ch.io 原因はカーネルパニック(ffs dup alloc)だったもより。 これ、HDD に強烈にアクセスする場合にごくまれに出るですね。 >>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 21位ですか・・・ 平均滞在時間は、かなり上位になりますねぇ・・・ p2.2ch.io と c2.2ch.io があるのだが。 やっぱ携帯か。 なるほどね。 つーことは、あれか? mixiができたから2ちゃんねるが廃れるとかって今のところは無いのだな。 >>150 なるほど......まぁ read.cgi 画面に組み込まれて表示されますからね. # 今 2ch.io で本格的にやってるサービスは,この関連キーワードぐらいなのかな......? >>151 MERGE テーブルですね.有用性はあるようなので,ぼちぼち考えますか (あるいは MyISAM から InnoDB に変えるかどうか,ってのも思案のしどころですが). # もっとも,停電で落ちるってのがそもそも起こるべきでないことではありますが...... >>153 c2 ってのは携帯ではないですよ.あくまで裏方の処理をする鯖で, 一般閲覧者が直接アクセスする鯖ではないです.というか,read.cgi を 直接見られるフルブラウザ搭載の携帯って,まだ一部じゃないのかな...... >>161 きっと c.2ch.net や p2.2ch.net のイメージがあるので、 p2 とか c2 というホスト名だと、携帯関連だと思うんじゃないかなと。 2ch.ioのpとcは、パーサのpとクローラのcだったりする(命名は管理人)。 >>162 >2ch.ioのpとcは、パーサのpとクローラのcだったりする(命名は管理人)。 そうだったんですかぁ......しかし,現状では p2: フロントエンド (getf.cgi) c2: クローラ (crawld), パーサ (parsed.pl), MySQL なので,c2 は pc2 にした方が「名は体を表す」ですねw # p2 は 'p' が取れて,どうなるんだろ...... >>162 むむむの部屋では2ちゃんねる画像掲示板になってるよ。<up01.2ch.io この鯖は>>161 なのね。 >>164 あ、up01 ってもうないかも。 更新jしておきます。 既に削除済みだった。 < up01.2ch.io # おかしいと思った、、、。 ん?よく判らないけどこうなってる。 ttp://sv2ch.baila6.jp/server.cgi?server=up01.2ch.io たとえば、1日ごとにテーブルを作るようにして、 selectするときは、2週間分をMERGEとかにすると、 鮮度の高いものだけをとれるのと、 検索対象がリニアに大きくなるのは防げるかと。 古いのはdrop tableとかで捨てちゃうとかで。 >>170 mergeしようがしまいが、データ量がメモリ内に収まるのであれば、 オンメモリなので、コストはそんなに変わらないです。 データが肥大化してオンメモリで処理できなくなったときに、 ボトルネックが発生するので、 肥大化しないようにするほうがいいと思うのですよ。 2chの未来占いではこんな感じで出てるけど http://aglgag.livedoor.biz/ 黒幕さんの生年月日も分かればリクエストしたいざんす >>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 ピーク時間帯で引っかかり感を感じることがあるのは,個人的には 登録処理時にテーブルロックで待たされるのが原因じゃないかと見てます. http://mumumu.mu/mrtgi/mrtg-rrd.cgi/traffic/ のグラフで,c2 のひろゆきさんのヒゲみたいwなのは再クロール処理によるものですが, ピーク時間帯では c2 のヒゲと p2 のへこみが連動してるのもそのためではないかと. InnoDB にすればテーブルロックはなくなる(しかもトランザクションログを使うので 鯖落ち後のリカバリに長時間かかることもなくなるでしょうし),その代わり 全般的に処理は重くなりそう,それで結果的にプラスになるかマイナスになるかは 予測がつかないので,思案のしどころということで...... # まぁ,それ以前にピーク時間帯は再クロールを停止すればいいのかもですがw ちなみに,getf.cgi でやってるクエリーはこんな感じですが, 特段のネックはないのではないかと...... mysql> EXPLAIN EXTENDED SELECT words.word, UNIX_TIMESTAMP(urls.mtime) FROM urls, dispwords, words WHERE urls.url = 'http://qb5.2ch.net/operate/dat/1166328527.dat' 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) 時代はInnoDBっすよ。 sennaを使うとかでなければ、 myIsamにするメリットってあんまりない気がします。 >>177 なるほど......やはり機能的にはそうなんですよね. ただ,MyISAM vs InnoDB のベンチマーク結果の載ってるサイトとか見て回ってると, パフォーマンス面で一抹の不安があったり......まぁベンチはいろんな条件次第で 結果は変わってくるんで,どっちに転ぶかは実際やってみないとわからないんですけどね. >>179 まぁそうですね.やるとすると 1. テーブルの MyISAM -> InnoDB 変換. 2. MyISAM では COUNT(*) が高速ということに依存してる部分があるので, レコード数を保持するテーブルを新設して COUNT(*) をなくす. 3. 登録時に START TRANSACTION 〜 COMMIT を使う (2. と併せ登録用ストアドプロシージャを変更). 4. my.cnf に InnoDB 用の設定を入れる. ってのをやることになりますが,特に 1. とかやると時間がかかりそうなんで, 今夜のピーク時間帯以降にぼちぼちって感じで...... >3. 登録時に START TRANSACTION 〜 COMMIT を使う 使わないほうが早くないすか? >>181 いや......現状の登録用ストアドプロシージャは↓のようなものですが, START TRANSACTION を使わない場合の implicit commit は各 INSERT / UPDATE / DELETE ごとに行われるので何回も commit することになってしまうのに対し, 全体を START TRANSACTION 〜 COMMIT で囲めば commit は1回だけなので. もちろん,データの一貫性保持の観点からも 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 おぉ、、ストアードプロシージャーをすでに使ってるんですかぁ。 ラジャーです。 Operaだと関連キーワードやofuda.ccのあれととスレの一番上の全部や掲示板に戻るが重なって 掲示板に戻るがクリックできない。 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; ja) Opera 9.02 これって、全部、普通のブラウザからの機能ですよね 2ch専用ブラウザにデータを渡して貰えば、クライアントで処理できるんじゃないの? 話題がそれていたらご免なさい 専用ブラウザ使っているから、見ること無いでね getf.cgiの使い方を説明すればいいんですかね? http://p2.2ch.io/getf.cgi?http ://qb5.2ch.net/test/read.cgi/operate/1166328527/ >>185 まー確かに一理あるな。<2chブラから情報収集 技術的に可能かどうかより、ひろゆきが望むかどうかなんだが。 >>189 望むも何も、>>186 が答えだろ。 少なくても今の段階では、外部からも自由に使ってみて良いんだと思う。 駄目ならその内アクセス制限掛けるだろうし。 専ブラ側でget.cgiをコールすればキーワードが返ってくるから、 後は専ブラ側でどうぞと。 つう訳で人柱になる専ブラ無いかな。 >>190 Jane派生といくつかの2chブラから閲覧はできる。 見るだけならその通り。 2chブラウザからのアクセス統計も集めるかどうかですよ。 専ブラ開発系のスレッドで告知すればいいんですかね? >>192 うーん数多いから面倒だろ ここで公示すればどうよ。 ひろゆきが2chブラウザから関連キーワードを閲覧できるようにしてちょうだいって言ってる。 http://qb5.2ch.net/test/read.cgi/operate/1166328527/186 186 名前:ひろゆき@どうやら管理人 ★[] 投稿日:2007/01/26(金) 04:05:53 ID:???0 ?S★(102442) getf.cgiの使い方を説明すればいいんですかね? http://p2.2ch.io/getf.cgi?http ://qb5.2ch.net/test/read.cgi/operate/1166328527/ 閲覧可能にしてほしいって言ってるだけで、2chブラからの集計はしてないですよ。 >>195 の底はおすすめ2ちゃんねるとゴッチャになってた。スマソ。 一種の検索ソフトだから、それなりにあるんじゃない? ググルとか、ヤッホーとか、MSとか やってるからね 専ブラで、負荷分散すればそれなりのが出来るかもしれないけど 上記とぶつかると思うよ ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる