vmstat 1 などとして、定期的表示を実行させていると、まれに

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  0     99     42     25     62    0    0     0     0 2031   58  0 13 88  0
 2  1     99     14     21     61    0    0   219     0 2034  123  0 21 79  1
 1  0     99     37     20     61    0    0 4294967275     0 2016   53  0 20 78  2
 5  0     99     16     15     55    0    0   201     0 2042  133  0 34 65  1
 2  0    101     31     11     50    0    0     0     0 2039   82  0 39 60  1
 4  1    108      8      6     46    0    0   298     0 2123  273  0 42 57  1
3656  1    120    460      2     35    0    0   285  6976 2176  685  0 61 35  4
 0  0    102   4836      2     27    0    0     0   448 2038 3789  0 49 51  0
 0  0    102   4838      3     26    0    0     0    40 2032   71  0  0 99  1

のようにbi 欄がトンデモな値になることがある。
１秒前の値よりも小さな値が/proc/vmstatにて取得されるので、unsignd での減算が発狂してしまうのだ。
hackbenchとか流そうもんなら頻出。

んで、今日一日追ってみたのだけれど、原因がまったく分からず。
とほほ・・・

分かった事

・vmstat コマンドにアミを仕込んだ結果 /proc/vmstatの取得結果が前回よりも減る事があるのが
　確認できた。
つまり、vmstatコマンドのバグではない
・カーネルにアミを仕込んだ結果、カーネル内でカウンタを減算する処理は一切走っていない事が分かった
・んじゃ、メモリオーダかなと他人のCPUのcpu varを読む処理を全部削除（てか、こんなんある時点で現在のコードはあきらかに間違ってる気がするんだけど・・・）しても結果は変わらず

むかついたので、もう寝るザマスよーー


追記：　原因判明。
　　　　　2.6.25-mm1は/proc/vmstatが壊れており、カラムが途中から全部１行ずれとる。
　　　　　よって、pgpgin に表示されているのはNUMAヒット率なので、減ってしまっても
おかしくないという。。。。
　　　　　バカか！

　　　　　教訓：　人間ソースコードがおかしいとすぐ気づくが文字列の配列が途中で一行抜けていてもなかなか気づかない。
　　　　　教訓２：　人間、偏見をもってみると全然関係ない統計値でも、すこしも疑問に思わずだまされる。

関連記事

• BKL as semaphore (2008/05/08)
• vmstatのバグが直せない。。 (2008/05/05)
• split lru seriesのコードフリーズできました (2008/05/03)