なんでCompleted major compactionってlogがたくさん出てるのさー defaultはdailyじゃないんかーい #hbase
2011-08-30 20:18:15YCSB用のusertableしか置いてないからか?! / if the set of store files selected for compaction is the set of all store files... http://t.co/0nkhY3S #hbase
2011-08-30 20:24:49@hamburger_kid なんか3時間くらいおきにトリガーは動いちゃうみたいですね。その時点で前回のメジャーコンパクションから24時間以上すぎているリージョンはメジャーコンパクションされちゃうっぽいです。ソースまでは確認していませんけど。 #HBase
2011-08-30 20:46:24@ueshin @hamburger_kid hbase.hregion.majorcompaction はデフォルト24時間です。ソースは o.a.h.hbase.regionserver.Store
2011-08-30 20:59:19@ueshin @shiumachi YCSBやりながら観察してるんですが usertable作成もクラスタ起動も今日したので まだ24hも経ってないんです そらに毎時発生してるんです 面白い情報見つけたので明日ソース読んでみます azs! http://t.co/0nkhY3S
2011-08-30 21:05:45@hamburger_kid @shiumachi お、うちのももしかしてこの辺絡んでるのかしら。すいません、ここは、まいいや、で深く探ってなかったところでした。僕も調べてみます〜。
2011-08-30 21:12:57約3時間おきに起動するメジャーコンパクションは HRegionServer$MajorCompactionChecker のせいじゃなかろうか。デフォルト 10000秒 = 2.7時間 おきにメジャーコンパクションのトリガを引いているように見える。(続
2011-08-30 22:12:47メジャーコンパクションの周期はきっちり(デフォルトだと)24時間というわけではないようだ。 hbase.hregion.majorcompaction.jitter という設定(デフォルト 0.20F)で24時間 ±20%(4.8時間)というブレを入れている模様。
2011-08-30 23:18:11@shiumachi はい、Store#getNextMajorCompactTime()でブレを入れてあるようです。
2011-08-30 23:25:56@ueshin "// default = 20% = +/- 4.8 hrs" ほんとだ……。やっぱ真面目にソース読んどくもんですね。勉強になりました
2011-08-30 23:27:08コンパクション要求があるのは HBaseAdmin経由でcompact/split指示をした時(shellでコマンド発行とかWebUIのボタンぽちとか)、MemStoreをflushする時、リージョンをopenした時、など。と、MajorCompactionChecker。
2011-08-30 23:37:24WebUIのcompactボタンはマイナーコンパクション指示なのでshellで compact をやった時と一緒。ただ、それでも24時間±20%を超えてればメジャーコンパクションになる。
2011-08-30 23:51:27@ueshin 20%のブレがあるのは先の記事によると一斉にmajor compactionが動き出すのを散らす意図のようですね しかしソース読むの早い! それを踏まえて明日自分でも読んでみますmm azs!
2011-08-31 00:12:13@hamburger_kid なるほど〜。それでウチのクラスタもバラけちゃってるんですね。 ソースを読む早さについては最近ちょうどRegionSplitterがらみでこの辺読んでいたのが大きいと思います。w
2011-08-31 00:30:24んー、もう一個メジャーコンパクションにされちゃう条件があるんだけど、ちょっとよくわかんないな。。。これが毎時メジャーコンパクションの原因かも?
2011-08-31 00:33:48具体的にはStore.javaの711行目でメジャーコンパクションになるんだけど、その前の条件が、StoreFileの数がコンパクションスレッショルドを超えていて、そのサイズが・・・?
2011-08-31 00:52:32