Asakusa on M3BPの環境変数

Asakusa Framework Advent Calendar 2016の24日目です。

Asakusa on M3BPでは、バッチ（YAESS）実行時のオプションを環境変数で指定することが出来ます。

まずASAKUSA_M3BP_OPTS。これはjavaコマンドに渡すオプションを指定します。

$ export ASAKUSA_M3BP_OPTS='-Xmx64g'

M3BP本体はC++なのでOSネイティブのバイナリーで実行されますが、Asakusa on M3BPはJava部分もあるので、javaのヒープ容量もそれなりに必要です。
（かといって64GBは多すぎですが＾＾； メモリーが512GBもあると、JavaVMのヒープも「てきとーに64GBにしとけばいっかー」みたいな感じになります(爆)）

---

それからASAKUSA_M3BP_ARGS。これはM3BPのパラメーターを指定します。
特にm3bp.propertiesで記述するような内容は、--engine-confオプションを（複数）使って指定します。

$ export ASAKUSA_M3BP_ARGS="--engine-conf com.asakusafw.m3bp.output.buffer.size=4194304 --engine-conf com.asakusafw.m3bp.output.buffer.flush=0.8"

---

あとASAKUSA_M3BP_LAUNCHER。
これについてはアドベントカレンダー2日目（バッチのメモリー使用量の確認方法）を参照して下さい。 

Asakusa on M3BPの出力バッファーサイズ

Asakusa Framework Advent Calendar 2016の23日目です。

Asakusa on M3BPでは、各vertex（演算子）の出力バッファーサイズと1レコードの最大サイズ（バイト数）の関係も気にしないといけません。
出力バッファーの使用量が閾値を超えるとフラッシュされるのですが、フラッシュ直前までデータが入っている状態で残り容量より大きいサイズのレコードが来ると、バッファーに入れられず、例外が発生します。

デフォルトでは出力バッファーサイズは4MB、閾値はその0.8倍なので、レコードサイズが800kBを超える場合は注意が必要です。
（フラッシュ前のバッファー使用量にも依るので、運が良ければ大きなレコードを出力しようとしても落ちないのですが、バッチ処理で運に頼るのもどうかと(爆)）
（てゆーか、1レコード800kBは結構大きい方だと思います。普通はそうそう超えないですよね＾＾；） 

Asakusa on M3BPの入出力バッファーのアクセス方式

Asakusa Framework Advent Calendar 2016の22日目です。

Javaでは、意外と2GBの壁があります。例えばbyte配列は2GBより多いサイズを扱えません。これは、配列の添え字がintなので、Integer.MAX_VALUEより大きな値を指定できない為です。
普通のJavaアプリケーションならそんな大きなサイズのデータは扱わないかもしれませんが、ビッグデータを扱う分散処理フレームワークでは結構有名な問題のようです。（例えばSparkにそんなIssueがある）

で、Asakusa on M3BPも同様の問題があります。
デフォルトでは、各演算子の出力やファイル出力で1ファイル当たり2GBを超えると、エラーが発生します。
ファイル出力の場合は、Direct I/OのExporterでファイル分割するように指定してあれば、分割された個々のファイルがそれぞれ2GBを超えなければ大丈夫です。（「*」で自動分割する場合は問題なし）

どうしても2GBを超えたい場合は、ASAKUSA_HOME/m3bp/conf/m3bp.propertiesでcom.asakusafw.m3bp.buffer.access（デフォルトはnio）にunsafeを指定すると、2GBを超えるデータを出力できます。
（unsafeというのは、sun.misc.Unsafeを使っている？これだとすると、これはsunパッケージなので非推奨であり、Java9辺りで無くなるという話もある）

Asakusa on M3BPの複数ジョブフローのCPU設定

Asakusa Framework Advent Calendar 2016の21日目です。

Batch DSLでは複数ジョブフローを並列実行するように記述できます。
Asakusa on M3BPではバッチが使用するCPU数を設定できます。
では、複数ジョブフローが並列実行できるよう記述されているバッチに対してCPU数を指定するとどうなるでしょうか？

CPU数の指定は、厳密にはバッチに対してではなく、ジョブフローに対して効くものです。したがって、並列で実行されるジョブフローそれぞれに（同一の）CPU数が設定されます。
なので、ジョブフローを並列に実行するバッチでは、そのことを勘案してCPU数を指定する必要があります。

（今のところ、バッチ内の個別のジョブフローに対して別々のCPU数を指定する方法は無いようです）

Asakusa on M3BPのCPU設定

Asakusa Framework Advent Calendar 2016の20日目です。

Asakusa on M3BPはマルチスレッドで動作します。スレッド数は、デフォルトでは（最大で）全ての論理CPUが使われます。
が、データ量によっては、そんなにCPU数があってもあまり意味が無いことがあります。（Hadoop（MapReduce）やSparkでタスク数を多くしても意味が無い場合があるのと同様です）
そうした場合は、ASAKUSA_HOME/m3bp/conf/m3bp.propertiesのcom.asakusafw.m3bp.thread.maxで、使用するCPU数（スレッド数）を指定することが出来ます。

上で「論理CPU」とわざわざ書いたのは、M3BPにおいては、物理CPUを意識してどれを使うのかを指定することが出来るからです。
CPU関連の用語については詳しくないのですが、マザーボードに物理的に設置できる個数がソケット数、1ソケットの物理CPUに対して複数コアが有り、1コアに対してハイパースレッディングで論理的に複数コアあるように見えているのが論理CPU。かな？
それぞれのレイヤーにキャッシュがあるそうです。
で、 com.asakusafw.m3bp.thread.affinity（デフォルトはnone）にcompactを指定すると同一ソケット上のコアから順番に割り当て、scatterを指定すると異なるソケットから順番に割り当てていくということが出来ます。
正直、どの方式が良いのかよく分からないので、興味があるなら試してみると良いでしょう。
（ただし、クラウド等の仮想マシン上で動いている場合は物理CPUの情報は正しく取れないでしょうから、意味が無いと思われます）

ちなみに、この物理CPUの情報を使用する為に（だと思いますが）、Linuxのライブラリーのバージョンがある程度高い必要があります。CentOSで言うなら、7以上ならOKです。6だとライブラリーを手動でバージョンアップしないと駄目そうですが、バージョンアップに成功した例を聞いたことがありません。下手するとLinuxの標準的なコマンド（cdとかlsとか）すらも使えなくなります(爆) 自分はそれで仮想マシンを1つ駄目にしましたorz