用过 skynet 的应该都碰到过：当我们在服务中不小心调用了一个长时间运行而不返回的 C 函数，会独占一个工作线程。同时，这个被阻塞的服务也无法处理新的消息。一旦这种情况发生，看似是无解的。我们通常认为，是设计问题导致了这种情况发生。skynet 的框架在监测到这种情况发生时，会输出 maybe in an endless loop 。
如果是 Lua 函数产生的死循环，可以通过发送 signal 打断正在运行运行的 Lua 虚拟机，但如果是陷入 C 函数中，只能事后追查 bug 了。
那么，如果我原本就预期一段 C 代码会运行很长时间，有没有可能从底层支持以非阻塞方式运行这段代码呢？即，在这段代码运行期间，该服务还可以接收并处理新的消息？
使用 Kubernetes 时，内存不足 (OOM) 错误和 CPU 节流是云应用程序中资源处理的主要难题。
这是为什么？
云应用程序中的 CPU 和内存要求变得越来越重要，因为它们与您的云成本直接相关。
通过 limits 和 requests ，您可以配置 pod 应如何分配内存和 CPU 资源，以防止资源匮乏并调整云成本。
如果节点没有足够的资源， Pod 可能会通过抢占或节点压力被驱当一个进程运行内存不足 (OOM) 时，它会被终止，因为它没有所需的资源。
如果 CPU 消耗高于实际限制，进程将开始节流。
但是，如何主动监控 Kubernetes Pod 到达 OOM 和 CPU 节流的距离有多近？
谢谢！