Tuning

与任何数据库一样，OpenTSDB 有许多调整参数可用于提高写入和读取性能。其中一些选项特定于某些后端，另一些则是全局的。

TSDB Memory

与任何服务器进程一样，调整 TSD 的内存占用量对于成功安装至关重要。 OpenTSDB 中有许多可以调整的缓存。

UID Caches

OpenTSDB 通过将字符串转换为二进制 UID 节省存储空间。但是，对于写入和查询，必须将这些 UID 缓存起来以提高性能(否则，每个操作都会放大针对存储的查询)。在早期版本的 OpenTSDB 中，无论操作模式如何，高速缓存都将维护字符串到 UID 的无界 Map 以及 UID 到字符串的无界 Map。在 2.4 中，您可以选择要缓存的数据量，还可以选择使用 LRU。相关设置包括：

  • 'tsd.uid.use_mode = true'-将其设置为 true 时，将检查 tsd.mode 值以确定是否填充了正向(字符串到 UID)Map 和反向(UID 到字符串)Map 中的一个或两个。当为空或设置为 rw 时，将同时填充两个 Map。设置为 ro 时，仅填充反向 Map(因为查询结果需要缓存)。在 w 或仅写入模式下，仅填充前向 Map，因为度量在写入时需要查找其 UID。

  • tsd.uid.lru.enable = true-切换到缓存的 LRU 版本，该版本将使一段时间内未读取的条目失效。

  • tsd.uid.lru.id.size =<integer>-对于专注于读取的 TSD，请将其设置为大于 tsd.uid.lru.name.size。

  • tsd.uid.lru.name.size =<integer>-对于专注于写入的 TSD，请将其设置为大于 tsd.uid.lru.id.size。

HBase Storage

这些是将 OpenTSDB 与 Apache HBase 一起使用时要查看的参数。

日期分层压缩

HBase 是 LSM 存储，意味着将数据写入内存中的块，然后按块刷新到磁盘，然后定期将磁盘上的这些块合并为更少的块，以减少文件数量和冗余。从磁盘读取和合并块的过程可能会消耗大量的 CPU 和内存，因此，如果系统负载了按时间 Sequences 写的流量，则后台压缩会开始影响写性能。 HBase 提供了各种压缩策略，包括“日期分层压缩”，它查看列的编辑时间戳，以确定是否应忽略未修改的陈旧文件并排列数据，从而使时间范围内的查询效率更高。

OpenTSDB 可以利用这种压缩策略(从 2.4 版本开始)来提高 HBase 性能，尤其是对于查询。要在 HBase 中设置日期分层压缩，请参见HBase Book。必须在 OpenTSDB 配置中设置的参数包括：

  • tsd.storage.use_otsdb_timestamp = true-默认情况下，每个数据点的编辑时间戳现在为。这会将时间戳更改为实际数据点的时间戳。请注意，汇总还没有使用此策略。

  • tsd.storage.get_date_tiered_compaction_start =<Unix Epoch MS timestamp>-在表上启用日期分层压缩器时的时间戳(以毫秒为单位)。如果要为 OpenTSDB 创建全新的表，则可以将其保留为默认值 0.

HBase 读/写队列

HBase 能够拆分处理 RPC 的队列以进行写入(变异)和读取。这对于 OpenTSDB 是一个巨大的帮助，因为海量查询将避免影响写入，反之亦然。有关各种配置选项，请参见HBase Book。请注意，不同的 HBase 版本对这些属性使用不同的名称。

可能的起始值为 50％或 60％。例如。 hbase.ipc.server.callqueue.read.share = 0.60 或 hbase.ipc.server.callqueue.read.ratio = 0.60，具体取决于 HBase 版本。

同样，调整调用队列的大小和线程也很重要。如果队列很大，则区域服务器可能会进行 OOM(如果有大量的写备份)，并且如果 RPC 位于队列中的时间太长，则 RPC 更有可能在 Client 端超时。队列大小是处理程序数量的一个因素。减小呼叫队列大小还有助于导致 Client 端限制，特别是 AsyncHBaseClient 端。对于 HBase 1.3，一个好的设置可能是 hbase.ipc.server.max.callqueue.length = 100 和 hbase.ipc.server.read.threadpool.size = 2.如果您需要增加线程，请也减少队列长度。

HBase Cache

调整 HBase 缓存对于查询也很重要，因为您要避免尽可能多地从磁盘读取数据(尤其是该磁盘为 S3 时)。尝试通过 hbase.bucketcache.combinedcache.enabled = true 和 hbase.bucketcache.ioengine = offheap 使用 offheap 缓存。给 offheap 缓存大量的 RAM，例如 hbase.bucketcache.size = 4000 用于 4GB 的 RAM。由于通常在读取时间序列时会查询最新数据，因此最好在写入时填充块缓存，然后将大部分空间用于最新数据。尝试以下设置：

hbase.rs.cacheblocksonwrite=true
hbase.rs.evictblocksonclose=false
hfile.block.bloom.cacheonwrite=true
hfile.block.index.cacheonwrite=true
hbase.block.data.cachecompressed=true
hbase.bucketcache.blockcache.single.percentage=.99
hbase.bucketcache.blockcache.multi.percentage=0
hbase.bucketcache.blockcache.memory.percentage=.01
hfile.block.cache.size=.054 #ignored but needs a value.

这会将黑色缓存的大部分分配给写操作，并将其缓存在内存中。

对于堆上缓存，您可以尝试分配以下内容：

hbase.lru.blockcache.single.percentage=.50
hbase.lru.blockcache.multi.percentage=.49
hbase.lru.blockcache.memory.percentage=.01

HBase Compaction

压缩是将磁盘上某个区域的多个存储合并为更少的文件以减少空间和查询时间的过程。您可以调整线程数和阈值以进行压缩，以避免在焦点应放在写入时使用过多资源。

hbase.hstore.compaction.ratio=1.2
hbase.regionserver.thread.compaction.large=2
hbase.regionserver.thread.compaction.small=6
hbase.regionserver.thread.compaction.throttle=524288000

HBase Regions

对于 OpenTSDB，我们已经观察到 10G 区域对于大型群集 hbase.hregion.max.filesize = 10737418240 是一个不错的大小。

HBase Memstore

尝试更频繁地将内存存储刷新到磁盘(和缓存)，特别是对于繁重的写入负载。我们已经看到 16MB 的 hbase.hregion.memstore.flush.size = 16777216 具有良好的行为。另外，尝试通过 hbase.regionserver.global.memstore.lowerLimit = .20 和 hbase.regionserver.global.memstore.upperLimit = .30 减小内存大小限制。

Name OpenTSDB 中文文档
Version
Language
Badge
Last Updated 2021-07-03T12:24:36