Closed Taylor000 closed 1 year ago
感觉一个小时两三万有点慢了
您怎么知道瓶颈在SELECT * FROM tc_tieba ORDER BY RAND
上?签到任务用的伪多线程并行开了多少
机器 4h8g 这一块应该没啥问题
innodb_buffer_pool_size
改了吗?默认只有128m
感觉一个小时两三万有点慢了
您怎么知道瓶颈在
SELECT * FROM tc_tieba ORDER BY RAND
上?签到任务用的伪多线程并行开了多少机器 4h8g 这一块应该没啥问题
innodb_buffer_pool_size
改了吗?默认只有128m
由于上个月关issue了所以没关注这块,今天看邮件才知道 有人回复; 那回复一下:
1、因为感觉既然有分表设计 那应该是有点关系的吧。 2、当时的话多线程给的是8,但是我记得之前看到其他issue下,开发者有回复说好像这个是结合分表功能 效果才比较明显(这边我就没去翻issue求证了) 2、数据库缓冲的话当时是设置的512M
然后就是在我关issue之前的大概一个礼拜时间里 尝试修改了设置:
单表单次签到执行数量
逐步提升到2000、计划任务线程数
逐步提升到了192,
最后就是一个小时大概四五万,接近三十万 6个小时多一点签到完成,所以我关了issue 这速度ok了
想知道 一开始没设置分表的话,后期能否直接改数据库强行分表
目前是二十多万,没分表(就默认的tc_tieba),然后设置的是 单表单次签到执行数量:400 签到间隔时间:4ms 贴吧数据表搜寻方法:随机 order by rand
机器 4h8g 这一块应该没啥问题 感觉一个小时两三万有点慢了,不知道有没有大佬可以解惑支招的
ps:尝试过直接修改'tc_user'里面的't'为新表,同时把'tc_tieba'对应用户贴吧挪到新表,但是好像不行,管理员「签到状态统计信息」那地方直接乱码了,然后在「统计信息」页面查看的话“签到成功数”一直是0