関連キーワードをなんとかしようスレ
■ このスレッドは過去ログ倉庫に格納されています
read.cgiの片隅に表示されている関連キーワードを きちんとメンテナンスしてみようなスレッド。 思い出した 昔、あったな、社会とかのボタン 無くなったんだよな確か? 記憶力弱いんで違ってたらスマソ 3回目か ホリエモンの1クリック程度の価値有ったのだろうか? 意外と進歩してないモンだな 辞書をロカールに於いて、集めてきて賢くするだったかな? 英和、和英何てのも有った 思い出すことは出来ないだろうが >>222 のでもまだデッドロックが起きて...... >>221 の top の表示で余裕に見えたのは, 新規データは登録されるものの,再クロールでの更新データはデッドロックのため ほとんど登録されず CPU が休んでいたための模様w 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 も働き出した. 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 への切り替えはプラス側に転んだ,ということでいいのかな. おつでした。 しかし InnoDB の本来の力を発揮させるには、 プログラミング上の注意も必要、ということですか。 >>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 食うんでそんな有り余ってる訳じゃないし...... などと心配してたんですが,杞憂だったようでめでたしめでたし. 完走したニューススレの次スレ追跡に一応使える 本当はおすすめ2ちゃんねるのほうで対応して欲しいが さすがに 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) >>232 おー、さすが。 Inno は innovation なんでしたっけ。 >>233 まぁそんなところだと思います. 直接的には Innobase http://www.innodb.com/ から来てるんでしょうけど. 適切なリアクションが思いつかない自分を不甲斐なく思うよ きっと就活の面接に落ち続けてる俺に“足りない何か” を見つけるきっかけはここいら辺にあるんだと思う いの一番に反応したかったものの,お二方に先を越されますた. [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) httpd@p2 立ち上がってますね.乙です>むむむさん >>239-240 やりました。 何か、しかけを入れる方向ですね。 < httpd health check で、すごいバカな質問かもなんですが、 accept.lock って、そもそも作らないとまずいんでしたっけ。 >>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 生成で失敗しなくなる,とかいうことないんでしょうか? >>243 ふむふむ。 一般的なサーバは、fstab にしてもいいかもしれないですね。 /md の大きさや設定は各サーバの事情によって結構変えているので、 /etc/fstab にあまり書きたくなかった、という事情がありました。 あと、FreeBSD 5.x のバージョンアップの時に、 fstab に md の設定を書いていると mount でしくって、 single user mode になってしまう、というのもありますね。 毎回 /md の mount をしないようにしてから作業すればいいんですが、 それよりも、別にスクリプトを書こうと。 …というか、たぶんきっと rcorder をちゃんと書けばいいような予感。 >>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. なるほど、ZZZ- を 000- とかにすればいいと言ってますかね。 あるいは、/md の mount 部分だけを 000- で切り出すとか。 ¶ ¶\ ¶ .\¶¶¶..¶,/¶ ヽ ¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶、 ¶¶¶¶¶¶エルメェス¶¶¶¶¶¶¶¶ ¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶i ¶<=○=><=○=> ¶i / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶* i < (ヘイッ!私のギコクンどこ? ¶:、¶¶¶ー□‐¶¶¶¶¶¶¶/ \_____________________ ¶|¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶ ¶ ¶¶¶¶¶¶¶¶¶¶¶¶¶ ¶¶¶¶¶ |ヽ ¶ ¶¶¶¶¶¶¶¶¶¶¶¶¶ ¶¶丿 ¶ ¶ ¶¶¶¶¶¶¶¶¶¶¶¶¶¶ )_ノ (.,.,.,.,..,).,.,.,..,.,.,.(,..,.,.,.,..,.),.,.,,../ ¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶ ¶¶¶¶¶¶ ¶*゚ー゚ ¶ ヘイッ!私のギコクンどこ? U U く く ¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶¶ このAAをみてから10日以内にこれと同じ内容を10回書き込まないと、 両腕をもがれて死にます。 虐厨はうそつきだと思ったみなさん。 すいません。 虐厨はうそつきではないのです。 しにたくないだけ、なんです。 関連キーワードってIEとかでスレを見たときに上の方に表示されるキーワードのことでいいのかな? 専ブラ使いなので初めて知った・・・ 使わせたいなら専ブラ作者に対応してもらった方が。 専ブラでスレタイ検索できるから別段不自由はしていないが IEで使ってる人がどのくらい居るのかは気になる AAにも反応するからオレはIEからでもあんまり使ってないけど ex21鯖の復旧をお願いします。 >>ひろゆきさん。 >>254 あ。そだ<ひろゆき この関連キーワードを2chブラに広めたいんだって言ってたよな。 ソフ板に告知スレを立てればええやん。 2ゲト禁止ってか常にスレ上位にある告知みたいなのを。 >>261 若ハゲ?隠してやんよ 彡⌒ ヽ ( ;ω;)=つ≡つ∧_∧ (っ ≡つ=つ∧_∧ / ) ババババ ( / ̄∪ ひろゆきにポイントねだるとか・・・ クレクレ厨はちゃんとsakuして下さい >>261 わくわくされたのでやってみるわ。 こんなのをhttp://pc9.2ch.net/test/read.cgi/software/9242006211/ ソフ板に立てりゃ良いのだろ? ↓ ★☆ひろゆきから2chブラウザ作者さんへお願い☆★ ひろゆきが2chブラウザから関連キーワードを閲覧できるようにしてちょうだいって言ってるです。 http://qb5.2ch.net/test/read.cgi/operate/1166328527/186,192 186 名前:ひろゆき@どうやら管理人 ★[ ] 投稿日:2007/01/26(金) 04:05:53 ID:???0 ?S★(102442) getf.cgiの使い方を説明すればいいんですかね? 192 名前:ひろゆき@どうやら管理人 ★[] 投稿日:2007/01/26(金) 12:22:59 ID:???0 ?S★(102442) 専ブラ開発系のスレッドで告知すればいいんですかね? つー訳で2chブラウザ作者さんは関連キーワードを閲覧できるようにしてください。 2ちゃんねるwiki 関連キーワード(編集用ページ壬) http://info.2ch.net/wiki/pukiwiki.php?%CA%D4%BD%B8%CD%D1%A5%DA%A1%BC%A5%B8%BF%D1 ↑ あ、対応してるかどうか、導入方法を知らせないとダメか。 じゃ普通にスレ立てするぞ。 924スレじゃないと普通に沈んでいっちゃうね そしてage荒らし >>278 俺ができる精一杯w 落ちたら落ちたで鯔が924スレこさえるだろw 遊び場を提供してくれてるひろゆきに、感謝の意を込めて かるーいお手伝いw とりあえずbe2ch対応ブラウザスレに書いといたから ボチボチ反応あるんじゃね? キーワードをクリックすると、同じ関連キーワードが出てくるスレが表示されるのかと思ってた まあ無料でそんなことできたら、モリタポ使って本文検索する意味ないわな >>280 あなた頭良いな。 スレタイに関連キーワードが入っていても肝心の中身に無いかもだよなー。 同じキーワードのスレが検索できるのが理想ってか正しい方向だわなー。 ひろゆき>対応してください。 Janeの次スレ検索で使われてる奴ね。 wktkして待ちます。 ttp://japan.cnet.com/news/media/story/0,2000056023,20095741,00.htm たとえば、「ライブドアの検索」という文章ならば、形態素解析では「ライブドア」「の」「検索」と分割する。 英語では、単語と単語の間にスペースが入るので認識しやすいが、 日本語の場合は、単語の辞書ファイルを用意しなくてはならない。 これがN-gramの場合、Nを2文字単位と指定すれば、 「ライ」「イブ」「ブド」「ドア」「アの」「の検」「検索」と分割し、それぞれを単語として扱う。 強制的に分割するので、別途辞書ファイルを用意する必要がない。 そのため、一般的に認識する単語のデータ量は、形態素解析よりもN-gramのほうが多くなるので、 検索を高速に処理するのは不得手(Nを何文字にするかによっても大きく変わる)とされている。 しかし、別途辞書ファイルが必要ないため多言語でも通用するほか、 網羅性が高く検索の漏れがなくなりやすいとされている。 =−−−− ひろゆき> ひょっとして2chブラウザ内で検索できるようにお願いするん? 変なキーワードがあると思ったらAAに反応してたのか・・・ http://qb5.2ch.net/test/read.cgi/operate/1171194778/124 124 名前:ひろゆき@どうやら管理人 ★[] 投稿日:2007/02/13(火) 23:42:14 ID:???0 ?DIA(103001) >>12 すんません。サーバ落ちてました。 久々に鉄の掟関係なく笑った 鯖が落ちていたらひろゆきに自動連絡するシステムが開発される悪寒。 ぼくはできませんが。 手紙が届いていたらひろゆきに自動連絡するシステムが開発される悪寒。 (-人-)ひろゆきがチョコ食ってゲリ止まらなくなりますように。。 彼女が居たら家まで持ってくるだろ普通 あ 宛所不明な人だったね、そういえばw ひろゆきはうまい棒とチョコ、どっちが好きなんだ? チョコ味のうまい棒があればいいのか? >>314 すげーーーーーーーwwwwwwwwww クレカから振込みに変更したんですか・・・。 それで今度は振込みを忘れたと・・・。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.1 2024/04/28 Walang Kapalit ★ | Donguri System Team 5ちゃんねる