きちんとメンテナンスしてみようなスレッド。
関連キーワードをなんとかしようスレ
■ このスレッドは過去ログ倉庫に格納されています
きちんとメンテナンスしてみようなスレッド。
母集団を反映してる標本なら、
それでもいいと思いますー。
仕組み的には，この数をもっと増やすことも不可能ではありませんが，
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
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;
0133耐
2007/01/06(土) 19:49:16ID:FcjBKnL90デフォルトでは 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.
0136動け動けウゴウゴ２ちゃんねる
2007/01/08(月) 22:50:59ID:EY1iKiNMP・10Mbps→100Mbps
・>>125-126 の作業
- MySQL
- mecab
- c2 の httpd を減らす
あたりですか。
で，MySQL を入れるのは最初 p2 がいいかなと思ってたんですが，
現状を鑑みれば c2 の方が良さそうという気がしてます．
p2 で mod_speedycgi を使うということで prefork MPM 利用は確定のようですし，
そうなると p2 に MySQL を入れるとなるとメモリやコンテキストスイッチなどの
競合できつくなりそうですし．c2 でもパーサがフル回転してる時は CPU で競合しますが，
データ収集が一巡してからはパーサも常時フル回転ではなくなってますし（で，2日以上経過した
データから順次再クロールする処理も入れますたが，それも比較的余力を持ってこなしてますし）．
p2 でもピーク時間帯はどっちにしろ CPU 食いますし，c2 ではプロセス数の少なさから
メモリやコンテキストスイッチなどで競合しにくいだろう，ってことで．
- p2 ⇔ c2 クロスケーブルで直結
について、再度メールで依頼しました。
関係者に Cc:。
0142動け動けウゴウゴ２ちゃんねる
2007/01/11(木) 03:08:24ID:VhKIX1KV0スレ同士の自動リンクツールとするならもう少し人為を反映する仕様があったほうがいいような
0143動け動けウゴウゴ２ちゃんねる
2007/01/16(火) 03:57:50ID:kO1prtGV0「24」を地で行くようなちょろの奮闘が眩しかった。
ひ(ryが2chを、というより、2chがこの男を失うか否かというような。
そんな風に見えなくもない今回の騒動。
read.cgi直書きになる予定ってないんすかねぇ
ただ，古いブラウザだと DOM をちゃんと扱えないかも知れないというところで，
read.cgi でその方式にするのは躊躇してます．
あと，管理人さんからは，2ch 専用でしか使えないものではなく
他のところでも汎用的に使い回しができる形で作ってほしいとも言われてたので，
read.cgi に依存する部分は小さくしておきたい，ということもあります．
[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'
上げました。
しかし、c2.2ch.io が落ちている予感。
復旧した模様。< c2.2ch.io
原因はカーネルパニック(ffs dup alloc)だったもより。
これ、HDD に強烈にアクセスする場合にごくまれに出るですね。
# サイズのデカいテーブルが壊れると，リカバリに時間がかってしょうがないですねぇ......
# 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
2ch.ioがランク入りしてしまった様子。
21位ですか・・・
平均滞在時間は、かなり上位になりますねぇ・・・
0153動け動けウゴウゴ２ちゃんねる
2007/01/23(火) 10:59:16ID:X6iTzN4i0やっぱ携帯か。
0154動け動けウゴウゴ２ちゃんねる
2007/01/23(火) 11:05:01ID:X6iTzN4i00156動け動けウゴウゴ２ちゃんねる
2007/01/23(火) 13:43:32ID:X6iTzN4i0つーことは、あれか？
mixiができたから２ちゃんねるが廃れるとかって今のところは無いのだな。
0157動け動けウゴウゴ２ちゃんねる
2007/01/23(火) 20:49:46ID:X6iTzN4i0言ったんだが返事が無いなｧ。
http://qb5.2ch.net/test/read.cgi/operate/1168090804/933
ひょっとして相手にされてないのか？
0158動け動けウゴウゴ２ちゃんねる
2007/01/23(火) 20:59:34ID:nBCpy34EP0159動け動けウゴウゴ２ちゃんねる
2007/01/23(火) 22:31:06ID:ttLdMJWB0なら俺は風見しんごの娘を殺す
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/
0160動け動けウゴウゴ２ちゃんねる
2007/01/23(火) 22:32:03ID:ALRfqIPI0# 今 2ch.io で本格的にやってるサービスは，この関連キーワードぐらいなのかな......？
>>151 MERGE テーブルですね．有用性はあるようなので，ぼちぼち考えますか
（あるいは MyISAM から InnoDB に変えるかどうか，ってのも思案のしどころですが）．
# もっとも，停電で落ちるってのがそもそも起こるべきでないことではありますが......
>>153 c2 ってのは携帯ではないですよ．あくまで裏方の処理をする鯖で，
一般閲覧者が直接アクセスする鯖ではないです．というか，read.cgi を
直接見られるフルブラウザ搭載の携帯って，まだ一部じゃないのかな......
きっと c.2ch.net や p2.2ch.net のイメージがあるので、
p2 とか c2 というホスト名だと、携帯関連だと思うんじゃないかなと。
2ch.ioのpとcは、パーサのpとクローラのcだったりする(命名は管理人)。
>2ch.ioのpとcは、パーサのpとクローラのcだったりする(命名は管理人)。
そうだったんですかぁ......しかし，現状では
p2: フロントエンド (getf.cgi)
c2: クローラ (crawld), パーサ (parsed.pl), MySQL
なので，c2 は pc2 にした方が「名は体を表す」ですねｗ
# p2 は 'p' が取れて，どうなるんだろ......
0164動け動けウゴウゴ２ちゃんねる
2007/01/24(水) 00:20:29ID:gqpPG0ef0むむむの部屋では２ちゃんねる画像掲示板になってるよ。＜up01.2ch.io
この鯖は>>161なのね。
あ、up01 ってもうないかも。
更新jしておきます。
# おかしいと思った、、、。
0167動け動けウゴウゴ２ちゃんねる
2007/01/24(水) 00:40:10ID:gqpPG0ef0ttp://sv2ch.baila6.jp/server.cgi?server=up01.2ch.io
0168動け動けウゴウゴ２ちゃんねる
2007/01/24(水) 00:51:14ID:NH5IBiiS0selectするときは、2週間分をMERGEとかにすると、
鮮度の高いものだけをとれるのと、
検索対象がリニアに大きくなるのは防げるかと。
古いのはdrop tableとかで捨てちゃうとかで。
0170動け動けウゴウゴ２ちゃんねる
2007/01/24(水) 19:04:22ID:gqpPG0ef0んーそれってコスト高くない？
0171動け動けウゴウゴ２ちゃんねる
2007/01/24(水) 19:48:55ID:/pXKQOLR0mergeしようがしまいが、データ量がメモリ内に収まるのであれば、
オンメモリなので、コストはそんなに変わらないです。
データが肥大化してオンメモリで処理できなくなったときに、
ボトルネックが発生するので、
肥大化しないようにするほうがいいと思うのですよ。
0173http:// 244.111.215.220.ap.yournet.ne.jp.2ch.net/
2007/01/25(木) 11:50:19ID:oxnNK9gY00174動け動けウゴウゴ２ちゃんねる
2007/01/25(木) 12:52:45ID:lJVO0eQF0http://aglgag.livedoor.biz/
黒幕さんの生年月日も分かればリクエストしたいざんす
表示時には使用しません．それ以外の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 にすればテーブルロックはなくなる（しかもトランザクションログを使うので
鯖落ち後のリカバリに長時間かかることもなくなるでしょうし），その代わり
全般的に処理は重くなりそう，それで結果的にプラスになるかマイナスになるかは
予測がつかないので，思案のしどころということで......
# まぁ，それ以前にピーク時間帯は再クロールを停止すればいいのかもですがｗ
特段のネックはないのではないかと......
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)
sennaを使うとかでなければ、
myIsamにするメリットってあんまりない気がします。
ただ，MyISAM vs InnoDB のベンチマーク結果の載ってるサイトとか見て回ってると，
パフォーマンス面で一抹の不安があったり......まぁベンチはいろんな条件次第で
結果は変わってくるんで，どっちに転ぶかは実際やってみないとわからないんですけどね．
1. テーブルの MyISAM -> InnoDB 変換．
2. MyISAM では COUNT(*) が高速ということに依存してる部分があるので，
レコード数を保持するテーブルを新設して COUNT(*) をなくす．
3. 登録時に START TRANSACTION 〜 COMMIT を使う
（2. と併せ登録用ストアドプロシージャを変更）．
4. my.cnf に InnoDB 用の設定を入れる．
ってのをやることになりますが，特に 1. とかやると時間がかかりそうなんで，
今夜のピーク時間帯以降にぼちぼちって感じで......
使わないほうが早くないすか？
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
ラジャーです。
掲示板に戻るがクリックできない。
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; ja) Opera 9.02
0185動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 00:26:59ID:CxnnXu9Q0２ｃｈ専用ブラウザにデータを渡して貰えば、クライアントで処理できるんじゃないの？
話題がそれていたらご免なさい 専用ブラウザ使っているから、見ること無いでね
http://p2.2ch.io/getf.cgi?http://qb5.2ch.net/test/read.cgi/operate/1166328527/
0187動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 04:07:25ID:xv4yZrZ100188動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 04:49:18ID:XaZ1ZGLD00189動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 07:15:29ID:G006ntY00まー確かに一理あるな。＜２ｃｈブラから情報収集
技術的に可能かどうかより、ひろゆきが望むかどうかなんだが。
0190動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 11:07:05ID:hJoWPiym0望むも何も、>>186が答えだろ。
少なくても今の段階では、外部からも自由に使ってみて良いんだと思う。
駄目ならその内アクセス制限掛けるだろうし。
専ブラ側でget.cgiをコールすればキーワードが返ってくるから、
後は専ブラ側でどうぞと。
つう訳で人柱になる専ブラ無いかな。
0191動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 12:21:58ID:G006ntY00Jane派生といくつかの2chブラから閲覧はできる。
見るだけならその通り。
2chブラウザからのアクセス統計も集めるかどうかですよ。
0193外野ｧｧﾝ
2007/01/26(金) 12:25:28ID:UA1Fteu600194動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 12:27:48ID:G006ntY00うーん数多いから面倒だろ
ここで公示すればどうよ。
0195こんなんで良い？
2007/01/26(金) 12:46:09ID:G006ntY00http://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ブラからの集計はしてないですよ。
0196こんなんで良い？
2007/01/26(金) 12:50:06ID:G006ntY000197動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 15:05:09ID:CxnnXu9Q0ググルとか、ヤッホーとか、ＭＳとか やってるからね
専ブラで、負荷分散すればそれなりのが出来るかもしれないけど
上記とぶつかると思うよ
>>184 下線付近のごく狭い領域ならクリックできたりしませんか？
0199動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 15:09:50ID:yN4KQ28M0出来たり出来なかったりです。
フォーカスがあってもカーソルの形も変わりませんし。
0200動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 15:58:14ID:CxnnXu9Q0関連キーワードログを保存しますか？しませんか？
関連キーワード登録しますか？しませんか？
関連キーワードデータをアップロードしますか？しませんか？
パケット課金ユーザーには、無縁の話しかも知れません
あっても良いなの機能ですが
0201動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 16:00:03ID:yN4KQ28M0innodb_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 使ってるので，それの関係ですかね......
0203動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 16:06:55ID:yN4KQ28M0掲示板に戻る、全部等を囲っているspanを消したらクリックできるようになりますから多分そうでしょう。
> % limit -h datasize
> datasize 524288 kbytes
FreeBSD/i386 って、これ、増やせるんでしたっけ、、、。
datasize 33554432 kbytes
になっているです。
#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);
となっているのか。
とりあえず、
kern.maxdsiz="2048m"
とかですかね。
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
# どおりで，sysctl -a の出力からそれらしきものを探してもなかったわけだ......
>>202 に加え，↑の設定も入れますた．で，MySQL は無事立ち上がり，
現在 MyISAM -> InnoDB にテーブル変換中......
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
0212動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 19:20:31ID:Zma3Ljln0Janeなら外部コマンドで見れるから
閲覧なら新しく機能つけなくてもいいかと
0213動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 22:37:44ID:txiJMxDB00214動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 22:40:22ID:yN4KQ28M0とか
$CHOTTO http://p2.2ch.io/getf.cgi?$URL
とか。
0215動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 23:02:10ID:CxnnXu9Q0タイトルの前に３つ出すの書ける？
0216動け動けウゴウゴ２ちゃんねる
2007/01/26(金) 23:19:17ID:yN4KQ28M0変換はすでに終わってるので，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
0219動け動けウゴウゴ２ちゃんねる
2007/01/27(土) 00:06:44ID:CxnnXu9Q0>>218
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
発生してしまうという......そのため，登録処理は単純に 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
0223動け動けウゴウゴ２ちゃんねる
2007/01/27(土) 22:15:46ID:FzgyxveM0記憶力弱いんで違ってたらスマソ
３回目か ホリエモンの１クリック程度の価値有ったのだろうか？
意外と進歩してないモンだな
辞書をロカールに於いて、集めてきて賢くするだったかな？
英和、和英何てのも有った 思い出すことは出来ないだろうが
新規データは登録されるものの，再クロールでの更新データはデッドロックのため
ほとんど登録されず 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 も働き出した．
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 への切り替えはプラス側に転んだ，ということでいいのかな．
しかし InnoDB の本来の力を発揮させるには、
プログラミング上の注意も必要、ということですか。
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 食うんでそんな有り余ってる訳じゃないし......
などと心配してたんですが，杞憂だったようでめでたしめでたし．
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 【維新】吉村知事「0歳児から選挙権を持ってもらうべき。親が代理で選挙権を行使する。僕は子どもが3人だから4票の影響力がある」 ★2 [Hitzeschleier★]
- 【株】中学生から株を始めて19歳で“億り人”に！ 現役医学生トレーダーが資産1億6000万円になるまで [PARADISE★]
- ひろゆき、被災地・能登に訪問 「今の景色は天災じゃなく人災」「能登を見捨てるというのは日本の皆さんが望んだ結果」 [Anonymous★]
- 【魚】極小焼さけ弁当が大人気 米消費拡大の起爆剤に ＪＡ秋田おばこ [少考さん★]
- 「ムスコは元気か？」サウナ室内で“不適切行為”が横行し、鹿児島の人気ヘルスセンターが閉店 [煮卵★]
- 東京メトロのポスターに「白人差別だ」との声 [少考さん★]
- 【実況】博衣こよりのえちえちFF10リバース【デートあり】🧪
- 【実況】博衣こよりのえちえちFF9リバース【デートあり】🧪
- 堀江貴文｢GU一斉休みやめませんか？GUにゴルフ行ったら大渋滞巻き込まれたんですよマジで「昭和の遺物」｣ [517459952]
- 【朗報】悠仁さま、推薦入学で東大へｗｖｗｖｗｖｗｖｗｖｗｖ「合格の確率はかなり高い」 [373226912]
- 俺より賢いやついるの？
- 【徹底討論】キーボードにテンキーは必要か否か [402859164]