Bulkfeeds の httpd が過負荷で接続できなくなる現象について、いろいろチューニングおこなってみたところ、原因が特定できました。
ずっと Namazu のインデクスをひくファイルシステムの問題か、mod_perl のチューニングだと思い込んでいたのですが、RSS の過去記事を格納しているテーブルの問題でした。アグリゲートしてきた記事をこのテーブルにつっこみつつ、Web からの検索ではこのテーブルを１回のクエリで20件分 SELECT するんですが、このテーブルのサイズが以前書いたように 2G を超えていて、ここでロックしているみたい。
アグリゲートにかかる時間が前よりかなり長くなっているのもこれが原因といえそうです。しかしテーブルを分けるわけにはいかないので、フロント側からひくときに裏に影響が出にくくなるようにキャッシュとかいれるしかないかな。。
１ゲトー
さておき
「しかしテーブルを分けるわけにはいかないので」
たしかOracleだと「物理的に分けつつ論理的には一つのテーブルに見える」ってのができたような。ビューと違って外部制約やインデックスも定義できる。違ったかな？
ともあれmiyagawaさんがDBパフォチューしてないわけもないのでもはやマシン性能の限界とみたｗ
MySQL だと「物理的に分けて論理的に1つのテーブル」はできないのですよ、というか出来るんだけどそれは 2G ファイルシステム制限回避にしか使えず、パフォーマンスの高速化にはつながらない（かった、ハズ）。
DB引く回数減らそうとファイルシステムにキャッシュいれてみたけどあんま変わらんなぁ。。もう限界かも。
Posted by: miyagawa on June 15, 2004 05:35 PM> Web からの検索ではこのテーブルを１回のクエリで20件分 SELECT するんですが
検索は Namazu じゃないんですか？
Robots → MySQL → (Namazu) ← End Users
みたいな構図だと思ってたんだけど。
Posted by: ceekz on June 15, 2004 05:54 PMいえ、namazu はラッパーを通して使っているので、namazu でいう URL=rssitem.id になっています。帰ってきた id を元にもう1回 rssitem テーブルを見て表示します。(id はPRIMARY KEY なので通常は問題ありませんけど）
Posted by: miyagawa on June 15, 2004 05:56 PMいえ、2GB というのは MySQL ではなくて OS で 2G 以上のファイルがつくれない場合の話です。なので関係ありません。
そして Bulkfeeds では InnoDB をつかっていません。