存档

2011年6月 的存档

MySQL单机多实例方案,是指在一台物理的PC服务器上运行多个MySQL数据库实例,为什么要这样做?这样做的好处是什么?
1.存储技术飞速发展,IO不再是瓶颈
普通PC服务器的CPU与IO资源不均衡,因为磁盘的IO能力非常有限,为了满足应用的需要,往往需要配置大量的服务器,这样就造成CPU资源的大量浪费。但是,Flash存储技术的出现改变了这一切,单机的IO能力不再是瓶颈,可以在单机运行多个MySQL实例提升CPU利用率。
2.MySQL对多核CPU利用率低
MySQL对多核CPU的利用率不高,一直是个问题,5.1版本以前的MySQL,当CPU超过4个核时,性能无法线性扩展。虽然MySQL后续版本一直在改进这个问题,包括Innodb plugin和Percona XtraDB都对多核CPU的利用率改进了很多,但是依然无法实现性能随着CPU core的增加而提升。我们现在常用的双路至强服务器,单颗CPU有4-8个core,在操作系统上可以看到16-32 CPU(每个core有两个线程),四路服务器可以达到64 core甚至更多,所以提升MySQL对于多核CPU的利用率是提升性能的重要手段。下图是Percona的一份测试数据:

3.NUMA对MySQL性能的影响
我们现在使用的PC服务器都是NUMA架构的,下图是Intel 5600 CPU的架构:

NUMA的内存分配策略有四种:
1.缺省(default):总是在本地节点分配(分配在当前进程运行的节点上);
2.绑定(bind):强制分配到指定节点上;
3.交叉(interleave):在所有节点或者指定的节点上交织分配;
4.优先(preferred):在指定节点上分配,失败则在其他节点上分配。
因为NUMA默认的内存分配策略是优先在进程所在CPU的本地内存中分配,会导致CPU节点之间内存分配不均衡,当某个CPU节点的内存不足时,会导致swap产生,而不是从远程节点分配内存。这就是所谓的swap insanity现象。
MySQL采用了线程模式,对于NUMA特性的支持并不好,如果单机只运行一个MySQL实例,我们可以选择关闭NUMA,关闭的方法有三种:1.硬件层,在BIOS中设置关闭;2.OS内核,启动时设置numa=off;3.可以用numactl命令将内存分配策略修改为interleave(交叉),有些硬件可以在BIOS中设置。
如果单机运行多个MySQL实例,我们可以将MySQL绑定在不同的CPU节点上,并且采用绑定的内存分配策略,强制在本节点内分配内存,这样既可以充分利用硬件的NUMA特性,又避免了单实例MySQL对多核CPU利用率不高的问题。

资源隔离方案
1.CPU,Memory
numactl –cpubind=0 –localalloc,此命令将MySQL绑定在不同的CPU节点上,cpubind是指NUMA概念中的CPU节点,可以用numactl –hardware查看,localalloc参数指定内存为本地分配策略。
2.IO
我们在机器中内置了fusionio卡(320G),配合flashcache技术,单机的IO不再成为瓶颈,所以IO我们采用了多实例共享的方式,并没有对IO做资源限制。多个MySQL实例使用相同的物理设备,不同的目录的来进行区分。
3.Network
因为单机运行多个实例,必须对网络进行优化,我们通过多个的IP的方式,将多个MySQL实例绑定在不同的网卡上,从而提高整体的网络能力。还有一种更高级的做法是,将不同网卡的中断与CPU绑定,这样可以大幅度提升网卡的效率。
4.为什么不采用虚拟机
虚拟机会耗费额外的资源,而且MySQL属于IO类型的应用,采用虚拟机会大幅度降低IO的性能,而且虚拟机的管理成本比较高。所以,我们的数据库都不采用虚拟机的方式。
5.性能
下图是Percona的测试数据,可以看到运行两个实例的提升非常明显。

高可用方案
因为单机运行了多个MySQL实例,所以不能采用主机层面的HA策略,比如heartbeat。因为当一个MySQL实例出现问题时,无法将整个机器切换。所以必须改为MySQL实例级别的HA策略,我们采用了自己开发的MySQL访问层来解决HA的问题,当某个实例出问题时,只切换一个实例,对于应用来说,这一层是透明的。
MySQL单机多实例方案的优点
1.节省成本,虽然采用Flash存储的成本比较高,但是如果可以缩减机器的数量,考虑到节省电力和机房使用的成本,还是比单机单实例的方案更便宜。
2.提升利用率,利用NUMA特性,将MySQL实例绑定在不同的CPU节点,不仅提高了CPU利用率,同时解决了MySQL对多核CPU的利用率问题。
3.提升用户体验,采用Flash存储技术,大幅度降低IO响应时间,有助于提升用户的体验。
–EOF–
关于NUMA可以参考这篇文章:NUMA与Intel新一代Xeon处理器

