関連キーワードをなんとかしようスレ

**ひろゆき＠どうやら管理人 ★** · 2006/12/17(日) 13:08:47

read.cgiの片隅に表示されている関連キーワードを
きちんとメンテナンスしてみようなスレッド。

耐 · 2007/01/06(土) 19:49:16

このやろうなめやがって！！

株価【1400】 **▲▲▲▲** ◆cZfSunOs.U · 2007/01/07(日) 04:55:44

>>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.

**ひろゆき＠どうやら管理人 ★** · 2007/01/08(月) 11:10:08

現状ってあとは何が足りないんでしたっけ？

**動け動けウゴウゴ２ちゃんねる** · 2007/01/08(月) 22:50:59

>>135

**root▲▲ ★** · 2007/01/08(月) 23:12:32

>>135
・10Mbps→100Mbps
・>>125-126 の作業
- MySQL
- mecab
- c2 の httpd を減らす

あたりですか。

**root▲▲ ★** · 2007/01/09(火) 00:25:26

で、>>137 は、たんたんとすすめるです。

**ひろゆき＠どうやら管理人 ★** · 2007/01/09(火) 09:34:40

よろしくですー。

株価【1250】 **▲▲▲▲** ◆cZfSunOs.U · 2007/01/09(火) 10:49:56

>>137 そんなところですね．ということでよろしくおながいします．

で，MySQL を入れるのは最初 p2 がいいかなと思ってたんですが，
現状を鑑みれば c2 の方が良さそうという気がしてます．
p2 で mod_speedycgi を使うということで prefork MPM 利用は確定のようですし，
そうなると p2 に MySQL を入れるとなるとメモリやコンテキストスイッチなどの
競合できつくなりそうですし．c2 でもパーサがフル回転してる時は CPU で競合しますが，
データ収集が一巡してからはパーサも常時フル回転ではなくなってますし（で，2日以上経過した
データから順次再クロールする処理も入れますたが，それも比較的余力を持ってこなしてますし）．
p2 でもピーク時間帯はどっちにしろ CPU 食いますし，c2 ではプロセス数の少なさから
メモリやコンテキストスイッチなどで競合しにくいだろう，ってことで．

**root▲▲ ★** · 2007/01/09(火) 11:56:02

- 10Mbps → 100Mbps
- p2 ⇔ c2 クロスケーブルで直結

について、再度メールで依頼しました。
関係者に Cc:。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/11(木) 03:08:24

>>135
スレ同士の自動リンクツールとするならもう少し人為を反映する仕様があったほうがいいような

**動け動けウゴウゴ２ちゃんねる** · 2007/01/16(火) 03:57:50

今現在までの閉鎖騒動関連スレを幾つか見たけど
「24」を地で行くようなちょろの奮闘が眩しかった。

