结合场景的HBase性能分析

2024年2月8日发(作者：)

ｏｕｄ　Ｃｏｍｐｕｔｉｎｇ云计算　结合场景的Ｈ　Ｂ　ａｓｅ性能分析　文，邓明鉴　在实际应用中，有很多细节能极大地影响ＨＢａｓｅ的性能。本文结合具体的应用场景对ＨＢａｓｅ的性能进行分　析，指出了影响其性能的具体细节和解决方法。　１Ｏ０　ＨＢａｓｅ是一个分布式、可扩展的基于ＨＤＦＳ的大数　据存储产品，可用于拥有海量数据的在线服务。　目前，Ｆａｃｅｂｏｏｋ、Ａｄｏｂｅ、ｅＢａｙ、Ｙａｈｏｏ！和３Ｗｉｔｔｅｒ　等国外大公司都在使用它。国内起步相对较晚，　因为不少人在做系统选型时对性能比较看重。我　认为作为一个平台级产品，性能确实很重要，但　它并不是一两个简单的Ｂｅｎｃｈｍａｒｋ可以说清楚　的，结合具体应用场景的分析更贴近实际应用。　关ｔＢｅｎｃｈｍａｒｋ　Ｎ　０　ＳＱＬ产品吸引人的地方通常是它们的　Ｂｅｎｃｈｍａｒｋ，因为它们的单机ＴＰＳ可以远远超过　关系型数据库，而且很多ＮｏＳＱＬ产品都能够做　水平扩展。但我们在追求高ＴＰＳ的同时也容易　走入一些误区，其中最重要的误区是没有分清　Ｂｅｎｃｈｍａｒｋ所针对的应用场景。虽然很多产品的　Ｂｅｎｃｈｍａｒｋ数！据看上去很高，但一到实际应用场　景中性能就上不去或者不能满足需求。造成这一　现象的原因就是实际应用中需要针对应用来设计　不同的参数，而不同的参数对性能的影响大不相　同。另外，不同的数据对性能的影响也需要考虑。　一般来说，实际应用场景通常是在项目开发时由　ＰＭ或ＰＤ评估出来的，包括以下这些情况。　・有多少热点数据？缓存命中率大约是多少。　＿读写比例如何。　－单条数据大小大约是多少，有多少列。　＿数据需要保存多久，总体数据有多大。　＿随机访问还是顺序访问。　－单连接还是多连接，批量请求还是单次请求。　・是否需要跨机房访问。　－是否会出现瓶颈在客户端的情况。　＿索弓『大，Ｊ、。　＿数据是否需要打开ｗＡＩ．。　・对响应时间的要求。　以上是一些常见的场景，还有一些是针对产品的　特殊场景，主要是依据存储产品的自身原理来总　结。比如，对ＨＢａｓｅ来说，数据是用３个备份因子　还是２个，ｃｏｍｐａｃｔ￣［ｂｐｌｉｔ是否可以关闭，等等。　图１展示了一些我们用过的性能测试场景，供各位　参考。　小结：在具体应用场景中做测试，得到的测试结　果通常和理论值差距非常大，所以产品标明的　Ｂｅｎｃｈｍａｒｋ通常只能做一个参考，我们必须详细　分析它为什么能达￣ｌｊＢｅｎｃｈｍａｒｋ［　数据，然后再　结合自身的应用做进一步的判断。　吞吐量和响应时间　对在线产品来说，衡量性能通常体现在两方面：　足够高的吞吐量和足够短的响应延时。足够高的　

