☰

我该如何测量每个 Glassfish 域所需的 RAM 数量？

tag-icon • tag-icon java memory-usage glassfish
我该如何测量每个 Glassfish 域所需的 RAM 数量？

在我们的测试环境中，我们有许多应用程序分布在几个服务器和 Glassfish 域中。为了简化版本控制，我希望每个客户的每个应用程序都有一个 Glassfish 域（有点像许多 jetty 实例的重量级版本）。

我听说 Glassfish 占用大量资源，所以我想测量一下可用 RAM 中大约可以容纳多少个实例。我知道我可以通过启动实例并观察top输出来做到这一点，但我应该关注哪些具体统计数据才能很好地衡量每个实例的资源消耗？

答案1

使用top来确定内存需求更像是一门艺术，而不是一门精确的科学。有两种主要方法可以实现这一点。

在这两种情况下，您都需要在启动要调查的程序（在本例中为 GlassFish）之前获取系统资源使用情况的基准。然后，您可以遵循以下两种方法之一：

聚合内存使用路径

这就是方法我我个人认为这样做可以更好地反映整体资源利用率。
另外，如果你搞砸了，你最终得到的数字可能会更大，而不是更小。

  • top在某个终端中运行并记下标题输出。
    特别注意 Active 和 Wired 内存：

    last pid: 26611;  load averages:  0.50,  0.38,  0.34   up 42+18:51:53  11:44:41
34 processes:  1 running, 33 sleeping
CPU:  0.9% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.1% idle
Mem: 447M Active, 112M Inact, 233M Wired, 22M Cache, 111M Buf, 170M Free
Swap: 2048M Total, 220K Used, 2048M Free

  • 启动目标应用程序，并注意标题的变化。

    last pid: 26571;  load averages:  0.35,  0.35,  0.33   up 42+18:49:00  11:41:48
34 processes:  1 running, 33 sleeping
CPU:  2.7% user,  0.0% nice,  1.2% system,  0.0% interrupt, 96.1% idle
Mem: 606M Active, 109M Inact, 235M Wired, 22M Cache, 111M Buf, 12M Free
Swap: 2048M Total, 224K Used, 2048M Free

  • Active计算已用内存 ( + wired) 和可用内存 ( )的变化Free。
    在本例中，已用内存增加了 161MB ((447+233)-(606+235))，可用内存减少了 158MB。
    （在其他条件相同的情况下，这些数字应该相等或非常接近，差异由其他字段（如非​​活动内存或缓冲区空间）的变化弥补）。

  • 上述最悲观的数字是用于猜测 RAM 利用率的良好数字。

    • 对您正在调查的程序的其他实例重复上述操作，并在图表上绘制变化以确定趋势/曲线。

    单个实例内存使用路径

    此方法检查与您正在调查的程序相关的单个进程。
    按上述方法操作，但不要查看top输出的标题，而是查看启动程序时生成的各个进程（我将使用 Postgres 作为示例）：

      PID USERNAME     THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
 4883 pgsql          1  58    0   181M   146M sbwait  0  24.3H  6.59% postgres
 5842 pgsql          1  44    0   149M   119M sbwait  1 376:03  0.00% postgres
 2051 pgsql          1  44    0 62944K 34836K select  1  21:39  0.00% postgres
 2054 pgsql          1  44    0 31672K  4220K select  1   6:31  0.00% postgres
 2052 pgsql          1  44    0 62944K  5368K select  0   6:00  0.00% postgres
 2053 pgsql          1  44    0 62944K  5484K select  1   1:11  0.00% postgres
 4884 pgsql          1  44    0 62944K  9144K sbwait  1   1:00  0.00% postgres
 1902 pgsql          1  44    0 62944K  5348K select  1   0:46  0.00% postgres

    将与您的应用程序相关的每个进程的常驻（）大小加起来RES，并记下它作为 RAM 的使用量。（常驻大小和虚拟大小（VSIZE或仅仅是SIZE）之间的差值）。

    此方法有一些注意事项：

    1. 尺寸膨胀或缩小
      RESident 大小并不能说明全部情况：共享库会被加载，而这些共享库不计入常驻大小，因此，如果您像我上面所说的那样将常驻大小加起来，那么您的数字将低于实际利用率。
      共享库是计算虚拟大小（VIRT或只是普通大小SIZE），但它们会被计入使用它们的每个程序中，因此如果你将虚拟大小加起来，你的数字将高于实际利用率——通常明显高于.
      的某些版本top还单独拆分出交换 — — 如果您的程序有内存泄漏（或者大量数据过期并被交换出去）这也会使您的数据产生偏差。

    2. 缺失流程
      如果不计算启动程序后产生的所有相关进程，则总 RAM 使用量将低于实际值。

    最后，有一个适用于这两种方法的警告：动态应用程序会弄乱你的数字。
    我的意思是，像 Postgres 或 Apache 这样的程序会生成新线程或新子进程来处理用户请求，但在静态条件下无法给出准确的图像：您需要对程序施加工作负载，这样才能衡量工作负载对系统的影响（这是我觉得聚合路径更容易的另一个原因：您不必追踪所有子进程，只需在增加工作负载时读取标题即可）。

    理想情况下，您将在测试期间对服务器施加非常大的负载，以确保正常的生产负载不会使其开始破坏其交换空间。此外，一旦您完成了大小调整，您就应该始终添加一些缓冲 RAM（我使用的 RAM 比最坏情况的运行结果高出 10%），并确保您的系统有足够的 RAM 来处理峰值负载情况。
    请记住：RAM 很便宜，停机时间很昂贵。在服务器构建期间，您可以随时投入更多 RAM 来解决问题，边际成本可能低于必须关闭系统以在以后添加 RAM。

    请注意，我的所有top输出均来自 FreeBSD——您的具体标签可能有所不同。请查阅您系统的手册页以top找出相应的字段。

    相关内容