Linux kernel Linux UNIX套接字上的实时锁，怎么办？

我们运行一个Linux应用程序，它分叉了大量（超过1000个）子进程。这些子进程通过UNIX数据报套接字（所有子进程共享的套接字）与主进程通信。UNIX数据报套接字除了用于其他通信之外，还用于日志记录。整个系统工作正常，直到应用程序必须对一个巨大的外部错误做出反应——比方说应用程序数据库崩溃。我们观察到，在这种情况下，子进程开始生成大量错误日志事件，这可能是正确的，因为每个子进程都会受到崩溃的影响。几分钟后，负载增加到8000以上，CPU消耗量达到80-100%（不是用户！）。只有当应用程序被终止，或者更常见的情况是，由于响应缓慢，该框变得不可用，并且必须重新启动时，该状态才可恢复

对内核转储的调查表明，子进程在UNIX套接字上的

send（）

syscall中被阻塞，与主进程对话。UNIX套接字配置为非阻塞，应用程序实现对

EAGAIN

的正确处理。更深入的分析表明内核中存在活动锁条件。显然，进程正在竞争对某些与UNIX套接字相关的资源的访问

问题：你以前有没有遇到过这种或类似的行为？我们是否错过了有关UNIX套接字并行性的任何内容

版本：
-CentOS Linux 7.3.1611版（核心版）。

---

-内核Linux 3.10.0-514.16.1.el7.x86_64 x86_64

在内核方面显然还有改进的空间，而且很有可能它是一个相当容易实现的成果。我不打算猜测。很有可能，这个问题将很容易通过火焰图看到

然而，在这种情况下，这种考虑是一种转移注意力的做法。为了便于讨论，我们假设内核以0开销推送所有这些错误消息。您已经生成了千兆字节的重复错误消息，没有增加任何价值

相反，当发生重大事件时，只需记录一次，然后再次记录它是否已被清除（例如，注意与数据库的连接已断开，注意它何时恢复，但不要在每个查询上记录它已断开）。或者，您可以定期或使用ratelimit记录。不管怎样，仅仅发垃圾邮件都是错误的

---

孩子的数量（1000+？）似乎太多了，这给项目设计的有效性打上了问号。你能详细说明一下那里发生了什么吗？

我不会说他们在send（）中被“阻止”，只是他们在那里花费了大部分的处理时间。套接字缓冲区是否可能已满？无论如何，考虑内核中的错误是我最后的选择。套接字缓冲区肯定是满的，但它通常是通过EAGAIN机制处理的。b/c UNIX套接字是非阻塞的。我同意内核错误部分。如果在不成功的发送之间没有延迟（例如睡眠），这就是您将得到的结果。让我们从结尾开始：我完全同意，具有大量子进程的设计至少是奢侈的。该决定的最初目的源于安全性：每个孩子处理一个由唯一密钥集加密的对等连接，目的是在系统/进程级别上保持该连接的分离。性能方面也令人印象深刻，它可以轻松处理+10k并发连接，每秒250个事务，CPU占用率为1-5%，系统负载小于0.1。但我并不是来为这一点辩护的，下一代可能会转向“每个CPU核心的进程”模式。然而，这并不能解决根本问题。还有其他方法可以触发广泛的日志记录，从而调用应用程序的暂停。关于“千兆字节的重复错误消息没有增加任何价值”-有一个巨大的审计日志从这个应用程序生成，并被送入一个功能强大的日志分析器。从这个角度看，这些错误是沧海一粟。类似的情况（不暂停应用程序时）会导致监控图表出现“良好”峰值，因此操作员会快速响应。但是，我也不为这一点辩护——这是一个明显的改进空间，也许单个但更严重的日志消息就可以了。最后——重新内核错误：我更正了上面的一个文本，它可能太粗体了。更好的说法是，有一种方法可以利用UNIX套接字子系统中的实时锁定，以便恶意非特权用户可以对系统执行本地DDoS攻击。因为这正是我们观察到的。这可能没什么大不了的。如果您有正当理由推送大量数据，那么您可能不应该通过unix套接字进行推送。您可能只想让每个人直接写入日志文件，或者如果必须通过主deamon，则通过共享内存来完成。这就是说，我认为在这一点上，您应该根据并发客户机的数量来衡量您可以推送的量，并查看您的合理消息是否符合限制。