时间:2021-07-01 10:21:17 帮助过:17人阅读
MySQL单机load过高问题讨论
有一个朋友问我: "hi,我想问下你们遇到单机load过高的情况 采取什么紧急措施啊?"
我问他是不是mysql db server?
他说是。
我给他如下建议:
1 先看下是不是mysqld进程造成的load高?
2 如果是的话,去看下当前线程有没有比较慢的sql
朋友再问: 嗯 都没有呢,这个如果由于业务的原因导致load高呢
我给出自己的建议:
1 并发量过高
2 业务原因,是crontab 任务,可以停止就停止掉
朋友再问:不是 sql的原因啊 db机器一般出现load高都是因为io,cpu这些导致的 这些很大部分都是由于业务繁忙处理不过来吧
我回复 :
1 嗯,不是慢sql导致io cpu爆增的,我还没碰到过,可能是我们这边单机性能太好了, [做人要坦诚特别是技术讨论]
2 如果是io,cpu,那也是有事务操作吧
3 看看db参数设置是否合理,如果参数合理的话,估计就是到了单机性能的瓶颈了
朋友问:额 没有遇到过 .... 这,那没有遇到过db机器load高需要处理的啊?
我回复:
遇到很多,大部分都是慢sql造成的
朋友再问:嗯 一般不急?
我回复:
1 嗯,不会啊,我们事先上应用之前都会做压力测试,峰值测试
2 业务量不会超过预计的峰值
3 你们单台load过高,现在mysql不都是多台吗?分布式,读写负载均衡,一台load过高,那另外几台呢?
朋友再问: 我假设某个业务 突然一天访问量很高(超过之前预估),这个时候又只访问一个主,而业务肯定不能停的,机器明显感觉处理不过来,load急速上升,有什么办法处理吗?我们的不是不是分布式的,现在的分布式都有负载均衡,对这样的情况太好处理了。
我回复:
1 这个时候业务不能停,单机硬件升级更不是可行方案。
2 在发现cpu过高了,就马上去准备加新的db机器,如果新的db机器在单台db爆掉之前准备好的话,直接添加上去,分担app访问压力。
3 这个操作不会对业务产生影响,我们一般用的都是vip吧,在vip下再加一台db,应该是很方便的。
朋友再问: 我在想这样的问题还真是有点难处理啊?
我表示疑惑:为什么,你们不是用vip访问db?
朋友说:不是,都是直接写真实ip上去连接应用的。
说道这里,如果没有vip,而且是单台db,到时候瞬间爆掉了,我只能表示我水平有限暂时也没有别的好招了,只有暂停业务并且重新架构db了。
不过我还是给他一些自己的建议,希望能带给他一些帮组:
1 上新的app之前,做好db的压力测试和峰值测试。
2 要做db的ha方案,并且测试通过。
3 db的ip已经app的ip已经要用类似vip的处理方式,以便方便扩展。
4 db要做好备份机制,并随时抽查备份的有效性。
bitsCN.com