ただのにっき

■ Gauche 0.7.1 (2)

夕べの話。

せっかくshiroさんから教えていただいたので、install-pkgを試す。最初、rootで作業しなかったせいか(?)失敗してしまったのだが、じたばたしたらなんとか通る。なんか、できたファイル一式にはmanやinfoが含まれていないような? まぁいいか、実行には関係ないし(追記: install-docを使うのだ)。

で、ターゲットマシンに送って実行:

% gosh
zsh: illegal hardware instruction  gosh

なんか変わったことを言われてしまった……。これってもしかして、ビルドマシン(PentiumIII)とターゲットマシン(VIA C3)が違うってこと!? つまりconfigureから変えてやり直せと?

と、ここで時間切れ。続きはちゃんとrpmのSPECを読んでからにしよう……つーか、RPM作ればいいんじゃないの? >おれ

■ SPC17: 激重対策(3)

suzuneとメンテナンスの相談をしていたら、「重くなったのはApacheの設定をいじってMaxClientsを減らしたあとではないか」との指摘を受ける。

いやいや、あれは実に効果があって、あのあとCPU loadが減ってレスポンスが向上したのだよ。……と思ったが、その後、負荷状況をみながら徐々に減らしたりしていることも思い出す。現在のMaxClientsは15。Apacheのデフォルトセッティングの1/10だ。もしこの数字を超えるリクエストが一度にあった場合、待ち行列が発生する。で、tDiary.Netの増え続けるトラフィックの影響で、その行列がいつまでも解消せずに増え続けたら、いま直面しているような状況が発生したりしないか?(←このあたり、よくわかっていない)

そこで、試しにMaxClientsを50まで上げてみる(18:30)。やるときは効果がはっきりわかるようにガッと上げるべし。するとCPU load av.は5前後から一気に30(!)まで上がったりしたものの、Webのレスポンスは明らかに上がった。MRTGを見ていても、トラフィックは高い位置を保っている。Apacheのプロセス数は30前後で増えたり減ったりしているので、50という値は余裕がある状況。うへぇ、まさかこれがアタリか?

もっとも、この改善は一時の気の迷い(?)かも知れないので、しばらく様子を見つつ、値を調整してみるつもりである。で、もしこれが犯人だとすると、次に現れるボトルネックはCPU、ってことになるんだけど……。

＃つーかすでにボトルネックだが。loadが常時5前後あるってどうよ。

■ SPC17: 激重対策(4)

% uptime
10:54pm  up 329 days,  5:16,  2 users,  load average: 26.34, 29.46, 25.27

まぁ、MaxClientsを増やせば当然こういうことになるのは予想していたのだが。なんにせよ、昨日の同じ時間とは違う理由で重いというのは重要である。CPUが足らないなら、CPUを増やせばいいのだ。

……というわけで、第三、第四の設置を(以下略)。

■ Sylpheed 0.9.4

IMAP4 フォルダの内容を常にサーバと同期させるようにした。

きたきた! これを待ってたんだ〜。これで、WindowsのBecky!から読んだあとにSylpheedで読んでも未読管理がおかしくならないぞ。……といいつつ近間パッケージを待つおれ。

■ bsfilter

相変わらず、spamをcleanと認識する率が減らない。だいたい1割かそれ以上がclean扱いされてしまう。まぁ、それでも逆パターンがゼロになったのでずいぶん楽になったんだけど。

これって、地道に学習させてればじきに収束するもんだろうか?

■ KDE不調

一昨日の晩、近間パッケージ(←個人的な呼称^^;)をひさしぶりにmph-get upgradeしたんだけど、そのせいか、夕べからKDEで日本語が出なくなってしまった。KDEはデスクトップ環境として使っているだけで、KDE由来のアプリはまったく使っていないため(ぉぃ)、実作業にはほとんど支障がないんだけど、タイトルバーやタスクリストが見えないっつーのは不都合があるな。

で、フォント周りの設定をリセットして(それまではコントロールパネルすら満足に表示されず)、調べてみたら、東風フォントが(存在するにもかかわらず)何も表示されていない、とわかった。なんで???

■ SPC17: 激重対策(2)

さっぱりわからんので、試しにrebootしてみようかと思う。現在のuptimeは327 days。あと一息なんだが(なにがだ)。

とはいえ、rebootするには念のため現地要員(イコールsuzune)との連携が必要なのであった。あとでsuzuneにメールすること。と、ここにメモ。かんりょう。

■ 今年の「システム管理者感謝デー」はなんと土曜日

スケジュールをチェックしていたらなんと、今年の感謝デーは会社が休みの土曜日であることを知る。ひどい。これでは感謝してもらえないじゃないか。

参考: http://www.itmedia.co.jp/news/0207/24/ne00_geek.html

■ Gauche 0.7.1

メモ。

そういえばGauche、「make install」でもgcc(?)が必要なので、開発環境を入れてないマシンではインストールができないので困っている。こういうのはどうしたらいいんだろう。

■ pcspecs:SPC17: 激重対策

tDiary.Net、tDiary.org、spc.gr.jpが入っているサーバ(SPC#17)が非常に重いのはADSLの回線品質のせいだとばかり思っていたのだが、昨日のツッコミで同一セグメント上の別ホストは問題がないらしいと知らされて愕然としているところ。てことは、少なくともHUBのこっち側の問題ってことかい。

現在の事象はこんな感じ:

1. リクエスト多い時間帯にトラフィックが急速に落ちることがある(常時ではない)
2. 落ち込みの開始は毎正時に始まることが多い
3. 30分くらいである程度回復する(昨日は11時間回復しなかったが)
4. その間、CPU loadはそれほど上がらない

このこと(特に2番目)から、問題は外のネットワークで何かが起きていて、その影響を受けているのではないかと予想していたわけだ。

しかしそうではないようだと。ディスクエラーは起きていないので、正常時により多くのリクエストをさばいているCPUやディスクがネックになっているとは考えにくい。となると、問題があるのは

1. 同一セグメント上のホストが共用しているHUB
2. SPC#17←→HUB間のケーブル
3. SPC#17のNIC(現在はDECコンパチチップ、turipドライバ)
4. ネットワークドライバ?

のいずれかという感じか。

上の2つはsuzuneに頼めるなぁ。なんかやってみない? >suzune

参考: ipconfig eth0の結果

eth0      Link encap:Ethernet  HWaddr 00:00:F4:5A:8E:9A
          inet addr:202.224.217.246  Bcast:202.224.217.247  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:690007117 errors:1 dropped:0 overruns:0 frame:0
          TX packets:881858821 errors:3 dropped:0 overruns:0 carrier:3
          collisions:0 txqueuelen:100
          RX bytes:249051160 (237.5 Mb)  TX bytes:4050180650 (3862.5 Mb)
          Interrupt:18 Base address:0xa000

まぁ、少しエラーが出てるけど、問題になるほど?

■ 本日の感動二題

• 宇宙戦艦ヤマト。Intelまで日本のアニメをパクっていたとは……。
• 昼のblog、夜のblog。うまいことを言う。

■ なんでも継続

メモ。call/ccだけは(「call/ccも」だな……)さっぱり理解できないので、これを読んで理解を深める予定。多少は深まるだろうが、理解できるかどうかは不明。