Kerosoft : Modus Operandi

このModus Operandiがお世話になっているadiaryというBlog Systemはカウンタ機能を標準で持っていないので、3か月前くらいに自分で作ったのだが、たまたま友人から「ページビューが1増えたり2増えたりしてるぞ？」と報告をもらって色々調べてみた。


仕様としては、自分でPerl Moduleを一個作って/lib/Satsuki/に入れ、diary.user.skel/_sidebar.htmlのSystem Infoのとこにloadpmと値参照を加えるだけ。

とまぁ、そこまではいいのだが、やっぱりページビューを測るとなんかおかしい。
最初は自分の書き方が悪いのかと思ったのだが、どう考えてもforやwhileなどの繰り替えしを通らない部分に、カウント値の1upのコードを書いているので、おかしい……と悩んだ挙句、_sidebar.htmlが複数回呼ばれることがあるという結論に至った。

adiaryの中身をあまり詳しく見たわけではないのでよく分からないけど、1回しか呼ばれない場合と、2回呼ばれる場合がある模様。

そもそもカウンタはimgタグで対応してくれというのが作者の思惑なのかはわからないけど、とりあえずテキストカウンタにこだわりたいので現状のスタイルを保持して正しくカウントするには……と考え、PageViewの方はtime関数の戻り値が1以上ずれない限りカウントアップしないようにすることで対応した。
（ほんとは$$とかで対応しようかと思ったけど、speedy_backendが立ち上がりっぱなしなので、この手が使えない）

というわけで、同一時刻に複数からアクセスしても逆に1増えない、という状況になってしまったが、致し方ない。
細かい統計はGoogle Analyticsで見るか……。

原因が分かった 9:19

開発者のnabe様から的確なコメントをいただき、一発で原因が分かりました。ありがとうございます。
どうやらブラウザが勝手に読みに行くfavicon.icoや存在しないRSSファイルを憶測で読みに行く時の404 Not Found画面でカウントアップしている感じでした。

<@ifexec(v.load_days, begin)>
<$c=loadpm("SimpleCounter")>
<@c.counter>
<$end>

404の"記事がありません"のメッセージ文を参考に、上記のように書き換えたことで、意図する動作になったかな。

今日は雷のせいで、よくサーバーへのアクセスが切れる。
というのも、サーバー側のFTTHモデムが瞬停に耐えられず再起動し、IPアドレスが変わってしまうからだ。まぁこれはしょうがない。

上位DNSまでのDNS浸透は速いものの、やっぱり末端に広がるには時間がかかるようなので、とりあえずhostsファイルに書いてやったり*1で対応するのはいいとして、GNUのscreenがattached状態になったままで再アタッチできない事がたまにある。
いつも、気がついたらdetachedになってるんだが。

ちなみに、autodetachはonである。

[kero@spinel](2)$ screen -ls
There is a screen on:
        26323.pts-0.spinel      (Multi, attached)
1 Socket in /var/run/screen/S-kero.

となったので、しょうがない、リモートデタッチするかと。

[kero@spinel](3)$ screen -d
[26323.pts-0.spinel detached.]

が。

[kero@spinel](4)$ screen -ls
There is a screen on:
        26323.pts-0.spinel      (Multi, attached)
1 Socket in /var/run/screen/S-kero.

何度やってもscreen -dはdetachedと出るばかりで直らん。

[kero@spinel](9)$ screen -r
There is a screen on:
        26323.pts-0.spinel      (Multi, attached)
There is no screen to be resumed.

resumeもできん。

[kero@spinel](10)$ screen -D

[kero@spinel](11)$ screen -D

• Dにしたら今度は反応が返ってこない。Ctrl+Cが効くだけマシかもしれんが……。

と、この記事を書いている間に

[kero@spinel](12)$ screen -ls
There is a screen on:
        26323.pts-0.spinel      (Multi, detached)
1 Socket in /var/run/screen/S-kero.

となっていた。

あれか、焦って再アタッチせずに、ゆっくりしてきてね！！！ってことですね、きっと。
→解決編をご覧ください。

追記: 最後に打ったコマンドをウィンドウタイトルに 16:39

