如何以1.68美元/小时的成本获取百万TPS

Amazon EC2等云基础设施已经在世界范围内证明了它的价值，其易于扩展、即开即用、按时计费等特性更彻底地解放了开发人员的创造性；然而请不要忽略，虚拟化环境曾一度被认为是应用程序及数据库的性能杀手。

尽管性能方面，云供应商一直在寻找着改善途径，但作为用户的我们，自己的性能优化手段也必不可少。在实体服务器上，Aerospike曾展示过百万TPS的峰值，而现在，我们则将致力于提升云应用的性能，彻底打破云不等于高性能这个流言。

我们做过各种各样的云实例对比，这里将展示的是基于C3.8xlarge，如何以每小时1.68美元的成本获得每秒百万事务数据库的性能。

以下博文为译文：

越高越好

这个报告记录了大量Amazon EC2实例上的实验，下面则是见证奇迹的时刻，如何调整参数和指令以得到如此等级的价格性能比。

除非另有说明，实验将忠实执行以下设置：

• 单Aerospike内存NoSQL数据库服务器运行在一个独立的Amazon实例上。
• 1000万个对象，每个对象大小在100字节（10 bins或者columns，每个大小10字节），我们尽可能的调整。让对象体积保持足够小，这样就可以将所有的研究对象放到内存中。
• 使用具备Java基准工具的 Aerospike Java客户端，客户端进程使用非服务器实例模式。最大化客户端负载，并将之并行连接到Aerospike服务器上，具体使用数量取决于所运行的服务器实例类型。
• 为了最大化Amazon基础设施上的负载，在内存中使用了分布在整个key space上的100%读负载。
• 我们使用 spot-Instances来节省成本，在性能测试期间Spot和按需实例的性能基本相同。

步骤1：选择实例类型

在选择实例时基本按照以下准则：可以内存支撑整个数据库；可以支撑事务速率的网络和CPU。

我们不考虑i2和hs1实例，因为尽管他们虽然具备高存储能力，但是却会限制应用程序的内存使用。

我们调研了大量的EC2实例类型：

R――内存密集

C――计算密集

M――R和C的平衡

T――1个入门级的主机

不同类型的实例拥有不同的网络能力，因此我们调研了每个类型，并测试他们的最高带宽限制，使用发包工具从尽可能多客户端推送更大体积的包。经过调研后，结果如下：

Moderate（上限是100MBps）

High（范围在300Mbps到1.8Gbps之间）

10 Gigabit（峰值在8.8 Gbps左右）

我们没有考虑t1和m1.small，因为Amazon给它网络性能标注为“Low”，这个主要鉴于在“Low”或者“Moderate”标注的实例上，网络性能往往会成为实例瓶颈。此外，测试时M系列实例还不具备增大网络的选项。

步骤2：选择虚拟机

Amazon使用的是Xen，一个支持半虚拟化（PV）和全虚拟化的开源虚拟化平台，同时Amazon还有硬件虚拟化选项。我们同时使用了两个类型：

• Para Virtualized Machine。首先，我们选择了c3.8xlarge。虽然它的成本很高，但是我们觉得仍然大有可为。开始时，我们在EC2-Classic网络中使用了一个PV AMI；但是随后我们发现，这些被标注10Gbps上限的机器只能获得1.8 to 2.2 Gbps的能力，主机的速率被限制到每秒8.5万包左右。而在测试了C3.2xlarge之后，我们发现这个主机仍然存在速度限制。再看CPU使用率，我们发现在半虚拟化主机中，严重负载下虚拟层的CPU使用率将达到恐怖的40%。使用这些主机，在Aerospike上我们可以获得8.5万TPS，速度限制再次出现。
• Hardware Virtualized Machine。在AWS的说明中，基于网络加强实例的HVM会提供更高的网络性能，用户每秒将获得更高的packets。而在根据我们的测试显示，在没有其他增项时，TPS足足增加了3倍。同等端配置中，使用具备网络增强的c3.4xlarge，Aerospike可以获得21.5万的TPS。

鉴于同等价格的性能差异，对比PV实例，我们以后的测试将只是用HVM类型。

步骤3：Use Placement Groups

Placement Groups是同一个Availability Zone中实例组成的逻辑组，在Amazon Virtual Private Cloud（VPC）中使用Use Placement Group允许应用程序低延时共享资源，完全平分10 Gbps网络。

我们使用Placement Groups来最大化性能，同时VPC是HVM实例的首要使用前提。

步骤4：Test Tenancy

我们分别测试了专用租用（dedicated tenancy）和共享租用（shared tenancy），在没有发现明显的差别后，我们果断的选择了共享租用。

步骤5：最小化CPU Stealing

在AWS上运行应用程序最大的隐患就是计算资源不可预知性，当CPU被过度使用时，比如一个线程突然间占用了太多的CPU，EC2则会结束这个线程的时间片。同时，在下一个时间片，Amazon只会给它分配较少的资源。这会导致应用程序吞吐量的跌宕起伏，这一点可以通过控制应用线程CPU。这样一来，我们就可以保证应用程序拥有更稳定的吞吐率。

在我们的测试中，Aerospike完全可以避免CPU过用。这将给我们带来可预知的性能，即使重度负载时，应用程序也很少受到CPU窃取监视影响（从0.2到0.7）。

