ヒープの状態とGCの実行回数を表示する（備忘録）

ヒープメモリの状態とGCの実行回数を表示するコマンド

jstat -gcutil -h3 <ProcessID> <表示頻度(ms)>


ex.
jstat -gcutil -h3 4716 5000


  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
 92.74   0.00  76.22   9.29   7.27    188   23.448     0    0.000   23.448
 92.74   0.00  98.90   9.29   7.27    188   23.448     0    0.000   23.448
  0.00  92.31  23.16   9.29   7.27    189   23.630     0    0.000   23.630

＜各列の説明＞
S0：S0領域の使用率（Young領域）
S1：S1領域の使用率（Young領域）
E ：Eden領域の使用率（Young領域）
O ：Old領域の使用率（Old領域）
P ：Permanent領域の使用率（永続領域）

YGC：YoungGCの発生回数
YGCT：YoungGCの処理時間（秒）
FGC：FullGCの発生回数
FGCT：FullGCの処理時間（秒）
GCT：YoungGCとFullGCの処理時間（秒）


＜ヒープの世代＞
■Young領域
S0,S1,EdenがYoung領域（Newされてからまだ若いヒープ）
Eden: Newがおこなわれるとまずここにたまる。
S0: Edenから少し年をとったヒープ
S1: Edenから少し年をとったヒープ

■Old領域
　Young領域にある間に、解放されることがなかったヒープ。
　Young領域から、Old領域に移動するタイミングは、YoungGCの回数やS0,S1領域が満杯になったときなどGCアルゴリズムによる。

■Permanent領域
　基本的には永続的に保持するメモリ。主にクラス定義など


＜ヒープの容量を表示する＞
上記のオプションの「-gcutil」を「-gc」に変えるだけでよい。

jstat -gc -h3 <ProcessID> <表示頻度(ms)>


ex.
jstat -gc -h3 4716 5000


S0C     Survivor 領域 0 の現在の容量 (KB)
S1C     Survivor 領域 1 の現在の容量 (KB)
S0U     Survivor 領域 0 の使用量 (KB)
S1U     Survivor 領域 1 の使用量 (KB)
EC     Eden 領域の現在の容量 (KB)
EU     Eden 領域の使用量 (KB)
OC     Old 領域の現在の容量 (KB)
OU     Old 領域の使用量 (KB)
PC     Permanent 領域の現在の容量 (KB)
PU     Permanent 領域の使用量 (KB)
YGC     若い世代の GC イベント数
YGCT     若い世代のガベージコレクション時間
FGC     フル GC イベント数
FGCT     フルガベージコレクション時間
GCT     ガベージコレクション総時間

※S0CやS0U、ECやEUの「C」はCapacity、「U」はUsageと思われる。

http://docs.oracle.com/javase/jp/7/technotes/tools/share/jstat.html

ADempiereのMRPの処理速度改善メモ

MRPの処理速度改善のために、いろいろ実装したが、スレッド化がかなり効果的だった。
１スレッドごとに16％程度の処理改善がみられたようだ。
ただし、コア数以上のスレッドでは改善率が極端に下がる。

試験環境は、6コアで、1.16の6乗＝2.4363
実際には、6スレッド以上を起動しているので、2.4倍以上の速さになることを確認。

そこそこの部品構成と需要件数でも、30分で処理が終わるMRPになった。

技術的には、スレッドごとにレコードロックが競合しないように設計すること、こまめにコミットしてレコードロックを長時間保持しないこと、Wait、Notifyを巧みに使用すること、トランザクションのコミット漏れや長時間トランザクション、コネクション数のケア、Postgresのデッドタプル、オートバキューム実行ログのチェックなどがポイントだったように思う。

Postgresチューニングパラメータ（主なもの）

Postgresのチューニングパラメータの備忘録。（9.3ベースの設定ファイル）
postgres.confで設定される。
多くのPostgresのチューニングパラメータは、一昔前のPCを意識したような設定値であり、
最近のPCスペックにあった設定をしておいたほうがいい。


