5 篇带有“容量规划”标签的帖子

在 上一篇文章 中，我们开始使用仲裁队列对我们的 工作负载 进行容量分析。我们专注于消费者能够跟上、队列没有积压且集群中所有代理程序都正常运行的理想情况。通过运行一系列基准测试，模拟不同强度的我们的工作负载，我们确定了每 1000 条消息/秒每月成本最低的前 5 个集群大小和存储卷组合。

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

还需要进行更多测试，以确保这些集群能够处理代理程序故障和因停机或系统减速而积压大量消息的情况。

所有仲裁队列都声明有以下属性

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

x-max-in-memory-length 属性强制仲裁队列在安全时尽快将消息体从内存中移除。您可以将其设置为更长的限制，这是最激进的设置——旨在避免内存大幅增长，但代价是在消费者跟不上时增加磁盘读取次数。没有此属性，消息体将始终保留在内存中，这可能导致内存增长到触发内存警报，严重影响发布速率——这是我们在本次工作负载案例研究中希望避免的。

在本系列的第一篇文章 中，我们介绍了工作负载、测试以及 AWS EC2 上的集群和存储卷配置。在本篇文章中，我们将进行仲裁队列的容量分析。我们还进行了 镜像队列的容量分析。

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

所有仲裁队列都声明有以下属性

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

x-max-in-memory-length 属性强制仲裁队列在安全时尽快将消息体从内存中移除。您可以将其设置为更长的限制，这是最激进的设置——旨在避免内存大幅增长，但代价是在消费者跟不上时增加磁盘读取次数。没有此属性，消息体将始终保留在内存中，这可能导致内存增长到触发内存警报，严重影响发布速率——这是我们在本次工作负载案例研究中希望避免的。

在 上一篇文章 中，我们开始使用镜像队列对我们的 工作负载 进行容量分析。我们专注于消费者能够跟上、队列没有积压且集群中所有代理程序都正常运行的理想情况。通过运行一系列基准测试，模拟不同强度的我们的工作负载，我们确定了每 1000 条消息/秒每月成本最低的前 5 个集群大小和存储卷组合。

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

还需要进行更多测试，以确保这些集群能够处理代理程序故障和因停机或系统减速而积压大量消息的情况。

在本系列规模分析的第一篇文章中，我们讨论了AWS EC2上的工作负载、集群和存储卷配置。在本文中，我们将进行镜像队列的规模分析。

我们规模分析的第一阶段将评估我们每个集群和存储卷能够轻松处理的负载强度，以及哪些负载过高。

所有测试均使用以下策略

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

这是我们开始查看 RabbitMQ 集群容量规划的短系列文章的开篇。实际容量规划完全取决于您的硬件和工作负载，因此，我们不会告诉您应该配置多少 CPU 和多少 RAM，而是会制定一些通用指南，并使用案例研究来展示您应该考虑的事项。