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

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

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

**動け動けウゴウゴ２ちゃんねる** · 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)

**root▲▲ ★** · 2007/01/31(水) 23:52:52

>>232
おー、さすが。
Inno は innovation なんでしたっけ。

株価【1200】 △ ◆cZfSunOs.U · 2007/02/01(木) 00:10:53

>>233 まぁそんなところだと思います．
直接的には Innobase http://www.innodb.com/ から来てるんでしょうけど．

**ひろゆき＠どうやら管理人 ★** · 2007/02/01(木) 06:07:00

伊能忠敬。

**動け動けウゴウゴ２ちゃんねる** · 2007/02/01(木) 06:20:37

ぎゃはははは

**動け動けウゴウゴ２ちゃんねる** · 2007/02/01(木) 06:24:20

適切なリアクションが思いつかない自分を不甲斐なく思うよ
きっと就活の面接に落ち続けてる俺に“足りない何か”
を見つけるきっかけはここいら辺にあるんだと思う

株価【E】 △ ◆cZfSunOs.U · 2007/02/01(木) 08:40:05

いの一番に反応したかったものの，お二方に先を越されますた．

株価【E】 △ ◆cZfSunOs.U · 2007/02/01(木) 17:41:48

[Thu Feb 01 16:09:48 2007] [emerg] (17)File exists: Couldn't create accept lock (/var/log/accept.lock.634) (5)

ってことで rm /var/log/accept.lock.*; apachectl start おながいします @p2 ＞むむむさん

# 普通の場所だと EEXIST になったり，/md だとマウント前にファイル作ろうとしたりで，難しいですねぇ......

c2 は MySQL のシャットダウン処理中に落ちちゃったようですね．
まぁちゃんとリカバリしてますが．ただ，今回は28秒ぐらいかかってますけど......

070201 14:27:10 [Note] /home/c22chio/mysql/bin/mysqld: Normal shutdown
070201 14:27:12 InnoDB: Starting shutdown...
070201 17:01:01 mysqld started
070201 17:01: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...
070201 17:01:01 InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 14 502342626.
InnoDB: Doing recovery: scanned up to log sequence number 14 507585024
InnoDB: Doing recovery: scanned up to log sequence number 14 512827904
InnoDB: Doing recovery: scanned up to log sequence number 14 518070784
InnoDB: Doing recovery: scanned up to log sequence number 14 523313664
InnoDB: Doing recovery: scanned up to log sequence number 14 528556544
InnoDB: Doing recovery: scanned up to log sequence number 14 533799424
InnoDB: Doing recovery: scanned up to log sequence number 14 539042304
InnoDB: Doing recovery: scanned up to log sequence number 14 544285184
InnoDB: Doing recovery: scanned up to log sequence number 14 549528064
InnoDB: Doing recovery: scanned up to log sequence number 14 551520217
070201 17:01:09 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
070201 17:01:29 InnoDB: Started; log sequence number 14 551520217
070201 17:01:29 [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)

株価【E】 △ ◆cZfSunOs.U · 2007/02/01(木) 18:14:59

httpd@p2 立ち上がってますね．乙です＞むむむさん

**root▲▲ ★** · 2007/02/01(木) 18:30:48

>>239-240
やりました。

何か、しかけを入れる方向ですね。 < httpd health check

**root▲▲ ★** · 2007/02/01(木) 18:38:42

で、すごいバカな質問かもなんですが、
accept.lock って、そもそも作らないとまずいんでしたっけ。

株価【E】 △ ◆cZfSunOs.U · 2007/02/01(木) 23:32:08

>>242 ソケットの accept() を直列化するためのロックで利用するものですね．
ソケットが1つだけなら直列化は必須というわけでもないんですが，
直列化した方がカーネル内でのスピンを抑制し遅延を小さくする効果があるためにやってるらしいです．
cf. http://httpd.apache.org/docs/2.2/misc/perf-tuning.html
　　の "accept Serialization - single socket"

pthread_mutexattr_setrobust_np() が使えるなら AcceptMutex pthread を
安全に利用できるので，flock() / fcntl() ベースのロックを使わずに済む，
つまり accept.lock ファイルのことは考えずに済むんですが（それのみならず
パフォーマンス面でも有利ですし），FreeBSD ではそれはないようなので
安全には使えない（どれかの httpd プロセスが mutex lock を保持したまま死ぬと
他の httpd プロセスがデッドロックに陥ってしまう）ということで......

あと，/md の設定を /etc/fstab に入れれば /md のマウントのタイミングが
もっと早くなって accept.lock 生成で失敗しなくなる，とかいうことないんでしょうか？

