バッチの作業負荷

業務処理をしているほとんどの現場では、バッチ処理を必要とします。バッチ処理は通常、日中のオンラインの作業負荷が軽減した後、夜間に実行されています。これには、2 つの理由があります。日中のトランザクションをレポートに出力するためと、バッチの作業負荷でオンラインの負荷に影響を与えないためです。

「例」では、バッチジョブを実行する環境を管理する階層を説明していますので参照してください。またこの節では、その過程で使用する Solaris Resource Manager コマンドについても説明しています。

バッチの作業負荷が使用する資源

バッチの作業負荷は、オンライントランザクション処理 (OLTP) と意思決定支援システム (DSS) の作業負荷を組み合わせたもので、システムに対するこれらの影響はこの 2 者の間のどこかになります。バッチの作業負荷には、データベースに対する多くの繰り返しトランザクションが含まれていて、それぞれが重い処理作業となる可能性があります。単純な例としては、1 日の売上げ計算があげられます。このような場合、バッチ処理は、データベースからその日の各販売トランザクションを検索して、売上げ金額を抽出し、合計の計算を実行していきます。

通常バッチ処理は、プロセッサと入出力の資源が大量に必要です。これはバッチ処理とデータベースが大量の CPU 資源を必要としており、また各トランザクションを検索するために、バックエンドデータベースで多数の入出力が発生するからです。

バッチの作業負荷は、CPU と入出力の使用率を制限することで効果的に制御します。Solaris Resource Manager では、CPU 資源を細かい設定で制御できますが、入出力資源については、各作業負荷に異なる入出力デバイスを割り当てて管理しなければなりません。

資源に対するバッチの影響を軽減するには、通常は次の 2 つの方法を実行します。

• 別個のシステムにデータベースのコピーを作成して、別々のシステムでバッチとレポートの作業負荷を実行する (ほとんどの場合、バッチ処理はオンラインデータベースの一部を更新するため、データベースとは分離できないことに注意してください)。

• CPU 資源の制御を使用する。

バッチの作業負荷で発生する入出力の量は、CPU の使用量と比例するため、CPU サイクルを制限すれば、バッチの作業負荷の入出力使用率を間接的に制御できます。ただし、非常に小さな CPU の要求しかない作業負荷で過度の入出力が発生しないように注意しなければなりません。

バッチ処理に関連した問題

定義では、バッチの作業負荷は制限を受けないで実行される作業負荷であり、最短の時間で処理を終了しようとします。バッチは最悪の資源消費者ということにもなりますが、これはシステムのボトルネック (通常は、システムでデータフローが最小となる時点) で処理が制限されるまで、必要な資源をすべて使おうとするからです。

システム管理者にとってバッチには次の 2 つの問題があります。同時に実行している他のバッチジョブに影響を及ぼすということと、営業時間にオンラインの作業負荷と一緒に実行できないということです。

たとえば、午前 0 時から午前 6 時までのオフタイムにバッチジョブを実行するようにスケジュールしたとしても、システムの問題や売り上げが特に増大した場合などに、バッチの作業負荷が営業時間にずれ込むことがあります。ダウンタイムほど状況は悪くありませんが、午前 10 時 30 分にバッチの作業負荷がまだ実行されている場合、オンラインのユーザーが 1 つのトランザクションで何分も待つことになり、最終的にはトランザクション数が減少する可能性があります。

資源の割り当てを使用することで、バッチの作業負荷で利用できる資源の量を制限し、制御可能な方法で作業負荷を抑制します。