■メモリ関連
☆shared_buffers = 2048MB            # min 128kB
                    # (change requires restart)
    表領域をキャッシュする領域。
    たとえば、SELECTを実行するときに、この領域にデータがあれば
    ディスクアクセスせずここのデータを読み書きする。
    ディスクアクセス回数を減らすことができれば、処理が速くなる。
   
    OSキャッシュとの兼ね合いもあるので、あまり大きくすることは推奨されない。
    実メモリの25％がいいといわれている。
   
    また、指定方法は古いバージョンではバッファ指定だったが、
    最近のバージョンでは、バッファ指定できないようだ。
    GB、MB、kBの単位で設定するようにする。


☆work_mem = 1MB                # min 64kB
　Postgresが処理に使うワーキングメモリ。
　(実メモリ-shared_buffers)/max_connectionsを超えるとスワップするので注意。
　

☆maintenance_work_mem = 16MB        # min 1MB
　バキュームなどのメンテナンス処理に使われるワーキングメモリ。
　少なすぎると、バキュームされないことがあるという人もいるが詳細不明。



■コネクション関連
☆max_connections = 300
　work_memとの関係に注意。
　work_memは接続ごとに発生するので、work_mem*max_connectionsのメモリを確保しておかないと、スワップ発生の危険性がある。
　(実メモリ-shared_buffers)/max_connectionsを超えるとだめ。

☆tcp_keepalives_idle = 60        # TCP_KEEPIDLE, in seconds;
                    # 0 selects the system default
　コネクションを完全に接続するまでの待ち時間。
　デフォルトが大きいので、確実な値を設定しておくのがベター。
                   
tcp_keepalives_interval = 5        # TCP_KEEPINTVL, in seconds;
                    # 0 selects the system default


■BackGround Writer
　BackGround Writerは、CheckPointが発生するまでに、
　ディスク書き込みを少しでもしておくことで負荷の分散を計るもの。
　負荷の分散が目的であり、処理量を減らすものではない。
　
　アプリケーションで画面を表示するなどの場合、極端に遅いタイミングがあっては困るが
　チェックポイントの書き込み量が多いときには、処理が極端に遅くなる可能性がある。
　そういった場合に、BackGroundWriterによって、チェックポイントの書き込みが減るように
　少しずつ書き込みをおこない、チェックポイント処理を軽減して、極端な処理落ちを防ぐことができる。（処理を分散するだけで、処理量を減らすものではない。）
　
　逆に、大量データ処理の場合などは、負荷の分散よりも最終処理時間が大事なので、
　チェックポイントに任せておいても問題ないと思われる。
　（１回にたくさん書き込みしたほうがディスクアクセスを減らせるため）
　その場合、チェックポイントとバキュームの発生タイミングなどのチューニングがむしろ重要だと考えられる。
　
　
☆bgwriter_delay = 5000ms            # 10-10000ms between rounds
　BackGroundWriterの実行間隔。

☆bgwriter_lru_maxpages = 1000        # 0-1000 max buffers written/round
　BackGroundWriterが書込むサイズの最大値。
　１バッファは8KB。
　０にすると、BackGroundWriterを発生させない。

☆bgwriter_lru_multiplier = 10.0        # 0-10.0 multipler on buffers scanned/round
　最近の周期で書き込んだ平均とこの値が掛け合わされて、BackGroundWriterが書込むサイズの最大値とする。なお、ここで算出した最大値とbgwriter_lru_maxpagesの小さいほうが採用される。


■WAL
☆wal_buffers = 64MB            # min 32kB, -1 sets based on shared_buffers
                    # (change requires restart)
    WAL＝いわゆるトランザクションログをバッファリングしておく領域。
    基本的には、コミットのときに、WALログファイルに書き込まれる。
    その他、WALバッファがあふれたとき、Checkpoint、Vacuum実行時、WALライター実行時などにWALログファイルに書き込まれる。

　多くの更新を実行するトランザクションがある場合は、WAL_Buffersは大きい目に設定しておいたほうが
　ディスク書き込みを減らすことができる。

　デフォルトの-1で、SharedBufferの1/32を割り当てる。
　ただし、64KBから16MBの範囲内であり、それより大きい値を設定する場合は変えたほうがいい。
　8.1まではバッファ指定だが、それ以降は、サイズ指定する。


☆wal_writer_delay = 200ms        # 1-10000 milliseconds
　WAL Writerの実行周期。