**root▲▲ ★** · 2007/02/02(金) 09:56:43

>>243
ふむふむ。

一般的なサーバは、fstab にしてもいいかもしれないですね。
/md の大きさや設定は各サーバの事情によって結構変えているので、
/etc/fstab にあまり書きたくなかった、という事情がありました。

あと、FreeBSD 5.x のバージョンアップの時に、
fstab に md の設定を書いていると mount でしくって、
single user mode になってしまう、というのもありますね。

毎回 /md の mount をしないようにしてから作業すればいいんですが、
それよりも、別にスクリプトを書こうと。

…というか、たぶんきっと rcorder をちゃんと書けばいいような予感。

株価【1300】 △ ◆cZfSunOs.U · 2007/02/02(金) 22:57:15

>>244 なるほど...... rcorder ってのは依存関係を定義するんですね．
ただ，rc(8) のこれが適用されるなら，単に起動スクリプトを
リネームするだけでもいいのかも？

　　The following key points apply to old-style scripts in
　　/usr/local/etc/rc.d/:

　　o　 The scripts within each directory are executed in lexicographical
　　　　order. If a specific order is required, numbers may be used as a
　　　　prefix to the existing filenames, so for example 100.foo would be
　　　　executed before 200.bar; without the numeric prefixes the opposite
　　　　would be true.

**root▲▲ ★** · 2007/02/02(金) 23:41:03

なるほど、ZZZ- を 000- とかにすればいいと言ってますかね。
あるいは、/md の mount 部分だけを 000- で切り出すとか。

**動け動けウゴウゴ２ちゃんねる** · 2007/02/03(土) 21:03:29

¶　　　　　　¶＼
　　　　　　　　 ¶　　.＼¶¶¶..¶,/¶　ヽ
　　　　　　　　¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶､
　　　　　　　¶¶¶¶¶¶ｴﾙﾒｪｽ¶¶¶¶¶¶¶¶
　　　　　　¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶i
　　　　　　¶＜=○=＞＜=○=＞　 ¶i　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶＊　i　＜　 (ヘイッ！私のｷﾞｺｸﾝどこ？
　　　　　　 ¶:､¶¶¶ー□‐¶¶¶¶¶¶¶／　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　¶|¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶
　　　　　　　　　¶　¶¶¶¶¶¶¶¶¶¶¶¶¶ ¶¶¶¶¶ |ヽ
　　　　　　　　　¶　¶¶¶¶¶¶¶¶¶¶¶¶¶　　　¶¶丿 ¶
　　　　　　　　　¶　¶¶¶¶¶¶¶¶¶¶¶¶¶¶　　　　）_ノ
　　　　　　　　（.,.,.,.,..,）.,.,.,..,.,.,.（,..,.,.,.,..,.）,.,.,,../

¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶

　¶¶¶¶¶¶
　¶*ﾟーﾟ ¶　ヘイッ！私のｷﾞｺｸﾝどこ？　
　Ｕ　　Ｕ
　　く　く

¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶

このＡＡをみてから１０日以内にこれと同じ内容を１０回書き込まないと、
両腕をもがれて死にます。

虐厨はうそつきだと思ったみなさん。
すいません。
虐厨はうそつきではないのです。
しにたくないだけ、なんです。

**ひろゆき＠どうやら管理人 ★** · 2007/02/07(水) 15:50:30

落ち着いてる感じすかねぇ。

**動け動けウゴウゴ２ちゃんねる** · 2007/02/07(水) 15:51:46

落ち着いてるというか閑古鳥が鳴いてるというか

**動け動けウゴウゴ２ちゃんねる** · 2007/02/07(水) 18:37:19

ってか
どのくらいの利用者がいるのかしらん

**動け動けウゴウゴ２ちゃんねる** · 2007/02/07(水) 18:57:37

関連キーワードからスレを検索したりできないの？

**動け動けウゴウゴ２ちゃんねる** · 2007/02/07(水) 19:02:15

関連キーワードってＩＥとかでスレを見たときに上の方に表示されるキーワードのことでいいのかな？

専ブラ使いなので初めて知った・・・
使わせたいなら専ブラ作者に対応してもらった方が。

**動け動けウゴウゴ２ちゃんねる** · 2007/02/07(水) 19:05:25

専ﾌﾞﾗでｽﾚﾀｲ検索できるから別段不自由はしていないが
IEで使ってる人がどのくらい居るのかは気になる

AAにも反応するからｵﾚはIEからでもあんまり使ってないけど