nfs が umount できなかった。kill できないプロセスができちゃった。
えー結論からすると nfs を使ってるときには以下の３点に注意。 1. nfs client 側で umount せずに nfs server が動いているマシンを停止させない。 2. 上記状態になってしまったときに df -k など mount された状態を前提としたコマンドを実行させない。 3. 実行してしまって STAT が D の状態になってしまったプロセスが生まれてしまったらリブートしか解決方法はない。 です。では、何故こんな状態になってしまったか、ポカミスについて備忘録として情報公開です。 まず一番の原因として nfs client の接続を切らずに nfs server が動いているサーバを停止しちゃいました。これが前日にやったこと。バッチ処理で df -k の実行が走りました。 この通りロードアベレージが急上昇しました。df -k によって本来 mount されている nf
あなたの作ったメール配信システムはエラーメール処理をしていますか？
今回はメルマガ等やメーリングリストのように大量のメールを配信するためのメール配信システムを自前で開発している方向けの情報（備忘録？）です。 大量のメールを配信する場合、配信できなかったエラーメールを適切に処理することが重要です。たとえば、 なんて感じです。適切なエラーメール処理なくば、知らず知らずのうちに SPAMer と同じようなメール配信をしていることになってしまうのです。かく言う僕の作ったメール配信システムも、それほどエラーメール処理を厳密に行っているわけではなく、何とかしないとなぁ〜と思っている今日この頃で、ちまちま資料を集め始めて仕様検討している次第です。
IO Accounting 機能で I/O 負荷の高いプロセスを特定
随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
