云数据库调优（一）
之前负责trove产品化的同事负责监控去了，所以我接过RDS调优的活。
我们的方案是通过trove创建主、备，另外还允许创建若干个只读数据库来保障数据库的可用性。可是创建主、备的过程慢，给人的感受是好像过了半个小时，从同事留下的日志记录，准确的耗时是12分+，难以让用户接受。之前用过阿里云的RDS，感觉创建很快，而且营销文档显示阿里云支持主、备，异地双活，高可用物理机等，于是我跑去知乎问余峰（阿里云数据库专家）他们的RDS是部署在虚拟机还是物理机，回复很快，说是经过他们的调优，无论物理机还是虚拟机，性能都OK。莫不是先创建的数据库实例池，再按购买时分配的方案？
召集大伙出谋划策，同事建议把创建过程从串行改成并行，大概可以节约2-3分钟时间。经过代码梳理，这样改是可行的，但是改了其中一类数据库，其他如redis、mangoDB等也要跟着改，unittest要跟上，改完了提交社区，也不一定同意，有可能衍生出一个无法与社区兼容的版本。不过其他友商摸透了openstack的玩法后，就不跟社区玩了，也不再考虑兼容性
无果，跑去社区问PTL创建实例的时间，如果他们也慢，至少可以排除环境问题，我就可以从源码的机制入手，改造流程，可得到的答复是在desktop PC上只要2分钟就能创建一个。。。那我们这么牛逼的服务器居然。。。与此同时我还在参与openstack mitaka升级至ocata的任务，在我写的批量创建、删除实例的脚本里加入计时，出人意料的是主节点花费1分半，从节点花费2分半，整个过程耗时不超过4分钟。。。
不淡定了。。。于是根据日志和数据库记录的时间，重新把所有环境创建RDS实例的各个阶段统计出来，目标更清晰了。耗时数据横向对比，以下几个阶段耗时成2-10倍增长：
- nova创建实例的时间翻了2-3倍
- mysql服务启动到正常工作耗时翻了3-5倍
- guestagent从开始记录log->加载配置>开始启动mysql服务，耗时翻了6-10倍
- 从节点备份数据恢复耗时翻了2-4倍
从几个不正常的数据显露端倪，就是除了nova实例创建时间和整个集群的负载有关，其他几项基本上涉及到磁盘读写。
重新从IOPS角度出发，由于生产环境无法联网，没法安装fio测试IOPS，于是我使用了dd命令查看读写速度，测试数据如下：
#time dd if=/dev/vdb of=/dev/null bs=8k
3509717+0 records in
3509716+0 records out
28751593472 bytes (29 GB) copied, 549.096 s, 52.4 MB/s
real 9m9.100s
user 0m0.268s
sys 0m7.459s
#time dd if=/dev/zero of=/var/lib/mysql/test.dbf bs=8k count=300000
300000+0 records in
300000+0 records out
2457600000 bytes (2.5 GB) copied, 42.5467 s, 57.8 MB/s
real 0m42.552s
user 0m0.054s
sys 0m1.692s
time dd if=/dev/vdb of=/dev/null bs=8k
1310720+0 records in
1310720+0 records out
10737418240 bytes (11 GB) copied, 23.1137 s, 465 MB/s
real 0m23.117s
user 0m0.155s
sys 0m9.833s
time dd if=/dev/zero of=/var/lib/mysql/test.dbf bs=8k count=300000
300000+0 records in
300000+0 records out
2457600000 bytes (2.5 GB) copied, 4.86167 s, 506 MB/s
real 0m5.114s
user 0m0.049s
sys 0m4.546s
看到这组数据后我震惊了。。。整整10倍的性能差异。于是我联系到ceph负责人帮忙排查一下，才知道cinder那边的iops限速了，而测试环境是没有限速的，为了结论的可靠性，我请同事帮忙把测试环境的cinder iops也限速了，结果主、备耗时7分半，比原先耗时将近翻倍。从统计的结果显示，相比于12分钟的耗时，nova创建的速度节省将近2分钟，开机启动后的两次mysql start节省将近2分钟。
剩下的3分半时间，继续调优。。。
ceph负责人再次发现，生产环境的trove使用的系统盘是nova创建的，所以flavor也对iops限速了。然后帮忙把测试环境的flavor限速后，创建主、备所耗时间也是12分钟32秒，与生产环境持平，基本可以断定问题出在哪里了。至少确保nova、rabbitMQ的负载没有关联。
