- - PR -
ディスクI/Oがだんだん遅くなる件
«前のページへ
1|2|3
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2007-12-17 11:58
スレッドを拝見していての、思ったところをかきます。
1. Oracle 10g のオプティマイザの設定は大丈夫ですか? 10g は、コストベースのオプティマイザしかありませんので、オンラインでも使っているデータベースでは、バッチ処理の性能が低下する傾向にあります。バッチ処理中は、オプティマイザの統計情報を利用しないなどの方法が考えられます。とくにインサート処理が重く、かつ全件なのであれば、インデックスを破棄し、統計情報の取得も止めてからインサートを行い、あとでインデックスを作り直すのも手です。 2. ファイルキャッシュ分を除いたメモリの使用状況はどうですか? Linux は、デフォルトで空きメモリ領域をファイルキャッシュとして利用します。そのため、稼働中のマシンの空きメモリがほとんどないのは、正常動作です。 アプリケーションの利用メモリが増えると、ファイルキャッシュとして利用できるメモリは少なくなります。 sysctl -w vm.drop_caches=3;sysctl -w vm.drop_caches=0 で、キャッシュをクリアできるので、その状態で、アプリケーションのメモリの使用状況を調べてください。 3. メモリリークもしくは、使用メモリが増大しているアプリケーションはありませんか? 連続稼動させることが前提のシステムでは、アプリケーションの利用メモリがほぼ一定となることが必要です。キャッシュをクリアした状態で、空きメモリが減っていくようであれば、メモリの利用量が増大していっているアプリケーションを特定してください。 特定できれば、そのプロセスのメモリ使用状況が一定になるように対策を行うべきですが、とりあえず対症療法は、そのプロセスを再起動することによって、メモリを確保するのもありかと思います。 処理が終わったらとりあえずリブートという感覚は、ちょっと感心しませんねぇ。 | ||||
|
投稿日時: 2007-12-17 12:57
プロセスの再起動が失敗した場合を考えると、マシンの再起動が無難な気がしますが? (金と時間に余裕があるのであれば問題ありませんが、プロセスの特定にも工数が発生 しますし、シェルを組んでテストをするにも同じくです。) まあユーザーさんと要相談ですね。 | ||||
|
投稿日時: 2007-12-17 13:45
上総様,progman様,holic様ご回答ありがとうございます。
上総様 定期的な再起動はお客様の意向により出来ません。 再起動の際は各箇所へ連絡が必須のため面倒だそうです。 progman様 私の拙い文章で大変ご迷惑おかけしました。 正確な情報をお伝え出来るよう,今後は気を付けます。 holic様 Oracleの件ですが,夜間バッチ中は統計情報を利用しない方法を検討してみます。 取りあえず,夜間バッチ中にシェルで情報を取得しつつ,様子見する事でお客様から了解を得ました。 皆様本当にありがとうございました。 | ||||
|
投稿日時: 2007-12-17 14:20
出来ればSQLローダーで全件データの入れ直しが可能か検討してみて下さい。
(固定長・CSV形式のどちらでも動作可能です。) SQL*Loader (http://www.ne.jp/asahi/hishidama/home/tech/oracle/sqlldr.html) |
«前のページへ
1|2|3