近期，有些用户反复提出大家的计划任务出现问题，有的是不执行，有的是重复执行，
有的是今日发帖不正常等等
我们随机抽取了有问题的用户20个，进行追踪调查，发现了一些问题。
一、有的用户的独立主机访问量较大，数据库较大，而mysql的参数设置的又有些问题。
有的虚拟主机用户，要么是目录该给的读写权限没给（0777），有的是服务器上的网站太多了，经常在执行计划任务时未响应。
我们计划任务的机制是这样：
1.首先在到了触发计划任务的时间，有访问（会员，游客，搜索引擎的蜘蛛）然后触发该计划任务发生。（因为PHP是触发是语言，没有人去访问他，他什么也做不了。）
2. 计划任务执行.
3. 执行成功，返回执行成功的信息，更新到数据库中记录当前执行的时间，下一次需要执行的时间。
如果是这样，就发生问题了，一些人的mysql未响应，或者服务器繁忙，计划任务无法顺利执行，或者执行成功了，到返回执行成功的信息时，mysql超时了，程序认为没有成功之行，那么过不了多久，他还会反复的重试，一直执行下去，直到返回成功为止，但是大家知道，因为在执行中和执行完时，mysql就too many conection或者 lost conetcion了，所以虽然任务执行过了，他还会再次执行，这就造成了今日发帖数不对的情况。
二、还有就是大家的邮件服务器有问题，比如说一些主机上面的论坛根本就发不出邮件去，或者一次性的发信太多了。
这样当一些论坛，在发送大量生日祝福，或者回复帖子邮件通知的时候，出现了邮件发送失败，或者超时（一部分用户是根本就没设置好，发不出去，一部分用户是因为邮件被电信给封了不让发，一部分用户是因为邮件服务器不稳定。）这样呢，会造成计划任务执行时间非常的长或者高负载，结果就失败了，或者当成功时，返回成功记录时mysql连接或者php进程已经被释放了，所以计划任务重复执行甚至影响到其他的计划任务，造成紊乱。
解决办法：
1 修改您的mysql参数 （win主机是my.ini *nix主机是my.cnf）
适当的加大以下几个参数的数值
wait_timeout
long_query_time
key_buffer
max_connections
还有其他的一些能够影响大数据量和长时间连接操作的参数
2 确认您的邮件服务是否正常
3 关闭您的生日祝福计划任务和邮件回复计划任务
4 更新 Discuz 1001 补丁，改善计划任务的机制
（在更新1001补丁之前，请务必确认已经更新了911补丁，因为补丁文件是增量补丁，否则将会发生不匹配错误）
发表评论