此时OpenTSDB没有内置缓存（除了将缓存PNG图像文件60秒的内置GUI）。因此只能依靠底层数据库的缓存。在HBase（最常见的OpenTSDB后端）中，有一个块缓存的概念，它可以在写入 和/或 读取时在内存中存储行和列的块。Nick Dimiduck的Block Cache 101是一个很好的入门书。设置缓存的一个好方法是使用BucketCache缓存并将L1缓存大小设置得相当大，这样它就可以充当写缓存并将大部分最新数据保存在内存中。然后，当用户运行查询时，L2缓存可以将经常查询的数据保存在内存中。
仔细观察region server的GC暂停。用户通常在堆外模式下运行bucket cache，但在堆外缓存命中和写入操作中，Java和JNI之间的序列化操作仍有一定的代价。
另外，请确保HBase表已启用压缩。块使用表中指定的压缩算法存储在内存中，因此与未压缩的块相比可以将更多压缩块放入缓存中。
如果通常在某个指标中查找一个或两个时间序列的查询（即多个标签值不同），请确保使用了2.3或更高版本且在查询中启用了explicitTags。查询必须列出与正在查找的数据相关联的所有标签key，但它会启用HBase上的特殊过滤器，这将有助于减少扫描的行数。详情请参阅查询过滤器。
或者，如果在指标名称中放置高基数的标签，这将大大减少查询时扫描的数据量并提高性能。请参阅编写数据以获取更多信息
对于将许多时间序列聚合在一起的查询，提高性能的最佳方法是在启用salting的情况下运行OpenTSDB 2.2或更高版本，并在HBase集群中运行多个regionserver。这将并行执行查询，从每个regionserver获取数据子集并合并结果。例如，对于单个regionserver，查询可能需要10秒才能完成。使用salting将相同的数据写入5个regionserver时，相同的查询大约花费2秒，它是由最慢的regionserver响应所需的时间决定的。合并集合通常是微不足道的。
如果在TSD和消费应用程序（例如UI或API客户端）之间观察到瓶颈，那么查看宽时间范围（例如几个月或几年）的查询可以使用降采样，并从中受益。使用降采样器将减少由TSD序列化并发送给用户的数据量。
但是，如果存储（HBase）和TSD之间存在瓶颈，那么最好的解决方案是使用OpenTSDB 2.4或更高版本开始写入上卷数据。这需要外部系统计算基于时间的上卷并将其写入存储。或者，UI或API客户端可针对较小时间范围跨度的多个TSD执行多个查询并将结果合并在一起。未来我们计划直接向TSD添加这些功能。
需要考虑的其他事项：
运行多个专用于读取数据的TSD，并在它们的前面放置负载均衡器。这是运行OpenTSDB时观察到的最常见的设置，允许在不关闭整个系统的情况下轮换升级TSD。
HBase有许多可以调整的参数，一般而言，大多数OpenTSDB的瓶颈都来自HBase。确保监视服务器，特别是队列，缓存，响应时间，CPU和GC。
没有数据库系统可以避免长时间运行或资源浪费查询。要求用户从较小的时间范围开始，如1小时，并逐渐增加时间范围。还有帮助用户了解基数，以及如何请求high_cardinality_tag_key=*可能是一个坏主意。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
