amazon-ec2 - redis服务器的最佳EC2设置

EC2可能不是在虚拟化硬件上运行Redis的最佳环境，但它很受欢迎，并且有很多要点可以从这个平台上获得Redis的最佳效果。

我是http://redis.io/topics/benchmarks和http://redis.io/topics/latency的作者之一，其中涵盖了我在下面提到的大部分主题。这只是要点的总结。

虚拟化费用

它不是特定于EC2，但是在VM上运行时Redis显着变慢（在支持的最大吞吐量方面）。这是由于基本操作的事实，Redis不会为处理客户端连接所需的epoll /读/写系统调用增加太多开销（如memcached或其他有效的键/值存储）。系统调用在VM上通常更昂贵，并且它们代表Redis活动的重要部分（特别是在基准测试中）。在这种情况下，与裸金属相比，最大吞吐量减少50％并不少见。

当然，它还取决于管理程序的质量。对于EC2，使用Xen。

在良好条件下进行基准测试

基准测试可能很棘手，尤其是在像EC2这样的平台上。经常被遗忘的一点是确保基准客户端和服务器的正确配置。例如，在针对您的Redis服务器时，不要在CPU缺乏的微实例（可能受亚马逊限制）上运行redis-benchmark。两台机器对于获得良好的最大吞吐量同样重要。

实际上，要评估Redis的性能，您需要：

在本地运行redis-benchmark（在与服务器相同的机器上），假设您有多个vCPU核心。
在QoS配置等同于服务器计算机的机器上远程（从不同的VM）运行redis-benchmark

因此，您可以评估和比较机器和网络的性能。

在EC2上，您将获得第二代M3实例（或高内存或集群计算实例）的最佳结果，这样您就可以从HVM（硬件虚拟化）中受益，而不是依赖于较慢的半虚拟化。

分叉问题

这不是特定于EC2，而是针对Xen：在Xen上分支大型进程可能非常慢（使用kvm看起来效果更好）。对于Redis，如果您计划使用持久性，这是一个大问题：持久性选项（RDB或AOF）都需要主线程来分叉并启动后台保存或重写过程。

在某些情况下，fork延迟可以将Redis事件循环冻结几秒钟。 Redis实例管理的内存越多，延迟就越多。

在EC2上，确保使用启用HVM的实例（M3，高内存，群集），它将缓解此问题。

然后，如果您有大量内存要求，并且您的应用程序可以容忍它，请考虑在同一台计算机上运行几个较小的Redis实例，并对您的数据进行分片。它可以将fork操作引起的延迟降低到可接受的水平。

持久性配置

这是从Redis（VM和裸机）获得良好性能的关键点。所以请花点时间仔细阅读http://redis.io/topics/persistence

如果您使用RDB，请记住，一旦保存后台进程已分离，内存写时复制机制将开始复制页面。所以你需要确保Redis本身有足够的内存，加上一些余地来应对COW。额外内存量取决于您的工作量。你在实例中写的越多，你需要的额外内存就越多。

请注意，写入文件也可能会占用一些内存（因为文件系统缓存），因此在Redis后台保存期间，您需要考虑Redis内存，COW开销和转储文件的大小。

运行Redis服务器的计算机绝不能交换。如果是这样，结果将是灾难性的。与其他一些商店相反，Redis不是虚拟内存友好的。

使用Linux时，请务必设置合理的系统参数：vm.overcommit_memory = 1和vm.swappiness = 0（或者无论如何都是非常低的值）。不要使用旧的内核版本：它们在执行低swappiness时非常糟糕（导致在写入大文件时进行交换）。

如果您使用AOF，请查看fsync选项。它是写操作的原始性能和持久性之间的权衡。您需要做出选择并定义策略。

您还需要熟悉EC2存储选项。在某些VM上，您可以选择临时存储和EBS。在其他一些人，你只有EBS。

短暂存储通常更快，并且您可能会比使用EBS获得更少的问题，但是在磁盘发生故障或重新启动主机等情况下您可以轻松地丢失数据...您可以想象将RDB快照放在短暂的情况下存储，然后将生成的文件复制到EBS目录，作为性能和稳健性之间的权衡。

EBS是远程存储：它可能会占用分配给VM的标准网络带宽，并影响Redis的最大吞吐量。如果您打算使用EBS，请考虑选择＆＃34; EBS优化的＆＃34;在标准网络和存储链路之间建立QoS的选项。

最后，EC2对性能要求较高的实例的一个非常常见的设置是停用主服务器上的持久性，并仅在从属实例上激活它。它可能对数据安全性较低，但它可以防止主机上出现许多潜在的延迟问题。

redis服务器的最佳EC2设置

1 个答案: