[jira] [Comment Edited] (HBASE-19357) Bucket cache no longer L2 for LRU cache
[ https://issues.apache.org/jira/browse/HBASE-19357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292025#comment-16292025 ] Anoop Sam John edited comment on HBASE-19357 at 12/15/17 7:07 AM: -- Will add to RN. bq.perhaps system tables are offheap whereas everything else is file-backed? There is no tiered BC at all. Either off heap or file. This can be useful.. There is a jira and Ram was working on a prototype. We will come back to that next year. Will add a comment in that issue. So when/if we do, then we can think of adding the system table blocks always to off heap BC. cc [~ram_krish] The issue is this one HBASE-18300 was (Author: anoop.hbase): Will add to RN. bq.perhaps system tables are offheap whereas everything else is file-backed? There is no tiered BC at all. Either off heap or file. This can be useful.. There is a jira and Ram was working on a prototype. We will come back to that next year. Will add a comment in that issue. So when/if we do, then we can think of adding the system table blocks always to off heap BC. cc [~ram_krish] > Bucket cache no longer L2 for LRU cache > --- > > Key: HBASE-19357 > URL: https://issues.apache.org/jira/browse/HBASE-19357 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19357.patch, HBASE-19357.patch, > HBASE-19357_V2.patch, HBASE-19357_V3.patch, HBASE-19357_V3.patch > > > When Bucket cache is used, by default we dont configure it as an L2 cache > alone. The default setting is combined mode ON where the data blocks to > Bucket cache and index/bloom blocks go to LRU cache. But there is a way to > turn this off and make LRU as L1 and Bucket cache as a victim handler for L1. > It will be just L2. > After the off heap read path optimization Bucket cache is no longer slower > compared to L1. We have test results on data sizes from 12 GB. The Alibaba > use case was also with 12 GB and they have observed a ~30% QPS improve over > the LRU cache. > This issue is to remove the option for combined mode = false. So when Bucket > cache is in use, data blocks will go to it only and LRU will get only index > /meta/bloom blocks. Bucket cache will no longer be configured as a victim > handler for LRU. > Note : WHen external cache is in use, there only the L1 L2 thing comes. LRU > will be L1 and external cache act as its L2. That make full sense. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19357) Bucket cache no longer L2 for LRU cache
[ https://issues.apache.org/jira/browse/HBASE-19357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16281328#comment-16281328 ] Anoop Sam John edited comment on HBASE-19357 at 12/7/17 4:47 AM: - bq. It is years since we did heap vs BC compare. Did tests 2 weeks back also based on Alpha-4 release. This is again a single node test only comparing the on heap LRU cache (old L1) vs off heap Bucket Cache (Old L2) On heap Test -- Single server with 42 GB heap size. 60% cache size ie. 25 GB.Using G1GC with 65% as Initial Heap Occupancy Factor. Off heap Test -- Single server with 17 GB heap size and 25 GB off heap Bucket cache size. Here it is combined cache any way with just 20% as the L1 cache size. Again GC tuning is same PE tests with single CF and single column and 1K value size per cell(PE defaults). Pushed ~25GB data. Warming up cache before the read tests so as to put whole data in cache. Random row read test with 100 threads. Result On heap test gives a QPS of 421940.9 whereas off heap gives a QPS of 476190.5. So for 100 threads load we have a QPS gain of 12.8%. Did not compare on heap LRU vs File mode BC. We sure it will be slower but not data now on how slower. Only on File mode, I have a concern of META data not in on heap LRU. When it is off heap there is no concern. We sure the perf wont be bad. Did many test even on smaller data size like 16GB. The Alibaba tests (and cluster) is with 12 GB BC size off heap per server. The compare was on heap LRU vs off heap BC and they saw ~25% QPS gain at that time. was (Author: anoop.hbase): bq. It is years since we did heap vs BC compare. Did tests 2 weeks back also based on Alpha-4 release. This is again a single node test only comparing the on heap LRU cache (old L1) vs off heap Bucket Cache (Old L2) On heap Test -- Single server with 42 GB heap size. 60% cache size ie. 25 GB.Using G1GC with 65% as Initial Heap Occupancy Factor. Off heap Test -- Single server with 17 GB heap size and 25 GB off heap Bucket cache size. Here it is combined cache any way with just 20% as the L1 cache size. Again GC tuning is same PE tests with single CF and single column and 1K value size per cell(PE defaults). Pushed ~25GB data. Warming up cache before the read tests so as to put whole data in cache. Random row read test with 100 threads. Result On heap test gives a QPS of 421940.9 whereas off heap gives a QPS of 476190.5. So for 100 threads load we have a QPS gain of 12.8%. > Bucket cache no longer L2 for LRU cache > --- > > Key: HBASE-19357 > URL: https://issues.apache.org/jira/browse/HBASE-19357 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19357.patch, HBASE-19357.patch, > HBASE-19357_V2.patch, HBASE-19357_V3.patch, HBASE-19357_V3.patch > > > When Bucket cache is used, by default we dont configure it as an L2 cache > alone. The default setting is combined mode ON where the data blocks to > Bucket cache and index/bloom blocks go to LRU cache. But there is a way to > turn this off and make LRU as L1 and Bucket cache as a victim handler for L1. > It will be just L2. > After the off heap read path optimization Bucket cache is no longer slower > compared to L1. We have test results on data sizes from 12 GB. The Alibaba > use case was also with 12 GB and they have observed a ~30% QPS improve over > the LRU cache. > This issue is to remove the option for combined mode = false. So when Bucket > cache is in use, data blocks will go to it only and LRU will get only index > /meta/bloom blocks. Bucket cache will no longer be configured as a victim > handler for LRU. > Note : WHen external cache is in use, there only the L1 L2 thing comes. LRU > will be L1 and external cache act as its L2. That make full sense. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19357) Bucket cache no longer L2 for LRU cache
[ https://issues.apache.org/jira/browse/HBASE-19357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16280841#comment-16280841 ] stack edited comment on HBASE-19357 at 12/6/17 9:26 PM: Commit this and open new issue for meta blocks I'd say. I'd like to see some numbers on size of prob first. It is years since we did heap vs BC compare. About time for a redo. A new issue with compare between onheap, offheap, and file-backed is overdue. in hbase2, master carries no regions. was (Author: stack): Commit this and open new issue for meta blocks I'd say. I'd like to see some numbers on size of prob first. in hbase2, master carries no regions. > Bucket cache no longer L2 for LRU cache > --- > > Key: HBASE-19357 > URL: https://issues.apache.org/jira/browse/HBASE-19357 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19357.patch, HBASE-19357.patch, > HBASE-19357_V2.patch, HBASE-19357_V3.patch, HBASE-19357_V3.patch > > > When Bucket cache is used, by default we dont configure it as an L2 cache > alone. The default setting is combined mode ON where the data blocks to > Bucket cache and index/bloom blocks go to LRU cache. But there is a way to > turn this off and make LRU as L1 and Bucket cache as a victim handler for L1. > It will be just L2. > After the off heap read path optimization Bucket cache is no longer slower > compared to L1. We have test results on data sizes from 12 GB. The Alibaba > use case was also with 12 GB and they have observed a ~30% QPS improve over > the LRU cache. > This issue is to remove the option for combined mode = false. So when Bucket > cache is in use, data blocks will go to it only and LRU will get only index > /meta/bloom blocks. Bucket cache will no longer be configured as a victim > handler for LRU. > Note : WHen external cache is in use, there only the L1 L2 thing comes. LRU > will be L1 and external cache act as its L2. That make full sense. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19357) Bucket cache no longer L2 for LRU cache
[ https://issues.apache.org/jira/browse/HBASE-19357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279947#comment-16279947 ] Anoop Sam John edited comment on HBASE-19357 at 12/6/17 10:08 AM: -- We can either continue to have the HCD setter so that not just META but any user table can set this. Or we can internally decide when a data block comes for caching. If that belongs to a system table, place in LRU cache. (not whole system tables may be only for META and NS also ok).. This will be a logic decision making with the cache block path based on table names. I tend to go with option #1 as the other looks hack way .. Comments? Wait for suggestions before making new patch. Or still u feel it is ok to keep META table data blocks in file BC when that is what available for RSs. BTW what we have for 2.0 now? The META table is in HM only or any RS? was (Author: anoop.hbase): We can either continue to have the HCD setter so that not just META but any user table can set this. Or we can internally decide when a data block comes for caching. If that belongs to a system table, place in LRU cache. (not whole system tables may be only for META and NS also ok).. This will be a logic decision making with the cache block path based on table names. I tend to go with option #1 as the other looks hack way .. Comments? Wait for suggestions before making new patch. Or still u feel it is ok to keep META table data blocks in file BC when that is what available for RSs. > Bucket cache no longer L2 for LRU cache > --- > > Key: HBASE-19357 > URL: https://issues.apache.org/jira/browse/HBASE-19357 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19357.patch, HBASE-19357.patch, > HBASE-19357_V2.patch, HBASE-19357_V3.patch, HBASE-19357_V3.patch > > > When Bucket cache is used, by default we dont configure it as an L2 cache > alone. The default setting is combined mode ON where the data blocks to > Bucket cache and index/bloom blocks go to LRU cache. But there is a way to > turn this off and make LRU as L1 and Bucket cache as a victim handler for L1. > It will be just L2. > After the off heap read path optimization Bucket cache is no longer slower > compared to L1. We have test results on data sizes from 12 GB. The Alibaba > use case was also with 12 GB and they have observed a ~30% QPS improve over > the LRU cache. > This issue is to remove the option for combined mode = false. So when Bucket > cache is in use, data blocks will go to it only and LRU will get only index > /meta/bloom blocks. Bucket cache will no longer be configured as a victim > handler for LRU. > Note : WHen external cache is in use, there only the L1 L2 thing comes. LRU > will be L1 and external cache act as its L2. That make full sense. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-19357) Bucket cache no longer L2 for LRU cache
[ https://issues.apache.org/jira/browse/HBASE-19357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16279947#comment-16279947 ] Anoop Sam John edited comment on HBASE-19357 at 12/6/17 10:07 AM: -- We can either continue to have the HCD setter so that not just META but any user table can set this. Or we can internally decide when a data block comes for caching. If that belongs to a system table, place in LRU cache. (not whole system tables may be only for META and NS also ok).. This will be a logic decision making with the cache block path based on table names. I tend to go with option #1 as the other looks hack way .. Comments? Wait for suggestions before making new patch. Or still u feel it is ok to keep META table data blocks in file BC when that is what available for RSs. was (Author: anoop.hbase): We can either continue to have the HCD setter so that not just META but any user table can set this. Or we can internally decide when a data block comes for caching. If that belongs to a system table, place in LRU cache. (not whole system tables may be only for META and NS also ok).. This will be a logic decision making with the cache block path based on table names. I tend to go with option #1 as the other looks hack way .. > Bucket cache no longer L2 for LRU cache > --- > > Key: HBASE-19357 > URL: https://issues.apache.org/jira/browse/HBASE-19357 > Project: HBase > Issue Type: Sub-task >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19357.patch, HBASE-19357.patch, > HBASE-19357_V2.patch, HBASE-19357_V3.patch, HBASE-19357_V3.patch > > > When Bucket cache is used, by default we dont configure it as an L2 cache > alone. The default setting is combined mode ON where the data blocks to > Bucket cache and index/bloom blocks go to LRU cache. But there is a way to > turn this off and make LRU as L1 and Bucket cache as a victim handler for L1. > It will be just L2. > After the off heap read path optimization Bucket cache is no longer slower > compared to L1. We have test results on data sizes from 12 GB. The Alibaba > use case was also with 12 GB and they have observed a ~30% QPS improve over > the LRU cache. > This issue is to remove the option for combined mode = false. So when Bucket > cache is in use, data blocks will go to it only and LRU will get only index > /meta/bloom blocks. Bucket cache will no longer be configured as a victim > handler for LRU. > Note : WHen external cache is in use, there only the L1 L2 thing comes. LRU > will be L1 and external cache act as its L2. That make full sense. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
