8-08 4 views
这个错误搞了很久,大概晚上将近0点接到朋友请求协助,说这个已经折腾了他们好几天了,研发把代码也扒拉个遍完全没有线索,请求支援,我从晚上12点开始一直折腾到早上快4点,也因为这个是batch每次跑的时间等待的比较久,还有要避开某些正在处理的batch,断断续续搞最后快4点实在是折腾不了,也没什么头绪,满世界查资料没一点进展,就先靠在椅子上睡了
早上6点醒来,仔细想了想这个业务流程,看了batch触发的sql日志,发现SQL其实是有跑一些的,说明不是一运行就程序报错,可能跟量或时长有关系,也因为是出报表的batch,按年处理,每年数据量巨大,然后会生成临时表存放,猜测有没有可能是这个方面的因素导致的,毕竟segfault at从网上查到的信息是说内存地址读取超出区域范围,就开始着手调整PHP的连接数据库相关的参数,尤其是内存大小这块儿的
不想太多,跟MySQL相关的,缓存相关的参数都先调整了再说,排查问题时,尤其是没有头绪时,找到参数先往大了加,如果太小可能看不出效果,尤其是Batch这种批处理任务
> vim /etc/php.ini
1 2 3 4 5 6 7 8 |
pdo_mysql.cache_size = 2000 mysql.cache_size = 2000 mysql.connect_timeout = 3000 mysqli.cache_size = 2000 max_execution_time = 60 max_input_time = 60 memory_limit = 512M |
调整了之后,再测试发现比远来的现象有些改善,本来是一个年度都处理不了就崩了,现在是能跑完一个年度了,这就来劲了,再加大
很明显,跟timeout没太大关系了,重点是cache_size和memory_limit上
1 2 3 4 5 6 |
pdo_mysql.cache_size = 200000 mysql.cache_size = 200000 mysqli.cache_size = 200000 max_execution_time = 300 memory_limit = 1024M |
调整完成后,Batch任务顺利跑完,跑了将近2个小时
这里面有些参数的值肯定是不合理的, 方向上我努力支援了,参数值的合理性上,就有他们自己去解决吧,