ひ(ryが2chを、というより、2chがこの男を失うか否かというような。
そんな風に見えなくもない今回の騒動。

◆A/T2/75/82 · 2007/01/17(水) 05:32:41

これiframeでやってるのもったいないなぁ
read.cgi直書きになる予定ってないんすかねぇ

株価【1200】 △ ◆cZfSunOs.U · 2007/01/17(水) 06:17:39

>>144 read.js では iframe ではなく JavaScript による DOM 操作でやってます．
ただ，古いブラウザだと DOM をちゃんと扱えないかも知れないというところで，
read.cgi でその方式にするのは躊躇してます．

あと，管理人さんからは，2ch 専用でしか使えないものではなく
他のところでも汎用的に使い回しができる形で作ってほしいとも言われてたので，
read.cgi に依存する部分は小さくしておきたい，ということもあります．

株価【1650】 △ ◆cZfSunOs.U · 2007/01/19(金) 15:22:17

停電の影響ですかね．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'

**root▲▲ ★** · 2007/01/20(土) 23:43:04

>>146
上げました。

しかし、c2.2ch.io が落ちている予感。

**root▲▲ ★** · 2007/01/21(日) 00:30:55

>>147
復旧した模様。< c2.2ch.io

原因はカーネルパニック(ffs dup alloc)だったもより。
これ、HDD に強烈にアクセスする場合にごくまれに出るですね。

株価【1399】 △ ◆cZfSunOs.U · 2007/01/21(日) 02:36:41

>>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

**ひろゆき＠どうやら管理人 ★** · 2007/01/23(火) 10:44:22

http://www.videoi.co.jp/data/summary_data/2007/wsr070117.html
2ch.ioがランク入りしてしまった様子。

**ひろゆき＠どうやら管理人 ★** · 2007/01/23(火) 10:49:04

テーブルって分割できる構造じゃないんでしたっけ？

[´・ω・｀] N076052.ppp.dion.ne.jp · 2007/01/23(火) 10:58:24

>>150
21位ですか・・・
平均滞在時間は、かなり上位になりますねぇ・・・

**動け動けウゴウゴ２ちゃんねる** · 2007/01/23(火) 10:59:16

p2.2ch.io と c2.2ch.io があるのだが。
やっぱ携帯か。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/23(火) 11:05:01

んーmixiがランクインしていないのは何故？

**ひろゆき＠どうやら管理人 ★** · 2007/01/23(火) 11:45:59

ユニークの数の集計だからじゃないすか。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/23(火) 13:43:32

なるほどね。

つーことは、あれか？
mixiができたから２ちゃんねるが廃れるとかって今のところは無いのだな。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/23(火) 20:49:46

ひろゆき＞
言ったんだが返事が無いなｧ。
http://qb5.2ch.net/test/read.cgi/operate/1168090804/933

ひょっとして相手にされてないのか？

**動け動けウゴウゴ２ちゃんねる** · 2007/01/23(火) 20:59:34

うぜえ

**動け動けウゴウゴ２ちゃんねる** · 2007/01/23(火) 22:31:06

皆でこのアホを通報しよう。２chの癌。

なら俺は風見しんごの娘を殺す
http://ex17.2ch.net/test/read.cgi/news4vip/1169394814/l50

863 ：動け動けウゴウゴ２ちゃんねる：2007/01/22(月) 11:36:52 ID:NF9a2QR+0
おじちゃん、殺人予告って2ch運営にはどこに通報すればいいのかしら?
見た感じいろんなところで予告してるみたいよ?

http://qb5.2ch.net/test/read.cgi/operate/1169301330/619
http://news22.2ch.net/test/read.cgi/newsplus/1169394325/914

864 ：どくどくさぼてん：2007/01/22(月) 11:41:12 ID:6SRCrGFv0
警察へどうぞ。
いや、ほんとならほんとに。

■警視庁匿名通報フォーム（通報は2chのように書き込むだけ）
　 http://ime.nu/www.keishicho.metro.tokyo.jp/anket/other.htm
■全国ハイテク警察リンク集　http://ime.nu/www002.upp.so-net.ne.jp/dalk/ksatulink.html
■警視庁ホームページ　　　　 http://www.keishicho.metro.tokyo.jp/

**動け動けウゴウゴ２ちゃんねる** · 2007/01/23(火) 22:32:03

そのままコピペかよｗ

株価【1203】 △ ◆cZfSunOs.U · 2007/01/23(火) 23:37:31

>>150 なるほど......まぁ read.cgi 画面に組み込まれて表示されますからね．
# 今 2ch.io で本格的にやってるサービスは，この関連キーワードぐらいなのかな......？

>>151 MERGE テーブルですね．有用性はあるようなので，ぼちぼち考えますか
（あるいは MyISAM から InnoDB に変えるかどうか，ってのも思案のしどころですが）．
# もっとも，停電で落ちるってのがそもそも起こるべきでないことではありますが......

>>153 c2 ってのは携帯ではないですよ．あくまで裏方の処理をする鯖で，
一般閲覧者が直接アクセスする鯖ではないです．というか，read.cgi を
直接見られるフルブラウザ搭載の携帯って，まだ一部じゃないのかな......

**root▲▲ ★** · 2007/01/23(火) 23:40:53

>>161
きっと c.2ch.net や p2.2ch.net のイメージがあるので、
p2 とか c2 というホスト名だと、携帯関連だと思うんじゃないかなと。

2ch.ioのpとcは、パーサのpとクローラのcだったりする(命名は管理人)。

株価【1203】 △ ◆cZfSunOs.U · 2007/01/23(火) 23:55:48

>>162
>2ch.ioのpとcは、パーサのpとクローラのcだったりする(命名は管理人)。

そうだったんですかぁ......しかし，現状では

p2: フロントエンド (getf.cgi)
c2: クローラ (crawld), パーサ (parsed.pl), MySQL

なので，c2 は pc2 にした方が「名は体を表す」ですねｗ
# p2 は 'p' が取れて，どうなるんだろ......

**動け動けウゴウゴ２ちゃんねる** · 2007/01/24(水) 00:20:29

>>162
むむむの部屋では２ちゃんねる画像掲示板になってるよ。＜up01.2ch.io
この鯖は>>161なのね。

**root▲▲ ★** · 2007/01/24(水) 00:22:29

>>164
あ、up01 ってもうないかも。
更新jしておきます。

**root▲▲ ★** · 2007/01/24(水) 00:23:30

既に削除済みだった。 < up01.2ch.io

# おかしいと思った、、、。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/24(水) 00:40:10

ん？よく判らないけどこうなってる。
ttp://sv2ch.baila6.jp/server.cgi?server=up01.2ch.io

**動け動けウゴウゴ２ちゃんねる** · 2007/01/24(水) 00:51:14

・・・・・

**ひろゆき＠どうやら管理人 ★** · 2007/01/24(水) 18:06:10

たとえば、1日ごとにテーブルを作るようにして、
selectするときは、2週間分をMERGEとかにすると、
鮮度の高いものだけをとれるのと、
検索対象がリニアに大きくなるのは防げるかと。

古いのはdrop tableとかで捨てちゃうとかで。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/24(水) 19:04:22

>>169
んーそれってコスト高くない？

**動け動けウゴウゴ２ちゃんねる** · 2007/01/24(水) 19:48:55

専ブラ使ってると関係ない感じがひしひしとします

**ひろゆき＠どうやら管理人 ★** · 2007/01/25(木) 11:33:17

>>170
mergeしようがしまいが、データ量がメモリ内に収まるのであれば、
オンメモリなので、コストはそんなに変わらないです。
データが肥大化してオンメモリで処理できなくなったときに、
ボトルネックが発生するので、
肥大化しないようにするほうがいいと思うのですよ。

**http://** 244.111.215.220.ap.yournet.ne.jp.2ch.net/ · 2007/01/25(木) 11:50:19

guest　guest

**動け動けウゴウゴ２ちゃんねる** · 2007/01/25(木) 12:52:45

2chの未来占いではこんな感じで出てるけど
http://aglgag.livedoor.biz/

黒幕さんの生年月日も分かればリクエストしたいざんす

株価【1300】 △ ◆cZfSunOs.U · 2007/01/25(木) 13:16:34

>>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 のひろゆきさんのヒゲみたいｗなのは再クロール処理によるものですが，
ピーク時間帯では c2 のヒゲと p2 のへこみが連動してるのもそのためではないかと．
InnoDB にすればテーブルロックはなくなる（しかもトランザクションログを使うので
鯖落ち後のリカバリに長時間かかることもなくなるでしょうし），その代わり
全般的に処理は重くなりそう，それで結果的にプラスになるかマイナスになるかは
予測がつかないので，思案のしどころということで......
# まぁ，それ以前にピーク時間帯は再クロールを停止すればいいのかもですがｗ

株価【1300】 △ ◆cZfSunOs.U · 2007/01/25(木) 14:50:52

**ひろゆき＠どうやら管理人 ★** · 2007/01/25(木) 17:51:53

時代はInnoDBっすよ。
sennaを使うとかでなければ、
myIsamにするメリットってあんまりない気がします。

株価【1300】 △ ◆cZfSunOs.U · 2007/01/25(木) 18:28:22

>>177 なるほど......やはり機能的にはそうなんですよね．
ただ，MyISAM vs InnoDB のベンチマーク結果の載ってるサイトとか見て回ってると，
パフォーマンス面で一抹の不安があったり......まぁベンチはいろんな条件次第で
結果は変わってくるんで，どっちに転ぶかは実際やってみないとわからないんですけどね．

**ひろゆき＠どうやら管理人 ★** · 2007/01/25(木) 18:59:41

実際に試してみるほうが早いかもですね。

株価【1300】 △ ◆cZfSunOs.U · 2007/01/25(木) 19:15:59

>>179 まぁそうですね．やるとすると

1. テーブルの MyISAM -> InnoDB 変換．
2. MyISAM では COUNT(*) が高速ということに依存してる部分があるので，
　レコード数を保持するテーブルを新設して COUNT(*) をなくす．
3. 登録時に START TRANSACTION ～ COMMIT を使う
　（2. と併せ登録用ストアドプロシージャを変更）．
4. my.cnf に InnoDB 用の設定を入れる．

ってのをやることになりますが，特に 1. とかやると時間がかかりそうなんで，
今夜のピーク時間帯以降にぼちぼちって感じで......

**ひろゆき＠どうやら管理人 ★** · 2007/01/25(木) 20:08:23

＞3. 登録時に START TRANSACTION ～ COMMIT を使う
使わないほうが早くないすか？

株価【1300】 △ ◆cZfSunOs.U · 2007/01/25(木) 20:25:26

>>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

**ひろゆき＠どうやら管理人 ★** · 2007/01/25(木) 21:19:00

おぉ、、ストアードプロシージャーをすでに使ってるんですかぁ。
ラジャーです。

**ﾉtasukeruyo** · 2007/01/25(木) 22:12:16

Operaだと関連キーワードやofuda.ccのあれととスレの一番上の全部や掲示板に戻るが重なって
掲示板に戻るがクリックできない。

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; ja) Opera 9.02

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 00:26:59

