openstack 性能优化

作者: cloudFans | 来源:发表于2020-09-08 12:16 被阅读0次

openstack 性能优化
Android性能优化 - 消除卡顿
Android性能优化 - 内存优化
前端性能优化（中）
前端性能优化（下）
Awesome Extra
常用的后端性能优化六种方式：缓存化+服务化+异步化等
webpack 性能优化
iOS性能优化 - 整理
【React.js 20】React性能优化

vip使用网卡子接口模式即可，不需要使用macvlan，ubuntu18 host网卡不要使用netplan，不好维护，
macvlan字节口模式经常导致vip:port telnet 不通，而vip可以ping

haproxy性能优化
作为一个可承载百万链接的应用，可以通过利用多cpu bind来优化
https://medium.com/@dubiety/multiprocess-haproxy-%E8%AA%BF%E6%95%99%E7%B6%93%E9%A9%97-253804148ea2
https://www.cnblogs.com/yinzhengjie/p/12114081.html

如果是面向数据库的haproxy，mysql和haproxy的连接数尽量保持大致一样。

kolla docker haproxy 没有log的问题

https://documentation.solarwinds.com/en/Success_Center/loggly/Content/admin/haproxy-logging-using-syslog.htm?cshid=loggly_haproxy-logging-using-syslog

/etc/haproxy/haproxy.cfg
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy

基于debug模式监控流量
If you would like to monitor live traffic that passes through HAProxy, enable debugging with the -d flag:
haproxy -f /etc/haproxy/haproxy.cfg -d

log rotate

https://gist.github.com/hzbd/5518180

https://sharadchhetri.com/how-to-enable-logging-of-haproxy-in-rsyslog/

maxconn 40000
galeara maxconn 10000

性能测试
window 60G 规格

控制（rabbitmq+mysql（64Gbuffer）） 48cpu 256G内存
批量 horizon gpu vm 100 100% cost 2min
批量 horizon gpu vm 200 100% cost 4.40min
批量 horizon gpu vm 300 100% cost 4.30 min
在300基础上
批量 horizon gpu vm 500 100% cost 6 min

compute节点 25台机器 10gpu/host 内存512GB 48cpu M10 1Tssd
controller节点 25台机器内存256GB 48cpu dell R620 1Tssd
network节点 25台机器内存256GB 48cpu dell R620 1Tssd

4, 二次定位的问题
由于批量创建的场景比如200批量出现问题，考虑到剩余容量，以及网络的问题，很难在一个集群复现一个因为性能瓶颈导致的bug，根据8/2原则，200中失败5台机器，二次定位成本太高了，如果磁盘足够，而且log rotate完善的话，强烈建议将openstack debug打开。

官方测试的数据

2018 openstack峰会演示的场景，基于73个cell管理了9000+物理机器，上万虚拟机
https://object-storage-ca-ymq-1.vexxhost.net/swift/v1/6e4619c416ff4bd19e1c087f27a43eea/www-assets-prod/presentation-media/2018-OpenStack-Summit-Berlin-Scaling-Nova-with-CellsV2.pdf

数据库deadlock问题
总之，和性能直接相关,haproxy 转发速度不够快，直接访问，nova-conductor， neutron-server 出现概率明显变小

/var/log/kolla/neutron/neutron-metering-agent.log
File "/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/protocol.py", line 220, in check_error\n err.raise_mysql_exception(self._data)\n', u' File "/var/lib/kolla/venv/lib/python2.7/site-packages/pymysql/err.py", line 109, in raise_mysql_exception\n raise errorclass(errno, errval)\n', u"DBError: (pymysql.err.InternalError) (1305, u'SAVEPOINT sa_savepoint_1 does not exist') [SQL: u'ROLLBACK TO SAVEPOINT sa_savepoint_1'] (Background on this error at: http://sqlalche.me/e/2j85)\n DBDeadlock: (pymysql.err.OperationalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction')

/var/log/kolla/nova/nova-compute.log
DBDeadlock: (pymysql.err.InternalError) (1213, u'Deadlock found when trying to get lock; try restarting transaction
galera集群是一个稳定很高的多主集群。但是写请求总是落到其中一个节点上，而随后的读不一定在写的节点上，存在一定的延迟。而galera是基于全局事务提交的。当写的并发太高，而读的时候，事务没有完全同步完毕，就会出现该情况。但是出现的一定是小概率的，大概率批量出现，很可能是性能问题。
建议排查下系统盘，数据盘是否损坏，网卡是否掉速，影响了集群同步的速度。

如果掉速的节点是galera主节点，数据库整个访问速度都会降低，不是的话，可能不会，取决于同步的配置是否是强一致性，毕竟有3个节点，也就是说有两个节点需要同步，同步完一个节点即可认为完成的话，那么只有50%的概率。

这个跟ceph集群的掉速很类似。3副本情况下

7.数据库优化
R620 48cpu 256G