検索してたらこちらで見つけた。
.screenrcに

shelltitle "$ |bash"

と付け足して、.bashrcを

OLD_PS1=...（元の設定）...
SCREEN_TITLE='\[\033k\033\\\]';
PS1="${SCREEN_TITLE}${OLD_PS1}"

てな具合。OLD_PS1の部分は無論、埋め込みでも構わない。
zsh使いの場合は、↑サイトを参考に。

このblogもそうだが、adiaryをサーバーに導入して、この公開blogと非公開blogを2つ運営している。
ごらんのとおり、このModus Operandiが公開blogである。
色々とadiary.conf.cgiの設定も違うから、ファイルを別個に分けてあるのだけど、どーも、moのほうだけ開くのが遅い。遅い。遅い。
特にひどいのは記事をSubmitするときとか、管理メニューを開くとき。10秒くらい待たされることが多々。これはひどい。


何でだろうと思って、ターミナルを開くとこれまた重い。
Load Averageが5とか10とかになってやんの。どおりで重いわけだ……。

topをかけてみると、こんな感じ。*1

top - 00:51:48 up 88 days,  8:29,  1 user,  load average: 3.06, 2.15, 1.80
Tasks: 218 total,   5 running, 213 sleeping,   0 stopped,   0 zombie
Cpu(s): 98.5%us,  1.5%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    515212k total,   349296k used,   165916k free,     8944k buffers
Swap:   787176k total,   388272k used,   398904k free,    58780k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
18019 apache    20   0 30468  24m 2816 R 25.8  4.9   0:29.53 speedy_backend
17995 apache    20   0 29632  23m 2816 R 25.3  4.8   0:25.77 speedy_backend
18047 apache    20   0 28812  23m 2816 R 25.3  4.6   0:18.32 speedy_backend
17982 apache    20   0 28952  23m 2816 S 13.6  4.6   0:20.50 speedy_backend
18179 apache    20   0 25420  19m 2780 R  7.3  3.9   0:03.92 speedy_backend
 8566 apache    20   0  3912 1448 1444 S  0.0  0.3   0:00.01 speedy_backend
 8567 apache    20   0 25904 7580 2936 S  0.0  1.5   0:13.11 speedy_backend
16712 apache    20   0 26096 5728 2180 S  0.0  1.1   0:00.18 httpd
16719 apache    20   0 26100 5708 2176 S  0.0  1.1   0:00.13 httpd
17282 apache    20   0  3912 1832 1456 S  0.0  0.4   0:00.02 speedy_backend
17356 apache    20   0 26120 6804 3204 S  0.0  1.3   0:00.12 httpd
17647 apache    20   0 28352 9236 3216 S  0.0  1.8   0:00.66 httpd
18055 apache    20   0 26120 6784 3204 S  0.0  1.3   0:00.02 httpd
18155 apache    20   0  3640  800  652 S  0.0  0.2   0:00.00 adiary.speedy.c
18158 apache    20   0  3640  804  656 S  0.0  0.2   0:00.00 adiary.speedy.c
18159 apache    20   0  3640  808  656 S  0.0  0.2   0:00.00 adiary.speedy.c
18160 apache    20   0  3640  808  656 S  0.0  0.2   0:00.00 adiary.speedy.c
18161 apache    20   0  3640  796  652 S  0.0  0.2   0:00.00 adiary.speedy.c
18162 apache    20   0  3640  808  656 S  0.0  0.2   0:00.00 adiary.speedy.c
18163 apache    20   0  3640  808  656 S  0.0  0.2   0:00.00 adiary.speedy.c
18164 apache    20   0 26096 5076 1552 S  0.0  1.0   0:00.01 httpd
18171 apache    20   0  3640  792  652 S  0.0  0.2   0:00.00 adiary.speedy.c
18177 apache    20   0  3640  800  652 S  0.0  0.2   0:00.00 adiary.speedy.c
18178 apache    20   0  3640  796  652 S  0.0  0.2   0:00.00 adiary.speedy.c
18185 apache    20   0  3640  796  652 S  0.0  0.2   0:00.00 adiary.speedy.c
19629 apache    20   0 28716 7916 4552 S  0.0  1.5   0:05.22 httpd
19695 apache    20   0 28392 9724 4648 S  0.0  1.9   0:06.15 httpd
19726 apache    20   0 27052 7948 4444 S  0.0  1.5   0:03.95 httpd
19731 apache    20   0 28716 9468 4424 S  0.0  1.8   0:05.44 httpd
19744 apache    20   0 27940 9.9m 4720 S  0.0  2.0   0:04.48 httpd
19754 apache    20   0 27556 9748 4720 S  0.0  1.9   0:04.38 httpd
19760 apache    20   0 28376 9.8m 4608 S  0.0  2.0   0:06.34 httpd
19787 apache    20   0 27836 9.9m 4652 S  0.0  2.0   0:04.68 httpd
19813 apache    20   0 28696 9372 4296 S  0.0  1.8   0:05.04 httpd
22168 apache    20   0 28144 9284 4480 S  0.0  1.8   0:11.31 httpd
22170 apache    20   0 28136 8912 4624 S  0.0  1.7   0:08.38 httpd
22173 apache    20   0 27276 9036 4352 S  0.0  1.8   0:10.07 httpd
22175 apache    20   0 28720 8184 4648 S  0.0  1.6   0:14.24 httpd
26275 apache    20   0 28128 8724 4004 S  0.0  1.7   0:09.27 httpd
31115 apache    20   0 28708 9660 4476 S  0.0  1.9   0:09.31 httpd