これって、全部、普通のブラウザからの機能ですよね
２ｃｈ専用ブラウザにデータを渡して貰えば、クライアントで処理できるんじゃないの？

話題がそれていたらご免なさい　専用ブラウザ使っているから、見ること無いでね

**ひろゆき＠どうやら管理人 ★** · 2007/01/26(金) 04:05:53

getf.cgiの使い方を説明すればいいんですかね？

http://p2.2ch.io/getf.cgi?http://qb5.2ch.net/test/read.cgi/operate/1166328527/

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 04:07:25

XHTMLは扱いづらい

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 04:49:18

あ

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 07:15:29

>>185
まー確かに一理あるな。＜２ｃｈブラから情報収集
技術的に可能かどうかより、ひろゆきが望むかどうかなんだが。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 11:07:05

>>189
望むも何も、>>186が答えだろ。
少なくても今の段階では、外部からも自由に使ってみて良いんだと思う。
駄目ならその内アクセス制限掛けるだろうし。

専ブラ側でget.cgiをコールすればキーワードが返ってくるから、
後は専ブラ側でどうぞと。

つう訳で人柱になる専ブラ無いかな。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 12:21:58

>>190
Jane派生といくつかの2chブラから閲覧はできる。
見るだけならその通り。

2chブラウザからのアクセス統計も集めるかどうかですよ。

