特定のコア以外に負荷はかかっておらず、メモリやディスクにも余裕があると考えられます。このような状況下においては、処理速度の向上を図ってCPUのプロセッサを追加（コアを増加）しても意味はありません。
ここでは処理の並列実行（マルチスレッド実行）を検証します。BI Publisher 11g では、バースティングの際に自動的に並列処理を行ってくれます（10gまでは、「構成」メニューでバースティング時の並列度を手動で定義する必要がありました）。
【準備】
データモデル：
データソースのSQLは以下の通りです。各行のreport_id には０または１が設定されます。
select t.*,
trunc(t.pageno/5001) as report_id
from emp2 t
order by
pageno, deptno, empno
バースティング定義：
5000ページ以前と、5001ページ以後の2つのファイルに分割して出力する定義です。分割、配信元にはともに report_id を指定します。
select distinct
trunc(pageno/5001) as key,
'Layout1' as template,
'ja-JP' as locale,
'RTF' as template_format,
'PDF' as output_format,
'FILE' as del_channel,
'false' as save_output,
'c:\workspace\' as parameter1,
'rp_' || to_char(trunc(pageno/5001)) || '.pdf'
as parameter2
from emp2
【結果】
処理時間はほぼ半減(123.6秒→67.2秒)しました。1秒あたりの出力ページ数も81.0枚から148.7枚と比例して増加しています。並列処理の効果は高いといえます。
所要時間（秒） | 秒間出力ページ数 | |
1回目 | 67.7 | 147.6 |
2回目 | 67.3 | 148.7 |
3回目 | 66.7 | 149.8 |
平均 | 67.2 | 148.7 |
【検証時のOSの挙動】
BIサーバ(ゲストマシン２)の挙動を確認します。確認は、平均時間に近い3回目の実行時の統計情報をサンプルとします。
CPU:
開始後20秒間は1コアでの処理が行われています。この部分の動きは前回と変わりませんが、その後、2つのコア(Processor(2), Processor(4))に処理が分散されていることが確認できます。
 |
| Figure 1: CPU |
メモリ：
前回同様、メモリには余裕のある状態です。
 |
| Figure 2: Memory |
ディスク：
CPUへの負荷が1コアから2コアに切り替わるタイミングでスパイクが見られますが、大きな問題にはなっていません。
 |
| Figure 3: physical disk i/o |
 |
| Figure 4: physical disk disk time(%) |
リソースに余裕のある状況では、バースティングの並列処理の効果が高いと考えられます。
[ Summary ]
It seems that a particular CPU core had been the bottleneck in the last test. BI Publisher was mainly working in a single thread.
You may suppose the other CPU cores, the memory and the physical disk can afford more load.
In the situation like this, adding another CPU processors does not mean anything.
This time, we see the parallel processing in a bursting job. BI Publisher 11g automatically performs multi thread.
[Settings]
Burst into two files. The data would be devided based on page number.
Data model:
select t.*,
trunc(t.pageno/5001) as report_id
from emp2 t
order by
pageno, deptno, empno
Set "report_id" for Split by and Deliver by.
select distinct
trunc(pageno/5001) as key,
'Layout1' as template,
'ja-JP' as locale,
'RTF' as template_format,
'PDF' as output_format,
'FILE' as del_channel,
'false' as save_output,
'c:\workspace\' as parameter1,
'rp_' || to_char(trunc(pageno/5001)) || '.pdf'
as parameter2
from emp2
[Result]
The elapsed time is cut into 67.2 seconds, almost a half.
Elapsed Time(sec) | pages / sec | |
1st | 67.7 | 147.6 |
2nd | 67.3 | 148.7 |
3rd | 66.7 | 149.8 |
average | 67.2 | 148.7 |
[OS statistics]
CPU:
It runs on a single core in the first 20 seconds. Then, two cores start to work (Figure 1).
Memory:
No problem (Figure 2).
Disk:
The disk spikes right before the second core starts to work - same as last time, not a big problem (Figure 3 and 4).
Note: This time, the value of disk time is "100 - %Idle Time" instead of %Disk Time.
[Conclusion]
When you have certain amount of available resources, it's worth to consider the parallel processing.
