Pulsar brokers acknowledge a write once the ack quorum of bookies confirms it, so the slowest bookie in each ensemble sets the latency floor. A single node with a saturated journal device degrades write latency across every topic whose ledgers touch it. AceMQ isolates the bookie and fixes the storage layout underneath.
The usual root cause is journal and ledger data sharing a device. The journal needs low-latency sequential fsync; the ledger device does large sequential writes and periodic compaction. Together on one disk they contend, journal fsync latency climbs, and add-entry latency rises cluster-wide. Contributing factors include an ensemble and quorum configuration with no headroom for a slow node, an undersized write cache, and garbage collection on the entry log competing with live traffic.
Apache Pulsar with BookKeeper on Kubernetes or bare metal, ZooKeeper or etcd metadata, and tiered offload to object storage.
AceMQ correlates per-bookie journal fsync and add-entry latency against broker-side publish latency to identify which node is setting the floor, then confirms whether the cause is device contention, cache sizing, or compaction. The immediate action isolates the bookie from new ensembles; the durable fix separates journal and ledger devices and retunes cache and compaction.
Cluster-wide publish latency returns to its baseline once the constraining bookie is isolated and the storage layout corrected, and the revised quorum configuration means the next slow node degrades gracefully rather than stalling the cluster.
Diagnosing producers blocked by backlog quota enforcement when a slow or abandoned subscription prevents the backlog from clearing.
Sizing brokers, bookies, and metadata for a Pulsar deployment against real throughput, retention, and durability requirements.
Whether you need architecture advisory, 24/7 support, or full managed services, AceMQ has the expertise to help.