Ｃｌｏｕｄ　Ｃｏｍｐｕｔｉｎｇ云计算　表１性能数据　ｌｄｖ＝５Ｏｂｙｔｅ／ｌＯＯｂｙｔｅ随机读　ｃｌｉｅｎｔ线程数　１ｃｆｌｑ　２０　ｌｃｆｌｑ　５０　ｌｃｆｌｑ　１０Ｏ　ｌｃｆｌｑ　２００　Ｑｐｓ　３４６０６　４２４４６　５０３７２　６４７Ｏ３　Ｒｅｓｐｏｎｓｅ　ｔｉｍｅ（ｍｓ）　Ｏ．５７　１＿２７　１．９８　３．０９　ｄａｔａｂｌｏｃｋｃａｃｈｅ实际命中率　１００％　１００％　１００％　１００％　∞０　■舢，壤　０ｔ¨　＿ｌ０赣　¨牲■瀚ｔ　０＃　ｕ啦ＭＩ雌　∞‘　●堆麓音壤ｌ球　ｊ白ｍ　Ｉ　白自ｈ　盘■■　∞０ＲＥｓＴｔｌ　翊ｌ∞ＲＥ　蚓＊　吞吐量意味着系统能承受更高的并发，足够短的　响应延时则意味着单次响应时间足够短。两者通　常需要一个折中。比如，我们在对ＨＢａｓｅ　Ｏ　９０做读　压力测试时，得到了表１中的一组性能数据。　简单说明一下，ｌｃｆｌｑ的意思是ｖａｌｕｅ体现为一个　ＣｏｌｕｍｎＦａｍｉｌｙ，并且只有１个ｑｕａｌｉｆｉｅｒ。这是最简　单的情况。客户端使用５台机器，第二行标明了　每个客户端使用多少线程并发读取。最后一行的　ｄａｔａｂｌｏｃｋｃａｃｈｅ区别于ＨＢａｓｅ日志中的命中率，它　是数据的命中率，排除掉了ｂｌｏｏｍｆｉｌｔｅｒ的命中率　（实际上ｂｌｏｏｍｆｉｌｔｅｒ的命中率很高，会造成命中率　看起来很高的假像）。　从表１可以看出，随着吞吐量的上升，响应时间也　在增加，但并不是一个反比关系。对在线服务来　说，响应时间通常有个最大接受值，所以可以先　确定最大可接受的响应时间，然后在这个范围内　尽可能多地提高吞吐量。　在吞吐量不大时，由于排除了排队、锁等因素，所　以响应时间可以达到理论值。　对ＨＢａｓｅ来说，写响应时间通常在２ｍｓ以内。原因　是每次写操作的顺序是先写ＷＡＬ再写ｍｅｍｓｔｏｒｅ，　都成功则返回给客户端，由于ｍｅｍｓｔｏｒｅ是本地的　内存操作，响应时间在微秒级，可以忽略不计，因　此时间主要消耗在客户端与服务器之间的ＲＰＣ通　信和写ＷＡＬ上。客户端与服务器的ＲＰＣ次数通常　只有一个来回，除非需要重新ｌｏｃａｔｉｏｎ（１ｏｃａｔｉｏｎ　的ＲＰＣ次数上限为３次，通常１次就够了）。而写　ＷＡＬ￣ＩＪ是执行ｄａｔａｎｏｄｅ的ｐｉｐｅｌｉｎｅ复制过程，顺序　地往本机及另外两台ｄａｔａｎｏｄｅ上写数据，再顺序　ａｃｋ回来。这个过程伴随着５次顺序的ＲＰＣ调用。　而在每台ｄａｔａｎｏｄｅ上写数据则是一个顺序写的　过程（ｈｌｏｇ的ａｐｐｅｎｄ是顺序写），并且通过撰作　系统的ｐａｇｅｃａｃｈｅ来缓冲，因此写数据本身的时　间是非常快的，接近内存操作的速度。因此，整　个写响应的理论时间为６～９次ＲＰＣ调用的时间，　按０　１～Ｏ．２ｍｓ的ＲＰＣ时间计算，写响应时间通常　＜２ｍｓ。　读响应时间则完全取决于命中率，如表１所示，内　存命中率为１００％时，响应时间最短可为０　５７ｍＳ，　如果是单线程会更快。内存完全命中时，响应　时间就是１～３次ＲＰＣ的请求时间。而内存不命中　时，响应时间就取决于Ｉ／Ｏ次数了。从原理上讲，　ＨＢａｓｅ一次读操作所需要的Ｉ／０如下。　．　＿读取每个ｓｔｏｒｅｆｉｌｅ的ｃｈｅｃｋｓｕｍ文件，判断文件是　否完整。　＿读取每个ｓｔｏｒｅｆｉｌｅ的ｂｌｏｏｍｆｉｌｔｅｒ，判断数据是否　在该文件中。　－如果ｂｌｏｏｍｆｉｌｔｅｒ为真，则读取该ｓｔｏｒｅｆｉｌｅ的　ｂｌｏｃｋｉｎｄｅｘ，来找到对应的ｂｌｏｃｋ。　＿读取该ｂｌｏｃｋ，并加载￣ｌＪｂｌｏｃｋｃａｃｈｅ中。　其中，ｂｌｏｃｋｉｎｄｅｘ只要读取一次就长驻内存不淘　汰，因此大多数情况下Ｉ／Ｏ次数是２ｎ＋ｍ次，ｒ　为　ｓｔｏｒｅｆｉｌｅ的数量，ｍ为所请求的数据在几个ｓｔｏｒｅｆｆｌｅ　中（由于有版本的概念，通常所请求的数据很　有可能同时在多个ｓｔｏｒｅｆｉｌｅ中）。ＳＡＴＡ盘的隧机　Ｉ／Ｏ时间大约为８ｍｓ，因此完全不命中时读响应　时间大约在２０ｍｓ左右。新版本的ＨＢａｓｅ在提高　读性能方面做了很多优化，比如提高对元数据　（ｂｌｏｏｍｆｉｌｔｅｒ）的Ｃａｃｈｅ￣ｆｆ力，把ｃｈｅｃｋｓｕｍ这一次　Ｉ／Ｏ想办法省去（读本地文件时不读ｃｈｅｃｋｓｕｍ，　或者￣Ｅｃｈｅｃｋｓｕｍ信息写￣１］ｈｆｉｌｅ中）。此外，还有　ｌａｚｙｓｅｅｋ（非常重要的一项优化，０．９４以上版本）　让读的ｓｔｏｒｅｆｉｌｅ尽量少、ｃｏｍｐａｃｔ优化算法等一系　列优化都是为了减少ｎ和ｍ的值。　１０１　

ｏｕｄ　Ｃｏｍｐｕｔｉｎｇ云计算　为了在实际应用中满足响应延时的问题，还需要　ｉｎｄｅｘ￣读ｄａｔａ，而ｉｎｄｅｘ长驻内存因此命中率接近　对慢连接进行监控，也就是把每次响应的时间都　１００％。命中率可以通过ｒｅｇｉｏｎｓｅｒｖｅｒ的ｌｏｇ文件来　ｉａ来获得。　统计下来，定期发给监控系统。这一点在０　９２以　获取，或者通过ｇａｎｇｌ上的版本中己得到支持。但为了取得更详细的数　我们需要想办法尽可能多地提高内存命中率，　据，恐怕还需要根据自己的需求去修改代码。　比如减／ｊ￣ｒｏｗｋｅｙ大小，将版本数设置为１，设置　至于吞吐量的性能分析，主要取决于排队等候的　合理的ＴＴＬ。及时清理掉不必要的Ｃａｃｈｅ，比如　时间和锁粒度等。“ｈｂａｓｅ．ｒｅｇｉｏｎｓｅｒｖｅ血ａｎｄｌｅｒ　“ｈｂａｓｅ．ＩＳ．ｅｖｉｃｔｂｌｏｃｋｓｏｎｃｌｏｓｅ”参数（Ｏ　９２以上版　ｃｏｕｎｔ”是一个重要的参数，它决定服务器端最　本）等。　多启动多少个线程来同时处理ＲＰＣ请求。一般设　・负载均衡。分布式环境中需要充分利用各台主　置１００－２００个线程可以极大提高吞吐量。排队的　机的性能，因此负载均衡是很重要的。当ｒｏｗｋｅｙ　ＲＰＣ长度限度为ｈａｎｄｌｅｒ数量ＸｌＯ０，可以通过系统　完全散开后，理论上每台服务器的ＴＰＳ应该是平　监控来看实时的排队长度。如果排队长度始终为　均的。ＨＢａｓｅ［￣带的ｂａｌａｎｃｅｒ线程默认每５分钟工　０，则说明服务器端还有能力并发处理更多的请　作一次，将ｒｅｇｉｏｎ数平均分配到所有服务器上。但　求。很多时候吞吐量的瓶颈其实是客户端无法提　这并不是一个很好的选择，比如集群中有一大一　供更多的并发请求了，此时可以尝试让客户端以　小两张表，很有可能小表的ｒｅｇｉｏｎ全部集中在一　多连接（注意区别于多线程）的方式请求服务器　台机器上，但总的来说ｒｅｇｉｏｎ是均衡的。这种情况　端（ＨＢＡＳＥ一２９３９）。　下对小表的请求很有可能全部集中在一台机器上　小结：在性能测试中要注意吞吐量和响应时间。　一了。因此我们需要做表级别的ｂａｌａｎｃｅ。Ｏ．９４　０版本　ＨＢＡＳＥＨＢａｓｅ一３３７３），我　般情况下，我们应该先保证响应时间在一定范　己经有这样的功能了（们也可以很轻松地在之前的版本上实现。　实时监控请求分布是很重要的运维手段。如果　围内，然后再尽可能多地提高吞吐量。　热点数据、负载均衡及ｓｔｏｒｅ￣ｌ：］ｓｔｏｒｅｆｉｌｅ的数量是影Ｐｌ￣ＨＢａｓｅ　性能的几个关键因素。　几个关键因素　以下是影响ＨＢａｓｅ性能的几个关键因素。　＿热点数据。热点数据即经常需要读取的数据。从　上面的分析可以看出有没有命中内存，读性能的　差距是两个以上的数量级，因此内存命中率对性　能非常重要。　ＨＢａｓｅ￣带ｂｌｏｃｋｃａｃｈｅ，大小由“ｈｆｉｌｅ．ｂｌｏｃｋ　ｃａｃｈｅ　ｓｉｚｅ”参数决定。它能将每次读取到的数据以　负载不均衡，那么系统的性能测试是极为不准确　的。因此需要把请求的分布实时统计下来，并定　期发到监控系统展示。　＿ｓｔｏｒｅ和ｓｔｏｒｅｆｉ１ｅ的数量。ｓｔｏｒｅ是ＨＢａｓｅ的ＣＦ　（ＣｏｌｕｍｎＦａｍｉｌｙ），每一个列簇是一个ｓｔｏｒｅ。一　般在设计的时候尽量不要使用过多的ＣＦ，因为当　前版本的ＨＢａｓｅ在支持过多的ＣＦ时会有一些使用　上的问题。比如，文件数会过多，多个ＣＦ在ｆｌｕｓｈ　的一瞬间会有短暂的不一致（近期有些Ｐａｔｃｈ在改　进）；ｍｅｍｓｔｏｒｅ过多等。一般尽量将列簇限制在３　个以内，而尽量多地利用列。而且对同一行不同　列簇的操作是串行的，因此性能上会有一定的影　响。表２是我们针对多列簇的测试结果。　可以看出，列簇增加１倍，随机读的响应时间增加　１倍，而列增加则对洼能影响不大。　ｓｔｏｒｅｆｉｌｅ是同一个列簇下的文件数目。文件数过　６４ＫＢ为单位缓存起来，即一次随机读的最小单　位是６４ＫＢ，因此在设计上尽量将需要批量读取的　数据前缀设置为相同或相近，这样可以极大减少　随机Ｉ／Ｏ次数。　ｇｅｔ命中ｂｌｏｃｋｃａｃｈｅ时，会直接返　回。假设每台服务器有１０ＧＢ可用于ｂｌｏｃｋｃａｃｈｅ，　　那么２Ｏ台机器就能缓存２００ＧＢ的数据。假设总数　多，会导致读响应变慢，这个前面己经分析过了，据为１ＴＢ，那么命中率为７０％（５０％＋０　２／１）。这　但好处是写会变快，原因是写入不受历史数据的　或放　里的５０％是ｂｌｏｃｋｉｎｄｅｘ，由于每次读取需要先读　影响。为了追求写入性能，可以关闭ｃｏｍｐａｃｔ１０２　

