Broker缓存配置不起作用,直接内存使用率太低

ApachePulsar版本: 2.10.3
节点数: 3*16c64GB
部署方式: Google Kubernetes Engine

事情的起源:
我们的系统在做性能测试,当我们逐渐提高并发量时(最大15000/s)发现端到端的延迟极速增大。
首先我们想到了是因为系统的吞吐能力影响到了端到端延迟。于是我们优化了消费者的处理时间,并增加了消费者的数量。优化后如下:
1、消费者的消费一条消息的时间大概是10ms.
2、receiverQueueSize=25
3、消费者节点数为24

问题处理:
经过上述的优化之后我们发现端到端的延迟还是非常大。10000并发时很多消息的延迟超过了1500ms。
于是我们开始考虑是Broker的性能影响了系统的整体性能。于是我们查看了Broker的状态。
通过调用 “http://{admin-url}/admin/v2/broker-stats/load-report”得到了服务端的状态信息。结果我们发现

{
    "cpu": {
        "usage": 233.45526087333334,
        "limit": 1600.0
    },
    "memory": {
        "usage": 24826.014556884766,
        "limit": 32768.0
    },
    "directMemory": {
        "usage": 140.0,
        "limit": 32768.0
    },
    "bandwidthIn": {
        "usage": 9263.137999999957,
        "limit": 1.0E7
    },
    "bandwidthOut": {
        "usage": 62778.11333333254,
        "limit": 1.0E7
    }
}

配置了32GB的直接内存但是直接内存似乎并未被使用。并且所有的消息似乎都没有被缓存起来。

{
      "msgRateIn": 51.84564421671624,
      "msgThroughputIn": 5084.539491877754,
      "msgRateOut": 155.53692894004064,
      "msgThroughputOut": 15253.618111780303,
      "consumerCount": 64,
      "producerCount": 247,
      "topics": 24,
      "cacheSize": 0
  }

如果没有走缓存,是否也就意味着所有的读写都是直接走磁盘?如果是这样的话也就意味着只要能让缓存的命中率提高那么消息的处理速度就会变快。

通过查看官网的文档我们发现有几个关于缓存的配置:

*managedLedgerCacheSizeMB*

Amount of memory to use for caching data payload in managed ledger.
This memory is allocated from JVM direct memory and it’s shared across all the topics running in the same broker. By default, uses 1/5th of available direct memory

Type: int
Default: 347
Dynamic: true
Category: Storage (Managed Ledger)

从文档中我们发现似乎有1/5的直接内存会被用做缓存,可从Broker的状态指标中来看配置似乎没有生效。
于是我们尝试显式指定此参数值:

  managedLedgerCacheSizeMB: "10240"
  managedLedgerCursorBackloggedThreshold: "10000"
  managedLedgerCursorMaxEntriesPerLedger: "80000"
  managedLedgerDefaultAckQuorum: "2"
  managedLedgerDefaultEnsembleSize: "3"
  managedLedgerDefaultWriteQuorum: "2"
  managedLedgerNewEntriesCheckDelayInMillis: "0"

重启整个Pulsar集群之后我们还是发现配置没有生效?通过查看Broker的状态得到的结果和配置前一致?是哪里出了问题呢?

我们的目标是希望端到端的延迟能够稳定在8ms左右。
尝试了非持久化Topic,发现消息可靠性太低,有很多的消息发生了丢失。10000条消息最多只能收到600多条。

2 Likes

我认为可以先从磁盘的性能入手:
1)明确下磁盘的性能,比如IOPS和吞吐量指标
2)安装Prometheus,查看bookie的metic,可以反馈出jourtal和ledger各个阶段写入和读取的统计信息

另外,managedLedgerDefaultWriteQuorum: "2"可以改为3

我们使用过程中,非持久化topic的稳定性还是很好的。你反馈的这个丢失率不太正常,可能还需要进一步分析下是否是其他问题导致

以下是我们的PVC的使用情况,共三个节点,三个磁盘都是使用SSD。使用情况如下: