0

我们有一台 64 位的 linux 机器，我们与其他服务建立多个 HTTP 连接，Drools Guvnor 网站（如果你不知道，规则引擎）就是其中之一。在 drools 中，我们为每个被触发的规则创建知识库，并且知识库的创建与 Guvnor 网站建立 HTTP 连接。

所有其他线程都被阻塞，CPU 利用率上升到 ~100%，导致 OOM。我们可以在 15-20 分钟后进行更改以编译规则。但如果有人已经面临这个问题，我想确定这个问题。

我检查了"cat /proc/sys/kernel/threads-max"它显示27000个线程，这是一个原因吗？

我有几个问题：

  1. 我们什么时候知道我们的容量已经超出了？
  2. 可以在内部产生多少线程（任何粗略估计或与差异参数相关的公式都可以）？
  3. 有没有其他人看到过 Drools 的类似问题？并发访问 Guvnor 网站基本上是导致问题的原因。

谢谢，

4

2 回答 2

2

我的回答是基于您正在为每个请求创建一个知识库的假设，并且这个知识库创建包括从 Guvnor 下载最新的规则源，如果我弄错了，请更正。

我怀疑包的构建/编译需要时间并且占用你的系统。

您可以从 guvnor 下载预构建包，而不是在每个请求上编译包，如果您的规则没有太大变化，您也可以在本地缓存这些包。唯一的限制是您需要在 guvnor 和您的应用程序中使用相同版本的 drools。

于 2012-10-30T13:42:36.847 回答
1

我检查了“cat /proc/sys/kernel/threads-max”，它显示了 27000 个线程，这是一个原因吗？

这个数字看起来确实很大，但我们不知道这些线程中的大多数是否属于您的 java 应用程序。创建一个 java 线程转储来确认这一点。您的线程转储还将显示每个线程占用的 CPU 时间。

我们什么时候知道我们的容量已经超出了？

您有 100% 的 CPU 和 OOM 错误。你已经超负荷了 :) 开个玩笑，你应该监控你的 HTTP 连接队列以确定你做错了什么。您的帖子没有说明您如何处理 HTTP 连接（大概是通过某种由队列支持的池化机制？）。我已经看到容器和程序无限地排队请求，导致它们突然崩溃。绘制以下图表以隔离您的问题

  1. 一段时间内的阻塞线程数
  2. 每个线程花费的时间
  3. 每个线程池的线程数以及它们如何随时间增加/减少（池大小）

可以在内部产生多少线程（任何粗略估计或与差异参数相关的公式都可以）？

只有负载测试才能回答这个问题。加载您的服务器并确定它在 60-70% 容量下可以支持的并发用户数。请注意此时在内部产生的线程数。那是您的峰值容量（为意外流量留出空间）

有没有其他人看到过 Drools 的类似问题？并发访问 Guvnor 网站基本上是导致问题的原因

我无法帮助那里，因为我没有以这种方式访问​​流口水。对不起。

于 2012-10-30T11:55:22.453 回答