Ｃｌｏｕｄ　Ｃｏｍｐｕｔｉｎｇ云计算　［￣ｃｏｍｐａｃｔ的速度，但为了追求读的性能，需要适　表２礁机读性能溅试　当加快ｃｏｍｐａｃｔ的速度，比如使用多线程ｃｏｍｐａｃｔ　（Ｏ　９２以上版本）。这个需要根据应用的读写情况　进行适当的取舍。　另外，对于读取类应用来说，ＢｌｏｏｍＦｉｌｔｅｒ是必须　设置的属性。如果列多的话，那么要尽量设置为　ｋ／ｖ＝５Ｏｂ／ｌＯＯｂ随机　线程数　ｌｃｆｌｑ　２０　ｌｃｆ２ｑ　２０　２ｃｆ２ｑ　２０　２ｃｆ２ｑ　２０　Ｑｐｓ（草￣ｓｅｒｖｅｒ）　Ｒｅｓｐｏｎｓｅ　ｔｉｍｅ（ｍｓ）　ＣＰＵ１ｏａｄ　９４７６　２．３６　６．９６　９５１４　２．１　６．８６　４２５０　４＿７　１２．１４　４７０２　４－２５　１５．５７　ｄａｔａｂｌｏｃｋｃａｃｈｅ命中率　６０－２９％　６０．３９％　６０．９％　５８．８７％　ｅｇｉｏｎ．ｍａｘ．ｉｆｌｅｓｉｚｅ”，比如可以设成６４ＧＢ。这样　“ＲＯＷ”属性。如果是宽表（一行中有成百上千　ｈｒｉｔ发生，从而提高系统的写入稳　列），则可以考虑设置为“ＲＯＷＣＯＬ”属性。通常　可以基本避免ｓｐｌ系统ＩＯＷａｉｔ飙升都是由于ＢｌｏｏｍＦｉｌｔｅｒ没有设置造　成的。　小结：我们需要尽可能多地提高数据的命中率，　并根据命中率来推算需要的服务器数量。我们　需要尽量保持服务器的负载均衡，并调整适当的　ｂａｌａｎｃｅ策略。对读应用来说，要让ｓｔｏｒｅｆｉｌｅ文件数　尽量少，尽量使用列而不是列簇。　ｃｏｍｐａｃｔ和ｓｐｌｉｔ的影响　如前面所说，ｃｏｍｐａｃｔ可以影响读写性能。ｓｐｌｉｔ也　一样，影响会更加严重。　・ｃｏｍｐａｃｔ的影响：ｃｏｍｐａｃｔ期间会将原有的　ｓｔｏｒｅｆｉｌｅ合并成一个新的ｓｔｏｒｅｆｉｌｅ，这期间会增加　网络和磁盘的Ｉ／Ｏ，因此会对系统整体性能造成一　定的影响。如果￣ＨＤＦＳ层加大是一个缓解的办　法，比如一个ＨＤＦＳ集群上搭建多个ＨＢａｓｅ集群，　那么ｃｏｍｐａｃｔ的Ｉ／Ｏ冲击就平摊到了一个大的　ＨＤＦＳ集群上，问题会相对较小。但如果ｃｏｍｐａｃｔ　采用默认的串行执行方法，则会在某些写压力很　大的应用上堆积较长的ｃｏｍｐａｃｔ队列。这会影响　￣ｈｌｏｇ的滚动和回收，并且对读性能也有不利影　响。所以建议对ｃｏｍｐａｃｔ队列做监控，如果真的会　有很长的队列，那么采用多线程ｃｏｍｐａｃｔ会有很　大帮助。　－ｓｐｌｉｔ是在单个ｒｅｇｉｏｎ过大时可以自动切分成两个　ｒｅｇｉｏｎ，这期间所有该ｒｅｇｉｏｎ的请求会失败，所以　我们尽量缩短ｓｐｌｉｔ的时间或者减ｓｊ￣ｓｐｌｉｔ的次数。　一个有效的办法是增大ｒｅｇｉｏｎ的上限，让ｓｐｌｉｔ次数　减少，另一个有效的办法是建表时通过对应用数　据的分析做出合适的ｐｒｅ—ｓｈａｒｄｉｎｇ（预分区）。　我们这里只分析第一种办法，因为这是系统层　面的办法。增）￣Ｎｒｅｇｉｏｎ大小的参数是“ｈｂａｓｅ　定性。但增加这个值会带来以下几个问题。　＿首先是ｃｏｍｐａｃｔ的压力会加大，因为要合并的文　件更大了；　－其次是由于ｃｏｍｐａｃｔ变得更慢，导致要读的：之件　更多了，读响应下降；　・最要命的是大文件使ｉｎｄｅｘ变大，甚至到达几百　ＭＢ或几ＧＢ，占用大量内存而且使加载速度变慢。　ＨＢａｓｅ　Ｏ．９２以上的版本部分解决了这些问题　比　如优化了ｃｏｍｐａｃｔ逻辑，让ｃｏｍｐａｃｔ去优先选择小　文件合并，尽量减少大文件的重复合并，又比如　使用ＨＦｉｌｅＶ２让ｉｎｄｅｘ由平面结构变成树状结构，　大大减小了ｉｎｄｅｘ的大小。所以建议对ｓｐｌｉｔ比较敏　感的用户尽量使用０　９２以上的版本。　小结：使用大ＨＤＦＳ集群可以有效降￣ｃｏｍｐａｃｔ的　影响，但需要注意ｃｏｍｐａｃｔ队列的堆积。ｓｐｌｉｔ对系　统稳定性的影响更大，建议通过ｐｒｅ—ｓｈａｒｄｉｎｇ以　及增大ｒｅｇｉｏｎ的方式来解决这个问题。采用增大　ｒｅｇｉｏｎ的方法尽量要采用０　９２以上的版本，并注意　读性能是否有下降。　ｄａｔａｎｏｄｅ的选择　ＨＢａｓｅ底层的文件存储采用了ＨＤＦＳ，因此ＨＤＦＳ　本身的性能也可以影［￣ＪＨＢａｓｅ。　２０１１年的Ｈａｄｏｏｐ　Ｗｏｒｌｄ大会上ｔｏｄｄＴｏｄｄ　Ｌｉｐ—ｓｏｎ　有一场经典的ｔｏｐｉｃ精彩的演讲，讲他们如何优　化ＨＤＦＳ。另外，Ｆａｃｅｂｏｏｋ也提到过他们如何优　化ＨＤＦＳ让它更适合做实时应用。总结起来看，　ＨＤＦＳ在１　０以及Ｃｌｏｕｄｅｒａ　３ｕ３以上的版本中性能有　明显的突破，主要体现在以下几点上。　－ｃｈｅｃｋｓｕｍ大小可配置。可将原先的５１２字节做一　次ｃｈｅｃｋｓｕｍ￣［［置￣６４ＫＢ做一次，并且采用＿＝　优　化的ＣＲＣ３２算法，让ＣＰＵ的消耗大大降低。　１０３　

