YNET Weblog

bg20 と bg30 の応答時間を計測したもの。

bg30 の安定した応答時間に対して bg20 は最大60.11秒という、とてつもない格差があった。

bg20 は深夜1時頃を過ぎると処理が落ち着き、その後アクセスが増えて転送量が増加している模様。
昼の12時頃から応答に時間が掛かるようになるのは、なにか別の処理でも走っているのだろうか？謎は深まるばかり。

bg20/bg30 では _service ディレクトリに負荷情報が存在しないので、実際に取得時間を計ろうという魂胆。
監視に使うのはグラフ化するのにはお馴染みとも言えるツール Munin で、プラグインをちゃっちゃと書いた。

取得時間は、動的ではないページの http://bg20.2ch.net/ の取得に掛かる時間を調べて記録し
bg30 では唯一動的ではなさそうな http://bg30.2ch.net/ を比較として記録する。

bg30 は他の掲示板サーバーと同様に22時頃にピークを迎えて緩やかに減っていく傾向に対して
bg20 では何故か朝5時頃に急激にアクセスが増えて朝6時頃に転送量のピークを迎えている。

唯一記録されている PV 情報でも、朝4時台のアクセスが272990PVなのに対して、5時台はいきなり383340PV
やはり朝の5時～6時はアクセス数が4～5万ほど多い。

ちなみに、この記事を書いている段階で bg30 の平均677msecに対して bg20 は平均9.05sec…。
これ大丈夫なのかなぁ。

例の一件で特定 Be のレスが来たら自動的にレスをする予約 Bot とかあったら面白いなぁと思った。

全然関係無いけど、クローラーに本文フィルターを入れて特定 Be の書き込みを追ってみる仕組みとか
実況キャプチャーを簡単に参照できる自分用のスクリプトでも作ってみようかな。

クローラーの出力先は、この前どさくさに紛れてメモリに載っけたので本文をブン回しても耐えられるはず。
負荷ついでに Munin では System が常に30%占有しているらしいんだけど、top で見ているとそんなことはなく
Munin が走る瞬間に30%に上がるだけという、貧弱 CPU による本末転倒現象が発生していた。

それと最近、リロードバーボンが厳しくなった影響なのか、bg20 のレスポンスが明らかに悪いような気がする。
昨年も一時期レスポンスが悪くなったけど、なんなんだろう？
親戚の bg30 の場合は c のバックエンドなので dat 取得には使えないし困った。

それはそうと _jungle が某所含め未だに閲覧可能なのは収穫だった。

以下の URL は削除しました。

http://blog.yuhisa.com/news/dat/1149078453.dat

http://blog.yuhisa.com/news/dat/1149165160.dat

MERGE テーブルの中で、いくつものMyISAMフィーチャーを利用する事はできません。

例えば、MERGE テーブル上でFULLTEXT インデックスを作成する事はできません。
もちろん、基礎となるMyISAM テーブル上に FULLTEXT インデックスを作成する事はできますが、
全文検索で MERGE テーブルを検索する事はできません

MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.6 MERGE ストレージエンジン

http://dev.mysql.com/doc/refman/5.1/ja/merge-storage-engine.html

そでしたか。

なんとか、 subject.txt から スレッドキーを取り出して、dat をダウンロードさせることに成功。
大きな進歩だ。

こんなんで良いのかな…？

気分が乗ってたので、新鯖 ( 新鯖か？ ) に DNS サーバーを立てました。
といっても、30分あればすぐ出来てしまうわけですが。

Apache と Toritonn ( MySQL ) は既に入れてあって、
テーブルも一応 10月分ぐらいまでは、マージしてあるはず。

登録件数は、2,731,083 件。データベースを構成するファイルの合計は 4.5GB。
現状でも、 API 叩けば、ちゃんとデータが表示されているので、特に問題はなさそう。
(まだ外部からは使えるようにしていないけど)

ただ、>>1 の本文と、スレタイを同じテーブルに入れちゃったせいで、
スレタイだけから検索したいときに遅くなるのが 失敗したなーと思った。

分割して、MERGE テーブル出来るようにしていればなぁ。

TCP/IP の入門書を読み始めて、何かを C言語化しようと愚策中。
いきなり目標を高くすると、すごい勢いで壁にぶつかって砕けるので、
あんなものや、こんなものを取ってくるものを作成。

debug.txt

というか、未だに C言語は未知の世界なんですが…。

[cc lang="c"]
#include

//スレッドの作成
pthread_create(pthread_t *thread, const pthread_arrt_t *attr,
void *(start_routine)(void *), void *arg);

//スレッドの待機
pthread_join(pthread_t thread, void **thread_return);
[/cc]

gcc を使う場合、「 -lpthread 」でリンクするべし

read.js では、スレッドのファイルサイズに対して 512 加算して表示しています。

前々から、この 512 は一体何なのだろう？と考えていたのですが、
今日、readc.cgi を修正するときに気がつきました。

ずばり、 kB 対策です。

スレッドの kB は、(ファイルサイズ + 512) / 1024 で計算され、
小数点以下は round で四捨五入されるのです。

このとき、スレッドのファイルサイズが 511 だと 1024 で割った際に
0.5 を切ってしまい、 0kB と表示されてしまうのです。
これを防ぐために、あらかじめ 512 を加算し計算しているのではないかと。

大したことではないのですが、何となくスッキリしました。

ということで、容量表示には 512 を加算しましょう運動開始。