**ひろゆき＠どうやら管理人 ★** · 2007/01/26(金) 12:22:59

専ブラ開発系のスレッドで告知すればいいんですかね？

**外野ｧｧﾝ** · 2007/01/26(金) 12:25:28

そこでメールマガジンですよ

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 12:27:48

>>192
うーん数多いから面倒だろ
ここで公示すればどうよ。

**こんなんで良い？** · 2007/01/26(金) 12:46:09

ひろゆきが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ブラからの集計はしてないですよ。

**こんなんで良い？** · 2007/01/26(金) 12:50:06

>>195の底はおすすめ２ちゃんねるとゴッチャになってた。ｽﾏｿ。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 15:05:09

一種の検索ソフトだから、それなりにあるんじゃない？
ググルとか、ヤッホーとか、ＭＳとか　やってるからね

専ブラで、負荷分散すればそれなりのが出来るかもしれないけど
上記とぶつかると思うよ

株価【1100】 △ ◆cZfSunOs.U · 2007/01/26(金) 15:05:12

さて，>>180 をやろうかな......ってことで，しばらく止まります．

>>184 下線付近のごく狭い領域ならクリックできたりしませんか？

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 15:09:50

>>198
出来たり出来なかったりです。
フォーカスがあってもカーソルの形も変わりませんし。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 15:58:14