步骤6：网络

在实例类型、VN、Placement Groups、租用和调谐选定后，我们仍然不能确定TPS受限方面。着眼实例，我们发现系统因为单核上的interrupt（中断）处理仍然存在瓶颈。每个NIC看起来只提供一个interrupt队列，默认绑定到一个单核心。因此，我们需要一个更灵活的解决方案，我们尝试了四种方法：

1. IRQ Distribution：我们尝试强迫系统将irq分布到多个核心上（disable irqbalance + echo ffff > *smp_affinity），而随后就发现它被绑定到一个独立的核心上。因此，一个独立的irq不能在多个核心上进行分配。

2. Interrupt Coalescing：在EC2上，Interrupt Coalescing对CPU利用率有些许提升，但是没有转化为更好的处理。

3. More NICs：在测试了这两个途径后，Elastic Network Interfaces（ENI）无疑是下一个必经之路。ENI让用户可以给实例增加多个（虚拟）NIC。单一的NIC峰值在25万TPS左右，增加多个接口可以增加程序的响应性，在两个实例上配置4接口和4客户端，我们可以在单c3.8xlarge实例上获得96万的TPS。通过确保每个客户端都推送到专用接口，从而可以利用所有的NIC和CPU。同时，使用具备私有IP的ENI并不会增加花费。

4. Receive Packet Steering：另一个简单的途径是使用RPS（“echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus”）将irp分配给多核心。这将避免使用多 NICs/ENIs，同时还避免了管理上的复杂度，并带来多ENI差不多的TPS。配置RPS的单NIC可以将TPS推到80万，通过跨4个核心的interrupt。

在测试过不同组合的NICs和RPS后， 通过一些Aerospike调优（比如适当的调整服务线程配置），我们可以达到非常高的性能――5个客户端（C3.2xlarge）加一个运行在C3.8xlarge上的单节点Aerospike集群可以达到百万的TPS，而花费仅仅是1.68美元每小时。

** DI = 按需实例

** RI = 预留实例

** All则是单实例给定类型的成本分析，3年和1年预留实例term计算都使用了重度负载（100%利用率）

NB：这些实例有时候体现着性能的好坏，这些数字都是一个月以上运行得出的结果。

* Core Bottleneck：我们尝试多种不同的NIC和RPS组合，但通常情况下会存在一个大量的%hi，同时会有个1核心被阻塞，峰值期间CPU利用率只有50%。

总结

以上解决方案体现了Amazon EC2已经可作为高性能数据库的一个选择，在AWS上使用Aerospike你可以花费1.68美元每小时的价格获得百万TPS。

• 使用AWS Marketplace在VPC中来设置一个基于c3.8xlarge实例Aerospike HVM，并将之作为一个服务器。使用一个AWS Marketplace。
• 为服务器实例搭载4个额外的ENI，没必要部署更多的Elastic IP。
• 运行afterburner.sh（cd /opt/aerospike/bin; sudo ./afterburner.sh）来最优每个Aerospike上的线程数量
• 使用AWS Marketplace来设置5个Aerospike c3.2xlarge实例，将这些使用了相同HVM和VPC的实例作为客户端，同时它们被布置在相同的Placement Group中作为服务器。
• 保证security group拥有3000-3003 TCP Port用于节点间的通信，同时为了使用AMC，TCP Port 8081需要对互联网开放。
• 给内存命名空间分配54GB的RAM（c3.8xlarge拥有60GB）
• 开启Aerospike服务器
• 通过Java基准客户端来加载数据

cd <java client>/benchmarks<br>./run_benchmarks-z 40 -n test -w I &nbsp;-o S:10 -b 10 -l 23 -k 10000000 -latency 5,1 -h YOUR_AWS_INTERNAL_IP

• 使用100%的读负载来运行服务器，为每个客户端指配独立ENI上的私有IP。

cd <javaclient>/benchmarks<br>./run_benchmarks -z 40 -n test -w RU,100 &nbsp;-o S:10 -b 10 -l 23 -k 10000000 -latency 5,1 -h YOUR_AWS_INTERNAL_IP

• 通过5个客户端，你可以获得百万TPS。

但是这仅仅是第一步，在下一篇文章中，我们将继续评估 4个Amazon实例价格性能比。到时候，我们将在内存中使用1个4节点Aerospike集群，同时将加载5个不同的读写负载。

原文链接：http://highscalability.com/blog/2014/8/18/1-aerospike-server-x-1-amazon-ec2-instance-1-million-tps-for.html

如您需要了解AWS最新资讯或是技术文档可访问AWS中文技术社区；如您有更多的疑问请在AWS技术论坛提出，稍后会有专家进行答疑。 

订阅“AWS中文技术社区”微信公众号，实时掌握AWS技术及产品消息！

AWS中文技术社区为广大开发者提供了一个Amazon Web Service技术交流平台，推送AWS最新资讯、技术视频、技术文档、精彩技术博文等相关精彩内容，更有AWS社区专家与您直接沟通交流！快加入AWS中文技术社区，更快更好的了解AWS云计算技术。

                                                                                                            （ 译者/薛童阳 责编/王玉平） 

生活不易，码农辛苦
如果您觉得本网站对您的学习有所帮助,可以手机扫描二维码进行捐赠