实际上，它可能是CR4E服务器或Dashboard Cache/Proc服务器。 我将在表中添加另一个名为"其他"的项，以将这些小型服务器合并为一个类别。 至少以这种方式，计算将排队。

由于许多用户请求，我们更改了原始系统警报，该警报在上一个补丁中计算了服务器RAM与Xmx。 如您所知，我们的某些服务器是C ++，其他服务器则是基于Java的服务器。 有些服务器（例如作业服务器）是C ++，但会生成Java子进程。 原始警报的重点是分析BI Java服务器并计算其最大堆。 由于这表示主机上可能需要的最大内存，因此我们正在将其与总RAM进行比较。 我们不考虑其他c ++ BI服务器，Tomcat，OS或主机上运行的任何其他设备所需的额外空间，因为此值在系统之间会有所不同。 每个客户都有不同的要求。 我们只是比较最大堆和总内存。 如前所述，我们对原始警报有很多要求和问题，因此已被禁用。 有些人想要计算出的子进程（主要是JS），另一些人希望忽略它。 有些人只希望将停止的服务器放在等式之外，等等。因此，为了妥协，我们开发了一些变体来满足每个人的需求。

"总Xmx与总RAM"-这是原始警报名称，此后已被禁用并重命名为下面的#1。

1。）"总Xmx（服务器和子级）与总RAM"-计算所有BI Java服务...父进程，子进程，正在运行的服务器和已停止的服务器。 如果一切都在其峰值内存中运行，则基本上可以测量全部潜力，并将此值与Total RAM比较。 我们已在补丁2中禁用了此功能，但我不确定在补丁3中恢复它是否有意义。

计算结果：仅APS，WACS，JS子级，CR4E和子级，Lumira，Explorer，Dashboard Cache和Dashboard Proc子级

2。）"总Xmx与总RAM（所有服务器，没有子代）"-顾名思义，这将度量#1中的所有服务器（正在运行和已停止），但将子代进程排除在外。

计算结果：APS，WACS，CR4E，Lumira，资源管理器，仪表板缓存

3。）"总Xmx与总RAM（运行中的服务器，没有子代）"-与#2相同，只是它只计算处于运行状态的父级服务器。

有关上面#1的更多信息。 与此警报的斗争实际上归结于作业服务器的计算。 如果我们为单个JS计算所有潜在的Java子进程，则最大堆很大。 默认的BI安装为单个JS提供约17个子服务。 每个服务的默认设置为5个子级。 而且我相信每个JS子级都有一个默认的Xmx256m，它继承自SIA。 单个默认JS的大小超过17GB。 我认为，如果我们重新启用它，我们会发现大多数客户都会收到警报。 而且，由于大多数客户永远不会看到他们的JS满载所有子服务的5个子代同时运行，因此我认为我们做出了正确的选择。 这些警报的目的是警告我们的用户潜在的问题，这就是我一直在警惕的地方。 我一直在浮动的一个选项是将其恢复但设置为禁用。 这样一来，我们的用户就可以在需要时启用和/或将其禁用。

此致

约书亚