関連キーワードを取得しますか？しませんか？
関連キーワードログを保存しますか？しませんか？
関連キーワード登録しますか？しませんか？
関連キーワードデータをアップロードしますか？しませんか？

パケット課金ユーザーには、無縁の話しかも知れません
あっても良いなの機能ですが

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 16:00:03

まずどういうものか理解しよう。

株価【1100】 △ ◆cZfSunOs.U · 2007/01/26(金) 16:03:16

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 使ってるので，それの関係ですかね......

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 16:06:55

>>202
掲示板に戻る、全部等を囲っているspanを消したらクリックできるようになりますから多分そうでしょう。

**root▲▲ ★** · 2007/01/26(金) 16:58:08

>>202
> % limit -h datasize
> datasize 524288 kbytes

FreeBSD/i386 って、これ、増やせるんでしたっけ、、、。

**root▲▲ ★** · 2007/01/26(金) 17:29:26

ちなみに FreeBSD 6.2R/amd64 だと、

datasize 33554432 kbytes

になっているです。

**root▲▲ ★** · 2007/01/26(金) 17:35:00

/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);

となっているのか。

**root▲▲ ★** · 2007/01/26(金) 17:38:58

TUNABLE_ULONG_FETCH ってことは、/boot/loader.conf に書いて再起動か。
とりあえず、

kern.maxdsiz="2048m"

とかですかね。

**root▲▲ ★** · 2007/01/26(金) 17:45:30

# 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

株価【1100】 △ ◆cZfSunOs.U · 2007/01/26(金) 18:00:28

>>204-208 乙です．kern.maxdsiz とかは元々なくって，自分で新たに定義するものなんですね．
# どおりで，sysctl -a の出力からそれらしきものを探してもなかったわけだ......

株価【1100】 △ ◆cZfSunOs.U · 2007/01/26(金) 18:17:21

default-storage-engine = InnoDB

>>202 に加え，↑の設定も入れますた．で，MySQL は無事立ち上がり，
現在 MyISAM -> InnoDB にテーブル変換中......

株価【1100】 △ ◆cZfSunOs.U · 2007/01/26(金) 18:26:52

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

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 19:20:31

>>186 >>190
Janeなら外部コマンドで見れるから
閲覧なら新しく機能つけなくてもいいかと

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 22:37:44

それってWebブラウザにURL渡すだけでしょ？

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 22:40:22

$VIEW http://p2.2ch.io/getf.cgi?$URL
とか
$CHOTTO http://p2.2ch.io/getf.cgi?$URL
とか。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 23:02:10

jane 使ってみた　コマンドを書くの？

タイトルの前に３つ出すの書ける？