6 28th, 2011 | Filed under 大话技术
标签: , ,

测试环境:Dell R510,2×E5620,24G,Fusion-io ioDrive 320G MLC
测试工具:Redhat Linux 5.3,Oracle Orion 11
测试一:8K随机读,IOPS超过5W,吞吐量超过400M,响应时间在IOPS达到4W时出现拐点(超过1ms),并迅速上升至最高值9.5ms。

########################################################
测试二:4K随机读,IOPS超过7W,吞吐量达到280M,响应时间在IOPS达到7W时保持在1ms以下,随着并发压力不断增大,IOPS出现波动,响应时间逐步增加。

########################################################
测试三:128K连续读,IOPS迅速上升至5000时,到达吞吐量瓶颈(700M),此时响应时间小于10ms,随后并发压力增大,IOPS与吞吐量指标无变化,响应时间迅速上升。

########################################################
测试四:8K随机写,IOPS到达5.8W,响应时间为1ms,随着压力增大,IOPS逐步下降,响应时间随之快速上升。

########################################################
测试五:读写混合模式,8K随机IO,20%写,IOPS到达4.5W,吞吐量360MB,响应时间在IOPS达到3.7W时保持在1ms左右,随着压力增长,响应时间迅速增加。

########################################################
测试六:读写混合模式,8K随机IO,128K连续IO,20%写,IOPS达到5W,吞吐量580MB,响应时间在IOPS达到4W时保持在1ms左右,随着压力增加,响应时间快速增加。

性能分析:
本次性能测试直接读写fusionio卡,无任何缓存的影响,从测试数据我们看出,ioDrive的随机读性能非常好,4k IO的性能最佳,可以达到7W IOPS,8K IO可以达到5W IOPS,响应时间稳定在1ms以下。随机写的表现也非常优秀,8K随机写可以达到5W+。IOPS,响应时间保持在1ms以下。模拟数据库的8K随机IO和128K连续IO,IOPS可以稳定达到4W左右。总之,ioDrive的表现非常优秀。
瓶颈分析:
存储的瓶颈有两个:一个是IOPS,另一个是吞吐量。对于传统磁盘来说,单块盘的IOPS为150,如果每个IO最大为1MB,那么我们可以计算出磁盘的吞吐量瓶颈为150MB(实测吞吐量大致为170-250MB)。我们可以看到,IOPS是磁盘真正的瓶颈,随机IO对磁盘是致命的,而吞吐量对于磁盘通常不是瓶颈,所以磁盘更适合追求吞吐量的系统。
Fusionio与磁盘相比,随机IO可以轻松到达5w+,响应时间小于1ms,而吞吐量瓶颈则大致在600MB-700MB之间,官方数据与实测数据差异不大。通过上述数据分析可以看到,fusionio的IOPS很高,通常不会成为瓶颈,而吞吐量可能会在IOPS之前成为瓶颈。我们可以计算一下,600MB吞吐量,IO大小为128K,IOPS只有4800;8K的随机读,IOPS达到5W时,吞吐量已经接近400MB。虽然单块fusionio卡的吞吐量比磁盘大,但是考虑到价格因素,fusionio并不适合追求吞吐量的系统。
观察Fusionio的响应时间,我们发现当压力未达到瓶颈之前,响应时间稳定在1ms左右,当快到达性能瓶颈时,IOPS和吞吐量不再增加,此时响应时间会出现一个突变,然后快速增加,直到不可接受。所以在实际使用中,必须控制压力在性能瓶颈之下。
Fusionio具备很高的IOPS性能,所以它更适合随机小IO读写。在实际使用的过程中,可以适当减小IO的大小,将吞吐量瓶颈转化为IOPS瓶颈,这点与磁盘系统刚好相反,磁盘系统应该尽可能将IOPS瓶颈转换为吞吐量瓶颈,比如增加IO的大小,这是个很有趣的话题。
随着Flash存储技术的出现,将会颠覆整个存储行业,甚至会改变未来数据库等存储系统的设计,也给了我们巨大的想象空间。
–EOF–
Fusionio的官方数据:

6 21st, 2011 | Filed under 大话技术
标签: ,