web-dev-qa-db-ja.com

LinuxディスクIOが過度の（> 1秒）アプリケーションストールを引き起こしているかどうかを確認する方法

Javaアプリケーションが大量（数百MB）の連続出力（プレーンテキストのストリーミング）を約12個のファイルに実行している ext3 SANファイルシステム。ときどき、このアプリケーションは一度に数秒間一時停止します。何かに関連しているのではないかと思います。 ext3 vsfs（Veritas Filesystem）機能（および/またはOSとの相互作用）が原因です。

この理論を確認または反論するためにどのような手順を踏むことができますか？出発点としてiostatと_/proc/diskstats_を知っています。

ジャーナリングを強調せず、「ストール」を強調するようにタイトルを改訂しました

私はいくつかのグーグルを行って、私が観察しているような振る舞いを説明しているように見える少なくとも1つの記事を見つけました： ext3レイテンシーの問題を解決する

追加情報

  • Red Hat Enterprise Linux Serverリリース5.3（Tikanga）
  • カーネル：_2.6.18-194.32.1.el5_
  • プライマリアプリケーションディスクはファイバチャネルSANです：_lspci | grep -i fibre_ >> 14:00.0 Fibre Channel: Emulex Corporation Saturn-X: LightPulse Fibre Channel Host Adapter (rev 03)
  • マウント情報：type vxfs (rw,tmplog,largefiles,mincache=tmpcache,ioerror=mwdisable) 0 0
  • _cat /sys/block/VxVM123456/queue/scheduler_ >> _noop anticipatory [deadline] cfq_
linuxperformanceredhatstorage-area-networkveritas
4
noahz

私の推測では、ディスクI/O容量をしばらく占有する他のプロセスがあると思います。 iotopは、最近十分なカーネルがある場合に、それを特定するのに役立ちます。

これが事実である場合、それはファイルシステムに関するものではなく、ジャーナリングに関するものではありません。競合するアプリケーション間の調停を担当するのはI/Oスケジューラです。簡単なテスト：現在のスケジューラーを確認して、別のスケジューラーを試してください。再起動せずに、その場で実行できます。たとえば、デスクトップで最初のディスクをチェックします（/dev/sda）：

cat /sys/block/sda/queue/scheduler
=>  noop deadline [cfq]

は、CFQを使用していることを示しています。これは、デスクトップには適していますが、サーバーにはあまり適していません。より良い設定 '期限'：

echo 'deadline' > /sys/block/sda/queue/scheduler
cat /sys/block/sda/queue/scheduler
=>  noop [deadline] cfq

数時間待って、改善するかどうかを確認します。その場合は、起動スクリプトで永続的に設定します（配布によって異なります）

4
Javier

簡単なテストの1つは、そのext3 fsをext2としてマウントしてから、アプリケーションのパフォーマンスをプロファイルすることです。

4
EEAA

答えは「はい」です（ジャーナリング[〜＃〜]常に[〜＃〜]追加レイテンシー:-)

それがどれほど重要であるかという質問は、実際には直接テストによってのみ答えることができますが、一般に、すべての（ジャーナリングされた）操作について、ジャーナリングが有効になっていない場合の約2倍の時間がかかると想定します。

別の回答 に関するコメントで、本番環境では直接テストを実行できない（おそらく、使用できる開発/テスト環境がない）と述べたので、もう1つあります。オプション：ディスク統計を調べて、ジャーナルデバイスへの書き込みに費やした時間を確認します。
残念ながら、これは、ジャーナルデバイスがディスクリートであり、「メイン」ディスクとは別に計測できる場合にのみ役立ちます。

今日は2回目にMcKusickビデオを接続しますが、 このビデオ ジャーナリングファイルシステムが実行する必要のある作業のいくつか（および関連するパフォーマンスへの影響）についての素晴らしい議論があります。
あなたやあなたの特定の質問に直接役立つ/関連するものではありませんが、ファイルシステムとジャーナリングに関する優れた一般的な背景です。

4
voretaq7

はい、ジャーナリングは待ち時間を引き起こします。しかし、それは方程式の小さな部分です。見るのは5番目か6番目の項目だと思います...しかし、これは、十分な関連情報が含まれていないシステムストレージの質問の傾向のもう1つです。

  • どのタイプのサーバーハードウェアを使用していますか？ （メーカーとモデル）
  • ストレージのセットアップ（RAIDコントローラー、キャッシュ構成、ディスクの数と配置）について説明してください
  • どのオペレーティングシステムを使用していますか？配布バージョンとカーネルバージョンが役立ちます。

なぜこの情報を求めるのですか？

ハードウェアのセットアップとRAIDレベルは、観察されるパフォーマンスに大きな影響を与える可能性があります。ハードウェアRAIDコントローラーの読み取りおよび書き込みキャッシュは、ワークロードとI/Oパターンに対応するように調整できます。オペレーティングシステムは、ツールの推奨事項とユーザーに役立つチューニング手法に影響を与えるため、重要です。ディストリビューションやカーネルが異なればデフォルト設定も異なるため、パフォーマンス特性はそれらの間で異なります。

したがって、この場合、いくつかの可能性があります。

  • RAIDアレイがワークロードに対応できない場合があります（スピンドルが不足しています）。
  • または、 書き込みキャッシュ の恩恵を受けることができます。
  • 断片化の問題がある可能性があります（ファイルシステムはどのくらいいっぱいですか？）。
  • 不適切なRAIDレベル は、必要なパフォーマンス特性に反する可能性があります。
  • RAIDコントローラーの調整が必要な場合があります。
  • システムのI/Oスケジューラを変更して、 一部のブロックデバイスチューニング を実行する必要がある場合があります。
  • [〜＃〜] xfs [〜＃〜] のようなパフォーマンスが最適化されたファイルシステムを検討できます。
  • ジャーナルを削除して、ファイルシステムをext2として再マウントできます。これはその場で行うことができます。
  • バスのタイムアウトが発生している可能性のある安価なSATAディスクがある可能性があります。

しかし、現状では、続行するのに十分な情報がありません。

4
ewwhite

/proc/diskstatsから/proc/meminfoに移動してみてください。おそらく、ライトバックバッファが大きくなり、フラッシュが必要になります。ライトバック（「ダーティ」）バッファが、書き込まれるよりも速く補充されるという状況がありました。その後、Linuxはより多くのフラッシュスレッドを開始し、事態を悪化させました。プロセスを一時停止する前にダーティバッファの許容比率を制限すると、問題がある程度解決しました。私が持っているもう1つのヒントは、相関関係です。I/ Oが遅い時間をキャプチャし、同時に他に何が起こったかを比較します。たとえば、これを試すことができます。

while sleep 2
do
    (date; cat /proc/meminfo) >> /tmp/your_logfile
done

そして、アプリケーションが遅いと思われるときを比較します。

2
U. Windl

私はext3ファイルシステムを使用するRedhat4でこの問題を抱えていました：ext3ファイルシステムでの多くの書き込み=> anoterext3での大きな待機FS write

アクセス時間の更新により、読み取りアクセスも一時停止できます=>回避策：mount -o noatime

よろしく、ジェロームD。

2
Jerome D