ｌｏｕｄ　Ｃｏｍｐｕｔｉｎｇ云计算　＿用Ｓｏｃｋｅｔ缓存。通过Ｋｅｅｐａｌｉｖｅ机制来复用连接，　内存方式，可以通过配置项来打开。但要记住在　减少大量重复新建连接的开销，并且重写了　ｒｅｇｉｏｎ数过多的场景下不可以使用ｍｓｌａｂ，它有可　ＢｌｏｃｋＲｅａｄｅｒ，消除了不少数据拷贝。这一项我们　能引起ＯＯＭ。　测试随机读有１３％、随机写有３％的性能提高。　对于大内存的管理，Ｊａｖａ的ＧＣ会有～定影响，将　・增加了本地读模式。如果判断到数据在本机，则　来的Ｇ１有可能从根本上改善这一状况，但目前Ｇ１　直接跳过与ｄａｔａｎｏｄｅ的通信，用直接调用文件系　还不太稳定，如果面对３２ＧＢ、４８ＧＢ或更大的内　统接口来访问数据，并且由于数据在本机，可以　存，除了调整ＪＶＭ参数外，使用ｎａｔ￣ｅ来管理内存　忽略ｃｈｅｃｋｓｕｍ这一步。这样～来随机读的Ｉ／Ｏ次　也是一条路径。　１０４　数直接减少一半，实际测试结果也证明了这一　点：仅这一项优化我们测试随机读性能可以增加　１００％以上。　另外，例如出错时重试机制的调整、Ｌｅａｓｅ的及时　释放等改进，都是针对实时应用所做的调整。自　２０１　１年以来，ＨＤＦＳ层面的优化大大提高了ＨＢａｓｅ　的性能。由于Ｈａｄｏｏｐ的版本分支非常多，目前性　能有大的优化并且稳定的版本还是Ｃｌｏｕｄｅｒａ　３ｕ３　以上，以及社区的１　０（Ｏ　２０　２０５）以上版本，可以　参考选择。　小结：不同的ＨＤＦＳ版本对ＨＢａｓｅ的性能影响也是　不同的，需要多关注。　ＧＣ的影响　之前Ｈｙｐｅｒｔａｂｌｅ的作者曾经认为，在ＨＢａｓｅ与　Ｈｙｐｅｒｔａｂｌｅ的性能对比中，让ＨＢａｓｅ落败的主要　原因是ＧＣ。这其实是一个比较片面的观点。读完　前面的内容，你应该比较清楚在实际应用中很多　细节的影响其实要远远超过语言层面那一点点优　化。当然，在理想状况下，ＧＣ的作用就会略为明　显，但最多只有１％左右的影响。　在系统压力～般的情况下，比如８核ＣＰＵ的ｌｏａｄ在　３－４左右时，我们观察到的ＧＣ时间大约占０　５％左　右，也就是说每１ｓ会有５ｍｓ左右的Ｙｏｕｎｇ　ＧＣ暂停　时间（２ＧＢ　Ｙｏｕｎｇ区），而ＣＭＳ　ＧＣ的频率并不频　繁，影响也ｂｈＹｏｕｎｇ　ＧＣ更小。但在系统上线前最　好多关注一下ＪＶＭ参数，尽量避免Ｙｏｕｎｇ区频繁　ＧＣ，以及避免发生Ｆｕｌｌ　ＧＣ。在多列簇的情况下，　ｔＬ￣Ｈ２－３个列簇，由于碎片的增加，在很高的压力　下发生ＣＭＳ　ＧＣ失败并引发Ｆｕｌｌ　ＧＣ是一件危险的　事，有可能引发长时间的ＧＣ，这一点需要多关注　ＧＣ日志。这个问题的解决方案可以是ｍｓｌａｂ分配　小结：ＧＣ对性能的影响只是理论上的，并不足以　改变ＨＢａｓｅ的整体性能。但对于稳定的线上应用　来说，需要密切关注和监控ＧＣ的情况，避免出现　长时Ｉ￣］ＧＣ的事故。　总结　ＨＢａｓｅ的性能分析应该结合具体的场景，并对测　试结果进行仔细分析，以便为线上应用提供尽可　能合适的参数。目前ｈｂＨＢａｓｅ版本变化非常快，有　很多性能优化点正在进行中，总体来说０　９２版本己　经比较稳定，可以尝试在生产环境中使用。＠　■　责阿改规丰邓任里进划富明编集淘及的鉴线辑宝运团　上：核版维应杨本支心用爽Ｈ持系Ｂ经统ａ，（ｓ熟验ｙｅ部ａ，悉。ｎ技　ｇ负各ｓ术ｈ责版ｕ专ａＨ本家Ｂｎｇ，ｓ＠ｅａ现的ｃｓ主线ｄ源ｎ导上码　维部ｅ，ｔ护署并）　和有、