apacheさんが大量にspeedyを起動しちゃって、backendが追いついていない感じ。
backendがアホみたいにCPUを食いつぶしているのが原因だろうと思って、一時的にspeedyの呼び出し引数に"-- -M5 -r10 -t3600"とか付けてみたんだけど、全然状況変わらず。


一方、非公開blogの方では同一バージョンを使用しているのに、全く
こういうことがない。speedyは常時2個くらい起動しっぱなしで、これ以上増えない。動作も快適。
が、moの方はリンクをクリックした拍子とかに10個も20個もバババーっと増えるのである。しばらくすると消える。

単にアクセス数の問題か……？否か……。
記事数ならば非公開blogの方がmoの10倍弱はある。


ちょっと時間ができたら双方を詳しく比べてこの問題を解決したいところである。今は時間がない。

うちのメインマシン(OSはWindows XP Professional x64)でよく強制リセットが起こる。
頻度は1週間に1回くらい？
ニコニコで動画再生を終えた直後とか、Media Player Classicである曲の再生を終えた直後とか、VSを操作したときとか、発生箇所は様々。

つまり、全く原因がわからない。

イベントビューアではこの通り。

種類: エラー
分類: System Error (102)
イベントID: 1003

エラーコード: 000000000000003b
パラメータ1: 00000000c0000005
パラメータ2: fffff8000127e1ce
パラメータ3: fffffadf5106ffe0
パラメータ4: 0000000000000000

0x3bでググってみたけど、ドライバを更新したら？くらいの情報しか見当たらなかったので、ダメ元でMicrosoft Updateを実行。

で、前々から出てたLANカードのドライバを入れてみる。

この更新プログラムのインストールをお勧めします。コンピュータ上にある、このドライバの適用先のデバイスが無効になっていると考えられます。

とか訳わからんメッセージが出てるけど（実際はちゃんと動作してる。けどLANポートには何も刺さってない）、とりあえず導入してみた。
これで改善されるだろうか？

相変わらず落ちる 2008/07/29

今回も0x3b。
LANドライバは関係ないようです。

（※重要な更新プログラムが非表示になってるのは、IE7を入れたくないからです…。これは本質とは関係ない。）

なぜ削った…この機能……。
特定の日時の更新状況を後から参照できて便利だったのに。

docxのフォーマットの制約で、複数のドキュメント版を管理できないということなら、ひどい話だ。

版の管理機能について - Word - Microsoft Office Online


しょうがないので、「変更履歴の記録」で対処しようか。
とりあえず「初版」と「最終版」の2つは管理できるようだし。