- - PR -
ディスクI/Oがだんだん遅くなる件
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-12-12 22:30
あと、気になったのですが、「だんだん遅くなる」とありますが、
本当にだんだん遅くなるのでしょうか？ つまり、リブート直後が最短で、時間が経過するごとに時間が 伸びるのでしょうか？（右肩上がり？） 例えば、リブート１時間後は２分で、２時間後は３分って感じですか？？ | ||||||||
|
投稿日時: 2007-12-13 09:15
おはようございます。
ていうのは、まだ情報は採取できていないようなので 定期的に採ってみては？ という提案をさせて頂きました。 サポートから指示があった時点でそのような情報を採取していた可能性も あるとは思いますが、バニーメンさんはsar等の見方がわからない と言われていますので、すぐの返信はたぶん無理なのでしょう。
あれ？ 考えてたのはfilesystemがHW側に渡すタイミングですかね。 キューが混んでるのなら早めにフラッシュしてあげれば 開いたと思ってましたけど。ちがいましたっけ。 記憶違いだったらごめんなさい。 ＃バランスも必要だと思いますが。。 いずれにしろ、topやsarやiostatの結果をトレースして 傾向をつかんでからでないと難しいと思っています。 むろん、可能なタイミングで適宜該当の処理時間を計るってこともしながら。 | ||||||||
|
投稿日時: 2007-12-13 10:42
上総様，みなと様，progman様，ラララ様ご回答ありがとうございます。
返信遅くなり申し訳ありません。 ファイルコピーは同一デレクトリー内で行いました。 cp /tmp/a0.dat /tmp/a1.dat >例えば、リブート１時間後は２分で、２時間後は３分って感じですか？？ 今回は12/10にリブートしました。12/11の処理は12/10より約1時間早く終了しました。 12/12は12/11+2分(これは誤差の範囲と思います)。12/13は12/11＋15分。 前回もこんな感じで少しずつ増えていき最終的にはリブート後のバッチ終了時間＋30分位で落ち着きました。 サポートからファイルコピーを行っている状態での情報収集を依頼されたので，バッチが動いている時間帯での調査は行っていません。申し訳ありません。 断面で調査を行うのはなく，シェルを使ってバッチ動作中にログを採取する等の継続的な調査を行います。 ちなみに10秒間隔のvmstat(サーバのメモリは8G) リブート直後(800Mファイルコピー) procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy id wa 2 1 0 6883152 37916 885000 0 0 2227 2338 262 7655 4 5 78 13 0 6 0 6708948 38128 1055228 0 0 8240 8894 490 25247 11 18 22 49 0 3 0 6515252 38356 1251840 0 0 9558 8558 551 31951 2 9 34 55 0 4 0 6334464 38568 1431180 0 0 8726 8332 522 29088 2 9 30 58 0 3 0 6179484 38748 1584508 0 0 7457 8645 520 24797 3 9 27 61 1 3 0 5993244 38964 1766480 0 0 8854 7575 509 30060 2 9 46 42 0 3 0 5851612 39132 1904372 0 0 6702 9667 534 22547 2 6 45 47 1 4 0 5652956 39352 2095864 0 0 9315 7345 514 30951 3 10 35 52 1 4 0 5516276 39516 2231440 0 0 6599 9273 530 21809 2 7 38 53 0 3 0 5337192 39736 2411160 0 0 8740 7404 510 29268 2 9 58 31 0 2 0 5219224 39868 2527208 0 0 5631 9647 456 19135 2 5 59 34 リブート前(800Mファイルコピー) procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy id wa 17 3 0 18528 87468 7357260 0 0 25 2610 201 10643 1 10 75 15 13 3 0 17568 84476 7371692 0 0 1115 3331 315 7961 1 9 22 68 0 3 0 17440 67296 7388984 0 0 3711 3501 392 12986 2 11 27 61 2 3 0 18264 67320 7388140 0 0 2170 4455 353 11043 1 10 43 46 2 3 0 18424 66188 7389108 0 0 2661 4392 358 16653 1 13 21 65 0 2 0 17552 66212 7389920 0 0 1417 3490 345 7295 1 8 14 78 3 0 0 17496 66276 7389944 0 0 2351 2536 369 12529 1 10 43 46 0 3 0 17312 66340 7390056 0 0 1755 5155 338 10909 1 9 17 72 0 3 0 19944 66412 7389852 0 0 3394 4442 384 16126 1 12 27 60 2 3 0 17284 66452 7389988 0 0 1160 2220 320 7013 1 8 37 54 0 3 0 18372 66512 7388840 0 0 2563 4503 370 11021 1 9 45 45 0 3 0 17440 66564 7389712 0 0 992 4545 310 18236 1 12 23 64 0 3 0 17864 66596 7389228 0 0 0 5220 296 12380 1 9 12 77 0 3 0 17364 66644 7389708 0 0 0 5272 295 17696 1 11 28 60 0 4 0 17376 66704 7389632 0 0 1403 3880 327 9474 1 8 13 78 0 4 0 17412 66780 7389496 0 0 4478 3593 414 14540 1 11 37 51 1 3 0 17636 66812 7389248 0 0 2334 3072 360 7852 1 8 9 82 1 4 0 17576 66860 7389264 0 0 3203 4165 388 10538 1 9 11 79 1 0 0 17432 66908 7389336 0 0 4470 3348 419 14477 1 18 15 66 0 4 0 17524 66948 7389176 0 0 3610 4115 464 12028 1 8 39 51 0 3 0 17288 66984 7389392 0 0 2262 2906 420 7756 1 9 18 72 0 3 0 17300 67016 7389340 0 0 2042 3042 354 6887 1 7 9 84 0 0 0 17632 62416 7393840 0 0 4142 2550 401 13581 1 10 38 51 0 0 0 17572 62416 7393892 0 0 1 2045 208 557 0 5 74 21 見難くてすいません。 | ||||||||
|
投稿日時: 2007-12-13 11:25
メモリの空き容量が6.8GBから17MBまで落ちてますね。
Linuxが落ちても不思議じゃないかも・・・・ こうなるとどのプロセスが異常なまでにメモリを使用しているかと、メモリの解放が 正しく行われているかを調査するしかないと思います。 データベースサーバーとして扱われている事を考えると、Oracleに割り当ててるメモリ 及びSHMMAX等のOS上の制限値がどのようになっているかも調査する必要があります。 | ||||||||
|
投稿日時: 2007-12-13 15:54
バニーメンさんは実行が遅くなって、運用上支障があって改善したいのですか？
遅くなるのは理解に苦しむ、ユーザへの説明に困るので、理由が知りたいのですか？ 前者なら、物理メモリを増やす、運用で再起動をおこなえるようにする。 処理内容を見直す。 といった対処になるでしょう。 後者ならモニタする機能を勉強するということになるでしょう。 ２分弱の処理が４分かかるということは驚くようなことではないとおもいます。 Windowsクライアント使っていても似たようなことはないですか？ 今までアップされた内容が環境等に問題があり起こっているということはないとおもい ます。 コンピュータシステムでありうる現象がおこっていると、私にはおもえます。 それで問題があるのなら、その問題点をはっきりさせてはどうでしょう。 | ||||||||
|
投稿日時: 2007-12-13 18:43
上総様，progman様ご回答ありがとうございます。
progman様への回答としては後者になります。 発端は運用上に問題が発生した事による調査でした。朝の運用開始時間にデータが作成されてませんでした。 前任のサーバ管理者が「OSのアップデート(Update6)を行った後に処理が遅くなりました。」とユーザーに報告していました。 前任者はバッチの中でも特に重い処理をスキップさせて朝の運用開始時間に間に合わせるように変更しました。その後，サーバ調査をやっていませんでした。 その状態で私が引き継ぐ事になりました。 前任者の保存していたバッチ処理ログを見ると 摘要前(処理実行時間) 平均6時間半。 摘要後(処理実行時間) 1〜7日目：平均6時間半 8〜9日目：平均3時間半 10日目：6時間半 11日目：8時間 12日目以降：平均7時間半 現在：平均3時間半(処理スキップの為) 特にDBにインサートする処理での時間差が終了時間に影響を与えていました。 処理自体は毎日最新データを全件取込後，全て作り直します。 毎日のデータ量に大きな差はありません。 私が引き継いだ後，Oracleの設定がデフォルトでしたので，REDOログとSGAを拡張しました。 その際，800MのREDOログファイルを作成するのに5分程かかりました。 スペックの劣る開発機より時間が掛かるためOracleを疑ったんですが，cpコマンドでもやはり5分程かかったのでハード・OSがおかしいのか？と思いました。 Oracleの設定変更後，サーバの再起動はせずにバッチは10分程早くなりました。 その後の事は今までのアップ内容になります。 現在は時間内に終了する(処理スキップの為)ため支障はないのですが，将来的に別システムをこのサーバで稼働させる計画なので...。 私自身Linuxを扱うのが初めてなので，再起動前後で同じファイルのコピー時間が分単位で違いがある事が異常に思えました。 モニタリングの勉強します。 | ||||||||
|
投稿日時: 2007-12-13 19:13
取りあえず、サーバーに長時間に渡り高負荷を与える処理が終わったら、
システムを再起動するのがベストかと思います。 それで暫くは放っておいて、夜間処理を何か追加すると言う話が出た時の為に、 現行の処理（ソース）を見て（チラ見でもいいと思いますが）問題点を探れば よいかと思います。 （要ユーザーとの相談ですが、予算が出るなら大手を振って作業が出来ますので） しかし、全件を入れ直しと来たらメモリが幾つあっても足りない様な気がします。 個人的にはINSERTよりローダーで読み込める形にすると、処理が早く終わるので 御奨めですが。 後、プロセスが使用しているメモリを調べる為のコマンドとして、『ps alx』と 打つと常駐しているプロセスのメモリ使用状況が分かるみたいです。 @ Linux でプロセスごとのメモリー使用量を調べる （http://at-aka.blogspot.com/2006/07/linux.html） こちらを今現在の状態で打ってもらって、2・3日後にもう一回打つと無駄なプロセスが 分かるやも知れません。 | ||||||||
|
投稿日時: 2007-12-15 20:03
私の投稿もわかりづらく伝わってないとおもうのですが、バニーメンさんの
投稿もわかりづらいです。 オラクルのパッチ適用の話など、ここに加えると複雑になって原因がわかり づらくなります。 だんだん、どれぐらい遅くなってるのかよくわかりません。 適用後の８、９日目が非常に早く終わっていて、何故？とおもうのですが、 処理内容やＤＢの中身などなにか違いがあるのではないですか？ ここにアップされてる情報ではわかりづらいですが、実運用マシンでまた試す わけにはいかないのでしょうか。 cpの２分と４分の違いはある話だとおもいませんか？ linuxでなくてもwindowsで同じでしょう。 パソコンでなにかやってて、やたら遅い経験ないですか？ | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。