May 09, 2019, By Vadim Tkachenko
以前，我曾经发过“ Kubernetes上运行自定义配置的MYSQL/Percona服务器 ”的文章。目的是让Kubernetes平台上的 MySQL 可以使用全部的系统资源。 今天，我将在Kubernetes上，测验一下MySQL运行时，是否存在某些性能问题，以及展示一下尝试测验过程中所遇到的挑战。
我将采用一个非常简单的CPU计算密集型基准来测验MySQL数据库在OLTP只读工作负载下的性能情况，命令和参数如下：
sysbench oltp_read_only --report-interval=1 --time=1800 --threads=56 --tables=10 --table-size=10000000 --mysql-user=sbtest --mysql-password=sbtest --mysql-socket=/var/lib/mysql/mysql.sock run
参考硬件环境配置如下：
超微服务器
• Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz
• 2 CPU/28核/56线程
• 256GB 内存
请注意：CPU是28核/56线程，稍后的测试会关系到这个数字。
先来看看MySQL在裸金属机环境的性能情况：
[ 607s ] thds: 56 tps: 22154.20 qps: 354451.12 (r/w/o: 310143.73/0.00/44307.39) lat (ms,95%): 2.61 err/s: 0.00 reconn/s: 0.00
[ 608s ] thds: 56 tps: 22247.80 qps: 355955.88 (r/w/o: 311461.27/0.00/44494.61) lat (ms,95%): 2.61 err/s: 0.00 reconn/s: 0.00
这个硬件环境下测试结果，可以取近似值为22000 tps。
接下来，我们在同样的服务器环境下，依次部署Kubernetes节点，Percona服务器系统镜像。所采用的镜像为修改过的Percona Server 8, 镜像已经包含了sysbech测验软件。镜像下载链接在 这里 。对应的deployment的yaml配置如下：
*apiVersion: v1
kind: Service
metadata:
name: mysql
spec:
selector:
app: mysql
ports:
- name: mysql
port: 3306
protocol: TCP
targetPort: 3306
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
name: mysql
spec:
selector:
matchLabels:
app: mysql
strategy:
type: Recreate
template:
metadata:
labels:
app: mysql
spec:
nodeSelector:
kubernetes.io/hostname: smblade01
volumes:
- name: mysql-persistent-storage
hostPath:
path: /mnt/data/mysql
type: Directory
- name: config-volume
configMap:
name: mysql-config
optional: true
containers:
- image: vadimtk/ps-8-vadim
imagePullPolicy: Always
name: mysql
env:
# Use secret in real usage
- name: MYSQL_ROOT_PASSWORD
value: password
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
- name: config-volume
mountPath: /etc/my.cnf.d*
较为重要的一点是：测试中的镜像部署，都是部署在smblade01节点上，和前面的测试部署是相同的。
然后再看看部署后的性能测试情况。数据如下：
[ 605s ] thds: 56 tps: 10561.88 qps: 169045.04 (r/w/o: 147921.29/0.00/21123.76) lat (ms,95%): 12.98 err/s: 0.00 reconn/s: 0.00
[ 606s ] thds: 56 tps: 10552.00 qps: 168790.98 (r/w/o: 147685.98/0.00/21105.00) lat (ms,95%): 15.83 err/s: 0.00 reconn/s: 0.00
[ 607s ] thds: 56 tps: 10566.00 qps: 169073.97 (r/w/o: 147942.97/0.00/21131.00) lat (ms,95%): 5.77 err/s: 0.00 reconn/s: 0.00
[ 608s ] thds: 56 tps: 10581.08 qps: 169359.21 (r/w/o: 148195.06/0.00/21164.15) lat (ms,95%): 5.47 err/s: 0.00 reconn/s: 0.00
[ 609s ] thds: 56 tps: 12873.80 qps: 205861.77 (r/w/o: 180116.17/0.00/25745.60) lat (ms,95%): 5.37 err/s: 0.00 reconn/s: 0.00
[ 610s ] thds: 56 tps: 20196.89 qps: 323184.24 (r/w/o: 282789.46/0.00/40394.78) lat (ms,95%): 3.02 err/s: 0.00 reconn/s: 0.00
[ 611s ] thds: 56 tps: 18033.21 qps: 288487.30 (r/w/o: 252421.88/0.00/36065.41) lat (ms,95%): 5.28 err/s: 0.00 reconn/s: 0.00
[ 612s ] thds: 56 tps: 11444.08 qps: 183129.22 (r/w/o: 160241.06/0.00/22888.15) lat (ms,95%): 5.37 err/s: 0.00 reconn/s: 0.00
[ 613s ] thds: 56 tps: 10597.96 qps: 169511.35 (r/w/o: 148316.43/0.00/21194.92) lat (ms,95%): 5.57 err/s: 0.00 reconn/s: 0.00
[ 614s ] thds: 56 tps: 10566.00 qps: 169103.93 (r/w/o: 147969.94/0.00/21133.99) lat (ms,95%): 5.67 err/s: 0.00 reconn/s: 0.00
[ 615s ] thds: 56 tps: 10640.07 qps: 170227.13 (r/w/o: 148948.99/0.00/21278.14) lat (ms,95%): 5.47 err/s: 0.00 reconn/s: 0.00
结果的差异性很大。数值分布在10550 tps到20196 tps之间, 但绝大多数都是10000 tps上下。我们基本上可以理解为:MySQL迁移到Kubernetes上后，损失了将近一半的吞吐量。这个结论有点悲观，但也别先急于悲伤，应该是有办法优化的。我们首先需要搞清楚这个结果的产生原因。问题的答案在于Kubernetes如何应用 pod 的QoS 。
默认情况下(假定不考虑CPU或内存限制)，QoS后的结果会是最佳的效果，如果我们要确保QoS是有保证，应该给它分配所有CPU资源。为此，我们镜像的配置定义中，添加如下内容：
resources:
requests:
cpu: "55500m"
memory: "150Gi"
limits:
cpu: "55500m"
在定义CPU限制时，遇到一个有意思的问题。正如前面提到的56个CPU线程，所以最初时，我尝试将这个数值设定为“56”开头的值，结果发现Kubernetes无法启动pod，错误提示为CPU不足。我猜应该是Kubernetes不能给内部应用分配100%的CPU资源导致的，于是就设定为“ "55500m" ，这也表示只给Percona服务器分配55.5个CPU。
Guaranteed QoS的测验结果如下：
[ 883s ] thds: 56 tps: 20320.06 qps: 325145.96 (r/w/o: 284504.84/0.00/40641.12) lat (ms,95%): 2.81 err/s: 0.00 reconn/s: 0.00
[ 884s ] thds: 56 tps: 20908.89 qps: 334587.21 (r/w/o: 292769.43/0.00/41817.78) lat (ms,95%): 2.81 err/s: 0.00 reconn/s: 0.00
[ 885s ] thds: 56 tps: 20529.03 qps: 328459.46 (r/w/o: 287402.40/0.00/41057.06) lat (ms,95%): 2.81 err/s: 0.00 reconn/s: 0.00
[ 886s ] thds: 56 tps: 17567.75 qps: 281051.03 (r/w/o: 245914.53/0.00/35136.50) lat (ms,95%): 5.47 err/s: 0.00 reconn/s: 0.00
[ 887s ] thds: 56 tps: 18036.82 qps: 288509.07 (r/w/o: 252437.44/0.00/36071.63) lat (ms,95%): 5.47 err/s: 0.00 reconn/s: 0.00
[ 888s ] thds: 56 tps: 18398.23 qps: 294399.67 (r/w/o: 257603.21/0.00/36796.46) lat (ms,95%): 5.47 err/s: 0.00 reconn/s: 0.00
[ 889s ] thds: 56 tps: 18402.90 qps: 294484.45 (r/w/o: 257677.65/0.00/36806.81) lat (ms,95%): 5.47 err/s: 0.00 reconn/s: 0.00
[ 890s ] thds: 56 tps: 19428.12 qps: 310787.86 (r/w/o: 271934.63/0.00/38853.23) lat (ms,95%): 5.37 err/s: 0.00 reconn/s: 0.00
[ 891s ] thds: 56 tps: 19848.69 qps: 317646.11 (r/w/o: 277947.73/0.00/39698.39) lat (ms,95%): 5.28 err/s: 0.00 reconn/s: 0.00
结果表示有了很大的改善，大多数值都接近20000 tps. 但依然没有达到22000 tps的级别。我不确定为什么仍然有10%的性能损失的原因，但它可能与GitHub上提到的一个 pod Guaranteed的CPU配置 问题有关。同时，我还发现有一项优化 Guaranteed QoS性能 的工作正在进行中，目前还没有被合并到主版本中，希望它能在下一个版本中出现吧。
结论：
• 在Kubernetes POD上，采用开箱即用的方式部署应用时，所看到的性能可能会非常差。
• 为了改善用户体验，我们建议使用Guaranteed QoS，但Kubernetes上配置这个却不太友好。需要手动设置CPU线程的数量，如果使用动态性的云实例时，也不是那么清晰易见。
• 采用Guaranteed QoS方式，目前仍然有10%左右的性能开销，我认为这个代价应该是当下必须接受的。
原文链接： https://www.percona.com/blog/2 ... etes/ （翻译：易理林）
以上所述就是小编给大家介绍的《Kubernetes上的MySQL性能测验》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
- c++ 静态变量初始化测验
- 使用REST Assured测验验证REST服务
- Go并发编程小测验： 你能答对几道题？
- 开喷先答题? 这个 WordPress 插件要求评论前需通过测验
- 性能优化第一课：性能指标
- 【前端性能优化】vue性能优化
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Alone Together
Sherry Turkle / Basic Books / 2011-1-11 / USD 28.95
Consider Facebookit’s human contact, only easier to engage with and easier to avoid. Developing technology promises closeness. Sometimes it delivers, but much of our modern life leaves us less connect......一起来看看 《Alone Together》 这本书的介绍吧!
