计算依据:总最大堆大小超过物理内存(所有服务器,无子计算)

2020-09-18 13:11发布

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


我已启动并运行2.1.2,并查看我遇到了哪些新警报。

我收到警报"总最大堆大小超过物理内存(所有服务器,无子计算)"

警报值:

主机名:tst-biproc

[TotalHeap = 58.35 GB]

[TotalRAM = 48.0 GB]

----------

APS堆:43.0 GB

WACS堆:2.0 GB

Lumira堆:10.0 GB

资源管理器堆:0.0 GB

我显然超出了允许的主机大小,但是为什么它计算的总容量为58.35 GB,而不是总的55GB?

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


我已启动并运行2.1.2,并查看我遇到了哪些新警报。

我收到警报"总最大堆大小超过物理内存(所有服务器,无子计算)"

警报值:

主机名:tst-biproc

[TotalHeap = 58.35 GB]

[TotalRAM = 48.0 GB]

----------

APS堆:43.0 GB

WACS堆:2.0 GB

Lumira堆:10.0 GB

资源管理器堆:0.0 GB

我显然超出了允许的主机大小,但是为什么它计算的总容量为58.35 GB,而不是总的55GB?

付费偷看设置
发送
3条回答
clever101
1楼 · 2020-09-18 13:29.采纳回答

实际上,它可能是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个子代同时运行,因此我认为我们做出了正确的选择。 这些警报的目的是警告我们的用户潜在的问题,这就是我一直在警惕的地方。 我一直在浮动的一个选项是将其恢复但设置为禁用。 这样一来,我们的用户就可以在需要时启用和/或将其禁用。

此致

约书亚

能不能别闹
2楼-- · 2020-09-18 13:41

非常有趣的东西。 因此,您要说的是,在任何给定时间,系统进程实际上可能会消耗多少RAM并没有枯竭? :)

通过淘汰过程,我推断(在我们的环境中)它包括用于仪表板处理服务的额外3.35GB。

将它们归类到"其他"类别中可能会有所帮助,我只是担心数学上"警报值"中显示的内容是错误的,但听起来比这复杂得多。

感谢Josh。

小c菟菟
3楼-- · 2020-09-18 13:25

Tomcat + AJS,也许吗?

一周热门 更多>