Subject: a problem of long STW because of GC ref-proc

Even if set to 64KB,it also has more than 100w softRef ,and will cost too long still.
this "GC ref-proc" process 50w softRef and cost 700ms:
2019-09-18T03:16:42.088+0800: 125161.477:
[GC remark
2019-09-18T03:16:42.088+0800: 125161.477:
[Finalize Marking, 0.0018076 secs]
2019-09-18T03:16:42.089+0800: 125161.479:
[GC ref-proc
2019-09-18T03:16:42.089+0800: 125161.479: [SoftReference, 499278 refs, 0.1382086 secs]
2019-09-18T03:16:42.228+0800: 125161.617: [WeakReference, 3750 refs, 0.0049171 secs]
2019-09-18T03:16:42.233+0800: 125161.622: [FinalReference, 1040 refs, 0.0009375 secs]
2019-09-18T03:16:42.234+0800: 125161.623: [PhantomReference, 0 refs, 21921 refs, 0.0058014 secs]
2019-09-18T03:16:42.239+0800: 125161.629: [JNI Weak Reference, 0.0001070 secs]
, 0.6667733 secs]
2019-09-18T03:16:42.756+0800: 125162.146:
[Unloading, 0.0224078 secs]
, 0.6987032 secs]
------------------ 原始邮件 ------------------
发件人: "OpenInx"<[EMAIL PROTECTED]>;
发送时间: 2019年9月30日(星期一) 上午10:27
收件人: "Hbase-User"<[EMAIL PROTECTED]>;

主题: Re: a problem of long STW because of GC ref-proc

100% get is not the right reason for choosing 16KB I think, because  if you
read a block, there's larger possibility that we
will read the adjacent cells in the same block... I think caching a 16KB
block or caching a 64KB block in BucketCache won't
make a big difference ?  (but if you cell byte size is quite small,  then
it will have so many cells encoded in a 64KB block,
then block with smaller size will be better because we search the cells in
a block one by one , means O(N) complexity).
On Mon, Sep 30, 2019 at 10:08 AM zheng wang <[EMAIL PROTECTED]> wrote: