実行時のCPU使用率を増やしたい

WindowsServer2003(StandardEdition)でのCPU使用率において、
質問があります。

VB6.0で作成したバッチプログラムを動かしています。
プログラムの内容はVBからMdbに対して問い合わせを行い
結果をMdbに格納する。。。といった感じです。
(接続はADOです)

またWebサーバーもかねており、IIS6.0で運用しています。
(メインの言語はASP)

上記の処理(バッチ及びIIS)の中にはかなり
CPU負荷かが掛かる処理があるのですが
CPUが30%を超えないのです。
(VB、IIS運用時共。確認はタスクマネージャー)

重い処理が走るときは30%付近をMAXにだらだらと時間が過ぎていきます。
こちらとしては一気に100%まで使い切ってもらって処理時間を短縮したい。

コーディング、あるいはＯＳ上で設定などがあるのでしょうか？
WindowsServer2003は導入後、RAID、IIS等の環境設定を行いましたが
それ以外はほぼデフォルト状態です。

サーバ環境
CPU：Xeon3.2G
メモリ：1GB
HDD：十分な空容量有

No.2 ベストアンサー 回答者： K-Sogacchi 回答日時： 2007/06/01 14:55

連続ですみません。

アプリレベルで、出来るだけCPUを使って処理を速くするというのであれば、
「出来る限りディスクアクセスを減らす」方向の開発を行うのも
一つの方向性かもしれません。
例えば、バッチ処理で頻繁に参照するマスタデータ等があるなら、
それは極力一度だけしか読まないようにする（一度読んだらメモリに置いておく）とか。
コーディングは面倒になるとは思いますが、処理の内容等によっては
劇的に速くなる可能性もあると思います。

この回答へのお礼

リソースを割けず、納期優先で製造した為
かなり荒っぽい処理をしているのは事実です。
後の改修につなげたいと思います。
ご意見ありがとうございます。

お礼日時：2007/06/01 15:38

No.4 回答者： PED02744 回答日時： 2007/06/01 17:50

全て同一マシン上にあるのなら、DBのHDDアクセスがネックになっている可能性が高いように思われます。

RAID5なら、間違いなくI/O待ちが結構多そうですし。

各プロセス単位のCPU利用率はどうなりますか？
SYSTEM なんかが結構上位に来ていたりしませんか？

この回答へのお礼

ご返答ありがとうございます。
今回の件は、ディスクＩ／Ｏのボトルネックが要因とし、
環境改善案としては物理的(ハードreplace等)対策を検討
する事としました。

ありがとうございました。

お礼日時：2007/06/06 09:36

No.3 回答者： PED02744 回答日時： 2007/06/01 16:08

追加で質問させていただいてよろしいでしょうか。

１．Xeon3.2G というのは、シングルコア？マルチコア？　マルチCPU？
２．DBは外部？　同一マシン？

この回答への補足

閲覧ありがとうございます。
以下、ご返答します。
１．シングルコアです
２．ＤＢは同一マシンです。
　　また、物理的に３ディスクですがＲＡＩＤ５で組んでますので
　　論理的に１ディスク状態です。
　　よって、Ｉ／Ｏの分散化は出来ていないと思います。

補足日時：2007/06/01 16:34

No.1 回答者： K-Sogacchi 回答日時： 2007/06/01 14:47

Web系とかIISは全然詳しくないのですが、一般論での回答です。

CPU使用率は、あくまで「CPU単独の」使用率です。
システム全体の負荷を示すわけではありません。
システム全体として、ディスクアクセス（MDB使ってるとの事なので
結構負荷が掛かると思います）等を含めると目一杯頑張っていても、
CPUだけ見れば、それほど頑張っていないという事は多いです。
……と言うより、CPU負荷100％ってのは、CPU内部で（他へのアクセス無しで）
ループ計算してるとか、バグで無限ループに陥っているとか、限られた
状況でしか見られないような気がします。
DB使用アプリで30％使用なら、かなりCPU使用率高いような気がしますよ？たぶん。

一応、該当アプリのプロセスの優先度を上げることによって、
優先的にCPU時間を割り当てれば、負荷率が上がる「可能性もあります」が、
下手に やたら上げると、特にサーバだとヤバい事になるかと思いますので、
気をつけてください。

この回答へのお礼

ご返答ありがとうございます。
なるほど、ディスクアクセスがボトルネックになっている
と言う事ですね。。
その可能性は気づきませんでした。

お礼日時：2007/06/01 15:35