一、py脚本释放cpu资源,time.sleep(0.001)
python脚本释放cpu资源,time.sleep(0.001)
- 原来写了个time.sleep(0.02)。为什么这么写的原因有点不太确定了,回忆了下,大概是一开始是轮询模式,避免tick触发太频繁,所以每20ms判断1次。后面改为阻塞模式,没有去掉这个time.sleep(0.2)。导致执行命令时,总有20多ms的耗时。
- 内网是20个服的db布置在同一台物理机上,每个服16条线程,一共300多条线程。如果time.sleep(0.001)很容易就能把cpu干爆(100%)。并且有的线程一直持有cpu,有的线程一直抢不到cpu资源。就会发现有的人访问db很快,有的人访问db就很慢。
- 2023-09-28 后来发现,前面的结论不完全准确。time.sleep(0.001)已经交出cpu时间片了。原则上运行的dbpy的cpu使用率应该很低。实际上没有业务的时候,确实只占用2~3%的使用率。但是内网有17个db布置在同一台机器上。
db数量 * 服务数量 * cpu使用率= 17*2*2.5 = 85
,也就是空转的时候,已经吃掉了85%的cpu。内网是双核的机器,相当于有200%cpu,85/200=0.425,差不多就是mobaXterm显示的值。 - 2023-09-28 这里犯了一个很傻逼的错误,不断的调整sleep的时长。其实并没有什么意思。sleep(0.001)已经交出cpu时间片了。如果cpu使用率还很高的话,那么说明业务逻辑占用了太高的cpu。需要去优化业务逻辑,调整sleep并没有实际解决问题。
把sleep从0.02修改为0.001,cpu使用率当然会下降。那是因为业务逻辑函数被触发的次数下降了。但是要维持tps的话,业务逻辑函数不能下降调用次数。
import time
def Work():
a = 1
while a < 0xFFFF:
#while a < 0xFFFFFF:
a += 1
def Main():
Work()
time.sleep(0.02)
#time.sleep(0.1)
二、time.sleep()精度问题
在windows中,time.sleep(0.001)并不能实现让线程睡眠1毫秒,因为操作系统的精度问题,其睡眠时长大概在16ms左右。得使用time.perf_counter()
函数。
lastTime = time.perf_counter()
while True:
nowTime = time.perf_counter()
if nowTime - lastTime >= 0.001:
# 执行函数
Func)()
lastTime = time.perf_counter()
精度问题2
time.perf_counter()
这个函数好像也不太好用。换了一种思路去解决。
用py写了一个测试脚本,在循环里面insert log到mysql,大概每秒能插入8000条log。但是在storage_py里,每秒只能处理100条左右,差了整整80倍。
-
后来排查,发现
生产线程
从redis队列
中取请求req
的速度就很慢,1秒钟就只blpop出100个左右。最后判断是time.sleep(0.001)使用不恰当,这里以为1秒能取出1000个请求。但由于time.sleep(0.001)实际上睡眠16ms左右,所以取出的请求数量大概是1000/16=62。
解决方案是:sleep一次以后,加个计数一直blpop取,取够200个命令,才进入下一次sleep。
2023-09-28:订正一下,这里为啥要加计数呢?计数其实并不合适。这里应该直接用阻塞,当请求队列中有请求的时候,应该一直取,知道队列取完了,那么退出业务逻辑。执行1次sleep(0.001)。嗯这样改完以后,速度提升显著。 -
同样的,在
消费线程
处理req的时候,发现也是16ms才处理一条,王德发。于是也改成,sleep一次以后,就处理够200个,才进入下次sleep。(2023-09-28 注:这里也改成阻塞了)
三、insert数据有点慢,表的主键、索引、自动递增
- insert数据有点慢,表的主键、索引、自动递增
插入战报、log的操作有点慢。
四、 dbsdk读取resp有点慢,因为互斥锁lock太多代码了
dbsdk读取resp有点慢,因为互斥锁lock太多代码了
- 锁越多的代码,锁住的时间就越久。其它线程等待的时间也越长。所以在实现功能的情况下,锁越少的代码越好。
- 双缓存队列,只在交换的时候,锁一下,其它时候,2个线程只访问当前持有的队列。
五、关闭auto commit
mysql的auto commit是默认是打开的
pymysql多次execute(),一次commit()定义了个遍历,每累计执行execute()1000个命令,就commit()提交1次。
- 提升蛮多的,但是要注意如果在commit之前出错了,要捕获异常,在处理异常中,执行commit(),否则会出现命令未提交的现象。
- 遇到个问题,有些命令是需要立即写数据库的。比如创建角色,在insert插入角色之后,会从数据库select查询角色数据。此时因为还没有累计达到1000个命令,所以数据库里并没有角色数据。没有角色数据,就被认定为
新角色
。这样上层逻辑就不对了。用数量来控制是否commit()会有问题
换了种方法,记录上次提交的时间戳,用时间来控制是否commit()
,测试下来目前好像没什么问题。解决方案:数量控制+时间控制。
log类的request命令,可以用合并提交的方式来优化。文章来源:https://www.toymoban.com/news/detail-513654.html
六、不设置cb回调函数
game内存容易增长,因为所有命令都要等python执行完毕,然后才释放内存。但有一些命令,可以不需要回调,因为回调也不会做什么操作。例如:log命令、操作缓存类的命令
。文章来源地址https://www.toymoban.com/news/detail-513654.html
七、其它
- __forceinline加在模板函数前,声明为内联模板函数。
- 尽量避免字符串的构造和析构。比如参数要求string,传递参数本身已经是string,不要再使用str.c_str()。
到了这里,关于db性能优化的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!