我有几个月来一直试图追踪的最奇怪的问题.我添加了在基于MySQL的日志中创建日志条目的调试代码行和行,结果没有意义.
基本上,脚本有时会停止.有时它会随机出现,然后在同一个位置进行十几次,然后它可能会一直持续,然后下次再次进行.
更多细节:
每隔15分钟,我循环遍历一个客户列表,每个客户端都有一个需要为电子邮件解析和收集的数据列表.如果此脚本的先前版本已在运行(即存在小于5分钟的日志条目),则不会再次执行该脚本.因此,如果我看到日志条目中断超过几分钟,然后在第一次启动后15分钟再开始,我就知道出了问题.日志中最奇怪的情况如下:
我在日志中写入了我要为客户端X创建数据库查询.然后我创建了一个包含客户端ID和星期几(date("l", strtotime("now")))的SQL代码的变量.然后我记录查询已成功创建.请注意,查询仅存在于PHP变量中,并且尚未提交给MySQL!
那么,让我举一个例子,说明我在日志中看到的内容:
并冲洗并重复.现在持续几个小时,它将在它为客户端20创建查询之前失败并在它为客户端21创建查询之后失败.然后,突然之间,它可能会一直通过其他客户端.然后脚本再次启动并继续相同的怪异循环.每隔一天左右,这将发生在一两个其他客户身上.
查询很简单,如下所示:
$sql = "
select fldClientName
from client
where fldClientId = $clientId
and fldEmail".date("l", strtotime("now"))." = 1
";
基本上,如果今天是星期一,它应该检查fldEmailMonday是否设置为1,让我们知道今天需要通过电子邮件发送此客户端.
这适用于我们的大量客户,但它只是随机地卡在一天或两天变化的一个或两个客户端.再次,这发生在BEFORE $sql提交给MySQL 之前!我们陷入了变量的创造$sql.
当然,实际的查询要比我在这里写的要复杂得多,但$clientId它date("l", strtotime("now"))是静态文本中唯一可变的部分.
此外,我们多年来一直有同样的问题(我现在才开始追踪它),到现在为止,我们经历了三个PHP服务器和两个MySQL服务器 - 我们仍然遇到同样的问题,所以我们要确定它不是硬件问题(如内存或硬盘驱动器).
我不知道这可能是问题所在,但是这个脚本是由一个在lynx中启动它的cron作业运行的.这是在我接受代码之前建立的,我不知道它的原因.每当我们手动运行它(我通常使用php index.php而不是lynx hostname://index.php),它似乎永远不会失败.
这可能是Lynx的一个问题吗？如果是这样,为什么它在70%的时间内都有效,否则会失败？为什么随机性？
或者我是否应该弄清楚PHP问题？我们正在运行5.3.2版本(是的,有点旧,但除非绝对必要,否则我们的服务器管理员不想搞砸它).
我猜测Lynx被使用所以我们得到了Apache日志(顺便说一下,除了一些不赞成的代码警告,我现在也试图摆脱它),而且我猜测如果我运行php index.php,我不要得到apache日志.也许还有另一个我错过的日志文件可能对此有所帮助？
此外,它不能是导致它的日志记录代码本身,因为它只提交纯静态文本和在创建SQL代码之前建立的客户端ID.
脚本在更多的位置失败了,但这对我来说真的没有意义.
关于什么可能导致这样的事情的任何想法？
有什么想法我可以做什么来追踪它？我的意思是,我正在创建变量之前和之后正在记录,并且它介于两者之间 - 现在确定我可以在这里记录多少...
总结一下这次谈话，我的主要策略是简化 cron 调用中涉及的软件组件的数量。所以，这意味着改变：
Cron -> Lynx -> Apache -> Script
到
Cron -> Script
如果新方法中仍然存在问题，则至少排除了两个组件（并且它也可能更快）。从你的评论来看，这似乎解决了这个问题；如果是这样，那就太好了。
我在这里重申的更广泛的一点是，虽然研究一个具有挑战性的问题可能很有趣，但出于成本原因，最好以另一种方式解决问题。也许正是在这样的时刻，Lynx 失败的谜团可能不得不继续存在！
| 归档时间： |
|
| 查看次数： |
191 次 |
| 最近记录： |