☰

サーバーの再起動時にディスク I/O が増加

tag-icon • tag-icon hard-drive io
サーバーの再起動時にディスク I/O が増加

CentOS 5.8 マシンは起動時にディスク I/O が高くなります。ディスク I/O を消費するプロセスは、kmirrord、kjournald、pdflush です。次の操作を実行しました。

1) noatime パラメータを使用してファイルシステムをマウントしました。2) Linux カーネル バージョン < 2.6.20 であるため、iotop はレポートしません。block_dump を有効にしましたが、kmirrord、kjournald、pdflush がディスクに対して大量の読み取り/書き込みを行っていることが示されています。

ディスク使用率が高くなると、サーバーの負荷も増加します。この状態はしばらく (約 30 分) 続き、その後システムは正常に戻ります。

他に確認できることはありますか?

答え1

iotop で確認してください。CentOS/RHEL 5.8 でも問題なく動作します。こちらをご覧ください。

これは再起動するたびに発生しますか? ウォームブートですか?

このサーバーは物理ハードウェア上にありますか? VPS ですか? 仮想マシンですか?

これはどのくらい前から問題になっているのですか?

答え2

CentOS 5.8 はかなり古くなっています。現在のバージョンは 5.10 です。

現在の 5.10 の lvm2 のバージョン履歴を調べてみました。

  • 2013年6月26日水曜日 ピーター・ラジノハ - 2.02.88-12

  • multipath_component_detection=1 の場合は、mpath コンポーネント上のパーティションもフィルタリングします。

  • 2013年5月22日 ピーター・ラジノハ - 2.02.88-11

  • カーネルのサポートがない場合、lvconvert でのスナップショットのマージの初期化を拒否します。
  • ミラーアップコンバートの失敗後に手動クリーンアップが必要であるという警告を削除します。
  • vgimport '--force' を使用すると、PV が欠落している VG をインポートできるようになりました。
  • 二重障害が発生した場合、ミラーリングされたログはミラーリングの前に修正されるようになりました。
  • --mirrors および --repair のみで lvconvert --stripes/stripesize を許可します。

  • -My オプションを使用する場合、major:minor の制限を 4095:1048575 に増やします。

  • 2012年8月28日 ピーター・ラジノハ - 2.02.88-10

  • lvm.8 の割り当てポリシーのドキュメントを改善します。

  • 2012年7月26日 ピーター・ラジノハ - 2.02.88-9

  • 連続ポリシーで既に検出された PV に固執するように alloc cling を修正しました。
  • 以前の LV セグメントがない場合に cling ポリシーが通常のポリシーのように動作しないように修正しました。
  • --alloc がタグなしで cling するときに、後のポリシーを使用しないように割り当てループを修正します。

  • 内部の A_CONTIGUOUS および A_CLING フラグの名前に _TO_LVSEG を追加します。解決: #821013

  • 2012年5月25日（金）ミラノブロス - 2.02.88-8

  • pv_min_size が 512KB から 2MB の範囲に設定されている場合、警告を出力しません。

  • vgcfgrestore 中に PE カウントがゼロの PV が使用される場合のゼロ除算を修正しました。解決: #786009 #820237

  • 2012年1月20日（金）ミラノ・ブロス - 2.02.88-7

  • 変換時にクラスター ミラーの排他的アクティブ化を維持します。解決: #702065

  • 2012年1月18日 ミラノ ブロス - 2.02.88-6

  • lvm1 形式のスナップショット処理を修正しました。

  • メモリ ロック エラー メッセージをわかりやすくします。解決: #758833 #769053

  • 2011年12月1日 ミラノブロス - 2.02.88-5

  • ミラー ログの変換とミラー ログの vgsplit を修正します。
  • dmeventd 自動スナップショット拡張機能を修正。解決: #754598 #75576​​2 #754198

したがって、ここでは既知のバグに遭遇する可能性があります。

関連情報