2日前からサーバのロードアベレージが，毎朝4時にグンと上がってそのまま下がらない．サイトは快調に動いている．メモリもCPUも普段通り（普段からおかしいことはおいといて）．サーバ管理者は他にいるし実害はないので放置していた（ひどいやつだ）
2日経ってさすがに気持ち悪くて調査をしてみると，psのSTATがDNで終わらないプロセスが複数存在していた
root 11975 0.0 0.0 1616 632 ? DN Sep10 0:15 /usr/bin/updatedb -f NFS,SMBFS,NCPFS,PROC,DEVPTS -e /tmp,/var/tmp,/usr/tmp,/afs,/net
もともと，時間が時間だけにcron.daily絡みだと目星をつけていた．ただ油断していけないのはこの時間にわざわざ設定したcronがあることだ．このあたりのcronによる負荷が大きすぎてサーバが止まることもある．現在処理をする時間の移動を検討中だが処理の書き方（内容ではなく）が複雑すぎてメドがつかない
***それはさておき***
psのSTATにDがあるというのは，man psで見ると判るけど「割り込み不可能なスリープ状態」ということらしい．Nがあって優先度は低いので実際の負荷にはならないけれど，待ちが発生しているわけで関連プロセスの数だけロードアベレージが上がると言うことでしょう
プロセスの状態コード
D 割り込み不可能なスリープ状態 (通常 IO 中)
R 実行可能状態 (実行キューにある)
S スリープ状態
T トレース中または停止中
Z 消滅した (ゾンビ) プロセス
BSD 形式で "stat" キーワードが用いられたときは、以下の添付文字が表示 さ
れることがある。
W 実メモリのページを使っていない
< 優先度の高いプロセス
N 優先度の低いプロセス
L 実メモリのページをロックして利
用している (リアルタイム処理や
カスタム IO 向け)実際まったく同様の状況になったひとがいるみたい（→http://his.luky.org/ML/linux-users.a/msg06402.html）です．kill -9でもきえません．この状況だと何をしても消えないみたいですねー
このcronはslocateコマンドのdbを作成するためのもののようです．ひとまずだれもslocateコマンドは使わないようで，cronは停止してもらいました
そもそもの原因は，先週ぐらいにファイル移動のために一時的にnfsを起動したことみたいです．うまく終わることができてなかったのかなぁ．lsコマンドなどでマウントしていた/mntあたりにアクセスするとそのコマンドもSTATがDになって死亡します．nfsコワイ
このプロセス消すには再起動しかないみたいなんですけど，サーバ管理者曰く「このサーバ再起動するの怖い」だそうで．計画立てて再起動です．冗長性が全くないシステムは怖いですね．いっそこのまま停止すればいいのに
