5 篇带有 "Capacity Planning" 标签的文章

在上一篇帖子中，我们开始了对我们的工作负载使用 quorum queues 的大小调整分析。我们专注于消费者保持同步的理想情况，意味着没有队列积压，并且集群中的所有 broker 都在正常运行。通过运行一系列基准测试，模拟我们在不同强度下的工作负载，我们确定了每 1000 msg/s 每月成本方面排名前 5 的集群大小和存储容量组合。

1. 集群：7 节点，8 vCPU (c5.2xlarge)，gp2 SDD。成本：$54
2. 集群：9 节点，8 vCPU (c5.2xlarge)，gp2 SDD。成本：$69
3. 集群：5 节点，8 vCPU (c5.2xlarge)，st1 HDD。成本：$93
4. 集群：5 节点，16 vCPU (c5.4xlarge)，gp2 SDD。成本：$98
5. 集群：7 节点，16 vCPU (c5.4xlarge)，gp2 SDD。成本：$107

还有更多测试要运行，以确保这些集群可以处理诸如 broker 故障和在中断或系统减速期间累积大量积压等情况。

所有 quorum queues 均使用以下属性声明

• x-quorum-initial-group-size=3
• x-max-in-memory-length=0

x-max-in-memory-length 属性强制 quorum queue 在安全时立即从内存中删除消息体。您可以将其设置为更长的限制，这是最激进的 - 旨在避免内存大量增长，但代价是当消费者跟不上时需要进行更多磁盘读取。如果没有此属性，消息体将始终保存在内存中，这可能会导致内存增长到触发内存警报的程度，从而严重影响发布速率 - 这是我们希望在本工作负载案例研究中避免的情况。

在本 sizing 系列的第一篇帖子中，我们介绍了 AWS ec2 上的工作负载、测试以及集群和存储容量配置。在这篇文章中，我们将使用 quorum queues 运行 sizing 分析。我们还对 mirrored queues 进行了 sizing 分析。

在这篇文章中，我们将在理想条件下运行增加强度测试，以衡量我们的候选集群大小在不同的发布速率下的表现。在下一篇文章中，我们将运行弹性测试，以衡量我们的集群是否可以在不利条件下处理我们的目标峰值负载。

所有 quorum queues 均使用以下属性声明

• x-quorum-initial-group-size=3 (复制因子)
• x-max-in-memory-length=0

x-max-in-memory-length 属性强制 quorum queue 在安全时立即从内存中删除消息体。您可以将其设置为更长的限制，这是最激进的 - 旨在避免内存大量增长，但代价是当消费者跟不上时需要进行更多磁盘读取。如果没有此属性，消息体将始终保存在内存中，这可能会导致内存增长到触发内存警报的程度，从而严重影响发布速率 - 这是我们希望在本工作负载案例研究中避免的情况。

在上一篇帖子中，我们开始了对我们的工作负载使用 mirrored queues 的大小调整分析。我们专注于消费者保持同步的理想情况，意味着没有队列积压，并且集群中的所有 broker 都在正常运行。通过运行一系列基准测试，模拟我们在不同强度下的工作负载，我们确定了每 1000 msg/s 每月成本方面排名前 5 的集群大小和存储容量组合。

1. 集群：5 节点，8 vCPU，gp2 SDD。成本：$58
2. 集群：7 节点，8 vCPU，gp2 SDD。成本：$81
3. 集群：5 节点，8 vCPU，st1 HDD。成本：$93
4. 集群：5 节点，16 vCPU，gp2 SDD。成本：$98
5. 集群：9 节点，8 vCPU，gp2 SDD。成本：$104

还有更多测试要运行，以确保这些集群可以处理诸如 broker 故障和在中断或系统减速期间累积大量积压等情况。

在本 sizing 系列的第一篇帖子中，我们介绍了 AWS ec2 上的工作负载、集群和存储容量配置。在这篇文章中，我们将使用 mirrored queues 运行 sizing 分析。

我们的 sizing 分析的第一阶段将是评估我们的每个集群和存储容量可以轻松处理哪些强度，以及哪些强度过高。

所有测试均使用以下策略

• ha-mode: exactly
• ha-params: 2
• ha-sync-mode: manual

这是一个简短系列的开始，我们将在此系列中研究 RabbitMQ 集群的大小调整。实际的大小调整完全取决于您的硬件和工作负载，因此我们不会告诉您应该配置多少 CPU 和多少 RAM，而是创建一些通用指南，并使用案例研究来展示您应该考虑的事项。