- - PR -
ディスクI/Oがだんだん遅くなる件
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2007-12-12 11:41
お世話になります。
redhat Linux AS3 update6＋Oracle10gを使用して運用しています。 サーバはF社TX600 Raid1で構築しています。 毎晩，ディスクI/Oの多いバッチが動きます。バッチ終了時間の誤差は-5分〜+5分位なんですが，リーブート直後は前日の処理時間より40〜50分位早く終了します。3日後位からだんだん処理時間が遅くなり(+10分)，リーブートから5日後位で処理時間が落ち着きます。 リブート前に800Mのファイルをcpした時の時間は約4分，リブート直後は約1分50秒でした。 Raidコントローラー・ハードディスクの状態を確認しましたが，異常ありませんでした。(F社ハードサポート回答) 勿論，F社のLinuxサポートにも投げていますが，今だ明確な回答は得られていません。 調査・解決方法等ありましたら，ご教授お願いします。 | ||||
|
投稿日時: 2007-12-12 11:52
メモリの状態が違うので処理にかかる時間も違うのではないでしょうか？
詳しく原因追求したいということでしたらsarや他の関連するコンポーネントをモニタ する機能を利用してネックになっているものを探すのも手です。 | ||||
|
投稿日時: 2007-12-12 12:51
progmanさんが言われているように、メモリの状態によっては処理が遅くなる事も あると思います。 Oracleを載せているようですが、Oracle等のデータベースは最大で何メモリ使用するか を設定できますが、最初から指定したメモリをフルで使用する訳ではありません。 その為時間の経過と共にメモリ使用量が増大、メモリの空き容量が減る事となります。 現時点でトラブルとなっているのであれば、マシンのリブートを毎日行うか、Oracleに 割り当てるメモリ使用量を減らす方向で検討されると良いかもしれません。 （Oracleはリブートしなくてもキャッシュのクリアコマンドがあったような・・・） 一つ失念していましたが、Oracle10gのファイル管理がRAWデバイスの場合は、特に 使用した事が無い為分かりません。 | ||||
|
投稿日時: 2007-12-12 14:10
progman様，上総様ご回答ありがとうございます。
progman様 F社サポートの依頼で800Mのファイルをコピーした際に，top,sar，strace，iostat，vmstatでログを取りました。サポートに投げたままなので，自分でも各ログの見方を勉強します。 上総様 OracleはRAWデバイスは使用していません。Oracleの設定も処理時間に影響があると思いますが，私が気になったのが800Mのファイルをコピーした時の処理時間の差です。この時間差が処理時間に影響しているのではないかと考えてます。 このサーバは夜間(午前0時から)バッチのみで使用しています。ファイルコピーは二度共に日中に行ったので，バックグラウンドで負荷の掛かる処理は動いてません。コピーの時間差は誤差の範囲なんでしょうか？ | ||||
|
投稿日時: 2007-12-12 14:34
ファイルコピーがネットワーク間のものかにもよると思いますが、ファイルコピーも メモリを使用する以上はその時点で空いているメモリ量によって変わると思います。 で、ファイルコピーを行う際にどれ位のメモリが空いているかといった観点から、 Oracleのメモリが解放されていないのではといった流れでの発言です。 もちろんバックグラウンドで処理が動いていれば、つられて処理が遅くなる事はあり ますが、それ以外も観点に入れないと問題が解決しないケースもあります。 念のため、再起動直後のタイミングと処理が遅くなったかなと思った段階で、free コマンドでメモリの状態を監視されると良いかと思います。 ちなみに空きメモリが少ないとSwapが頻繁に発生し、ディスクI/Oに影響を与える事が あります。 Linux のメモリー管理(メモリ−が足りない？,メモリーリークの検出/防止) （http://www.math.kobe-u.ac.jp/~kodama/tips-free-memory.html） | ||||
|
投稿日時: 2007-12-12 14:50
こんにちは。
性能問題って一発で解決しないケースが多いので ログなど採って論理的に突き詰めていくことになると思います。 さしあたって、現象が起きた後と、おきる前の環境を比較する方法が いいのではないでしょうか。 sarなりtopなりで（Fサポートが示した情報採取でまずは十分です） 定期的にシェルか何かでくるくる回してログを採ってくといいでしょう。 メモリの空きの推移やIOの推移が見られるはずです。 単純にバッチ中の間とそれ以外でもいいでしょうけど どうせ採るなら傾向をつかめるような仕掛けの方がいいと思います。 今回の現象とはたぶん関係ないと思いますが 全体的にディスクIOが遅いならフラッシュのタイミングや filesystemのブロックサイズなんかも見直し対象ですかね。 以上、ご参考までに。 | ||||
|
投稿日時: 2007-12-12 15:53
ＲＡＷデバイスでなくファイルシステム上のファイルへのアクセスは
カーネル内に一度キャッシュされるので、その時点のメモリの状態に大きな影響を 受けます。 遅い時は空いたエリアがなく、その時点で実メモリ上にあるイメージがスワップアウト されるといった処理がともなっているはずです。 | ||||
|
投稿日時: 2007-12-12 22:26
>全体的にディスクIOが遅いならフラッシュのタイミングや
すみません。 これは良く分からなかったのですが、何のフラッシュの ことでしょうか？ 採取情報の種類としては、サポートに投げているもので第一 切り分けに十分だと思いますが、起動直後と遅延の発生して いる時間帯でそれぞれ情報を採取していますでしょうか？ それぞれ採取しているのであれば、比較するのが一番簡単だと 思います。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。