**動け動けウゴウゴ２ちゃんねる** · 2007/01/26(金) 23:19:17

タイトルの前に３つ出すのってなに？

株価【1100】 △ ◆cZfSunOs.U · 2007/01/26(金) 23:22:57

未だ 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

**ひろゆき＠どうやら管理人 ★** · 2007/01/26(金) 23:52:45

InnoDB！InnoDB！

**動け動けウゴウゴ２ちゃんねる** · 2007/01/27(土) 00:06:44

スレ立て人のＣＰＵ借りて結果だけ貰えば？

**動け動けウゴウゴ２ちゃんねる** · 2007/01/27(土) 13:39:15

>>218
>>218

株価【1150】 △ ◆cZfSunOs.U · 2007/01/27(土) 19:09:39

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

株価【1150】 △ ◆cZfSunOs.U · 2007/01/27(土) 19:11:47

ただ，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

**動け動けウゴウゴ２ちゃんねる** · 2007/01/27(土) 22:15:46

思い出した　昔、あったな、社会とかのボタン　無くなったんだよな確か？
記憶力弱いんで違ってたらスマソ
３回目か　ホリエモンの１クリック程度の価値有ったのだろうか？

意外と進歩してないモンだな
辞書をロカールに於いて、集めてきて賢くするだったかな？
英和、和英何てのも有った　思い出すことは出来ないだろうが

株価【1150】 △ ◆cZfSunOs.U · 2007/01/27(土) 22:22:23

>>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 も働き出した．

株価【1150】 △ ◆cZfSunOs.U · 2007/01/27(土) 22:24:45

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 への切り替えはプラス側に転んだ，ということでいいのかな．

**root▲▲ ★** · 2007/01/28(日) 00:06:46

おつでした。

しかし InnoDB の本来の力を発揮させるには、
プログラミング上の注意も必要、ということですか。

株価【1150】 △ ◆cZfSunOs.U · 2007/01/28(日) 00:50:48

>>226 まぁそうですね．とはいえ，
http://www.drk7.jp/MT/archives/000941.html
http://www.thinkit.co.jp/cert/article/0603/10/5/3.htm
あたりのベンチマークとか見てて，InnoDB だと重くてピーク時間帯に
c2 が死ぬんじゃないかとかビビってたり，
http://d.hatena.ne.jp/naoya/20060729/1154139996
では CPU 等のリソースが有り余ってれば InnoDB でいいんじゃない？
というような感じのことが書いてありますが，c2 はパーサで
CPU 食うんでそんな有り余ってる訳じゃないし......
などと心配してたんですが，杞憂だったようでめでたしめでたし．

**ひろゆき** · 2007/01/28(日) 02:03:16

デッドロックってあるんすねぇ。

**ひろゆき** · 2007/01/28(日) 06:26:08

あるある。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/29(月) 08:49:02

http://qb5.2ch.net/test/read.cgi/operate/1168100274/617
http://qb5.2ch.net/test/read.cgi/operate/1168100274/619

PVにさしたる影響は無いと思ってたけどかなり使っているんだねぇ。

**動け動けウゴウゴ２ちゃんねる** · 2007/01/30(火) 02:15:25

完走したニューススレの次スレ追跡に一応使える
本当はおすすめ2ちゃんねるのほうで対応して欲しいが

株価【1200】 △ ◆cZfSunOs.U · 2007/01/31(水) 23:44:43

さすがに InnoDB のリカバリは早いっすね，2秒ぐらい．

070131 23:24:01 mysqld started
070131 23:24:01 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
070131 23:24:02 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 11 4261151496.
InnoDB: Doing recovery: scanned up to log sequence number 11 4261161318
070131 23:24:02 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66
67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
070131 23:24:03 InnoDB: Started; log sequence number 11 4261161318
070131 23:24:03 [Note] /home/c22chio/mysql/bin/mysqld: ready for connections.
Version: '5.0.27-standard' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Edition - Standard (GPL)