根据我的日志文件，发生了一系列令人困惑的事件，我将把很多责任归咎于Python记录器，这是一个大胆的主张。我想我应该得到一些关于我所说的是否属实的第二意见。
我试图解释为什么我的日志文件中存在几个大的空白（一次大约两分钟），因为我的应用程序在缺少截止日期的压力期间。
我在远程服务器上使用Python的日志记录模块，并使用配置文件设置所有严重性为ERROR或更高的日志，以便通过电子邮件发送给我。通常情况下，一次只会发送一个错误，但在持续出现问题期间，我可能会在一分钟内得到十几个 - 这很烦人，但没有什么可以强调SMTP。
我相信，在短暂的这些消息发布后，Python日志系统（或者它所处的SMTP系统）遇到了错误或拥塞。对Python日志的调用然后阻塞两分钟，导致我的线程错过最后期限。 （我很聪明，可以将日志记录移动到应用程序的关键路径之后 - 所以我不在乎日志记录是否需要几秒钟，但是两分钟太长了。）
这似乎是一个相当尴尬的架构（对于可以冻结的日志系统，以及一分钟都无法处理几十封电子邮件的SMTP系统（Ubuntu，sendmail）），所以这让我感到惊讶，但是它完全符合症状。
有没有人有这方面的经验？任何人都可以描述如何阻止它阻止？
**编辑＃2：我实际算了。两小时内发送170封电子邮件。忘记以前的编辑。我错了。现在已经很晚了......
答案 0 :(得分：2)
压力测试揭示了：
我的日志记录配置向SMTPHandler发送了关键消息，并将消息调试到本地日志文件。
为了测试，我创建了一个等待触发器的大量线程（例如50），然后同时尝试记录关键消息或调试消息，具体取决于测试。
测试＃1：所有线程都发送关键消息：它显示第一条关键消息需要大约.9秒才能发送。第二条关键信息大约需要1.9秒才能发送。第三个更长，仍然快速加起来。似乎发往电子邮件的邮件会阻止彼此完成发送。
测试＃2：所有线程都发送调试消息：这些消息运行得相当快，从几百到几千微秒。
测试＃3：两者的混合。从结果中可以清楚地看到，调试消息也被阻止，等待关键消息的电子邮件熄灭。
所以，不是2分钟意味着超时。这是两分钟的代表，大量的线程被阻塞在队列中等待。
为什么一次发送这么多关键信息？这是具有讽刺意味的。在包含网络调用的方法中有一个logging.debug（）调用。我有一些代码监视方法的速度（以查看网络调用是否花费太长时间）。如果是这样，它（当然）记录了发送电子邮件的严重错误。然后在logging.debug（）调用中阻止了下一个线程，这意味着它错过了截止日期，触发了另一封电子邮件，触发另一个线程慢慢运行。
一个线程中的2分钟延迟不是网络超时。这是一个线程等待另一个线程，被阻止1分钟57 - 因为它正在等待另一个线程被阻止1分钟55等等等。
这不是SMTPHandler的非常漂亮的行为。
答案 1 :(得分：1)
两分钟的暂停听起来像是超时 - 主要是在网络堆栈中。
尝试添加：
* - nofile 64000
到所有相关计算机上的/etc/security/limits.conf文件，然后重新启动所有计算机以确保它应用于所有正在运行的服务。