服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 我如何测量每个Glassfish域所需的内存量？
Intereting Posts
购买托pipe服务时需要OSS许可证吗？ SQL Server 2016 Web备份到URL 如果一个软件包没有安装应用程序，我该怎么办？ 如何使kern.ipc.somaxconn的设置保持不变？ 语音接线板连接到外部对 Azure AD域服务和客户端PC 在两台服务器之间创build共享文件 克朗的工作似乎并没有工作 DPM 2010代理问题 规划SQL数据库大小要求的工具 错误在PHP不logging或显示 Bind9在Debian上返回SERVFAIL，而configuration似乎是理智的 作为Apache2服务器的反向代理清除端口redirect问题 SELinux：限制httpd出站连接的地址和端口？ 如何安排batch file在启动或closures时运行？

我如何测量每个Glassfish域所需的内存量？

在我们的testing环境中，我们有很多应用程序分布在几个服务器和Glassfish域中。 为了使版本更简单，我希望每个应用程序每个客户都有一个Glassfish域（类似于许多docker实例的重量级版本）。

我听说Glassfish是资源密集型的，所以我想测量大概有多less实例可用于RAM。 我知道我可以通过启动实例和观察top输出来做到这一点，但是我应该专注于哪些具体的统计数据来获得每个实例的资源消耗的良好衡量标准？

使用top来确定内存需求是一门艺术而不是一门精确的科学。 有两个主要的方法去做。

在这两种情况下，您都希望在开始正在调查的程序之前（在您的情况下使用GlassFish）来获取系统资源使用情况的基线。 然后你遵循两个path之一：

聚合内存使用path

这是我个人这样做的方式，因为我觉得它可以更好地了解整体资源利用情况。
另外，如果你搞砸了，你可能会得到一个更大的数字，而不是一个较小的数字。

  • 在某个terminal运行top ，并注意头部输出。
    要特别注意主动和有线内存： 
    •  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）），可用内存减less了158MB。
    （所有其他条件相同时，这些数字应该相等或非常接近，其差别由其他字段（如Inactive memory或Buffer space）中的更改组成。
  • 上述数字中最悲观的是用于猜测RAM利用率的一个好数字。

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

    单个实例内存使用path

    此方法检查与您正在调查的程序相关的个别进程。
    按照上面的步骤进行操作，除了看看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. 规模通货膨胀或通货紧缩
      RES ident大小并不能说明整个故事：共享库得到加载，并且这些不是以居民身份的大小计算的，所以如果像上面所说的那样总计居民的大小，那么你的数量将低于实际的利用率。
      共享库以虚拟大小（ VIRT或简单SIZE ）计算，但是它们会根据使用它们的每个程序进行计数，所以如果总计虚拟大小，您的数量将高于实际利用率 – 通常大大高于实际大小。
      一些版本的top也分开了Swap分开 – 如果你的程序有内存泄漏（或大量的数据陈旧和被换出），这也可以扭曲你的数字。

    2. 缺less进程
      如果你不计算所有由于启动你的程序而产生的相关进程，你的总内存使用量将会低于实际值。

    最后有一个警告适用于这两种方法： dynamic应用程序将混乱你的数字 。
    我的意思是说像Postgres或Apache这样的程序，可以产生新的线程或者新的subprocess来服务用户请求，在静态条件下不会给出精确的图片：你需要在程序上加载一个工作负载，以便测量工作量对系统的影响（这是我find聚合path更容易的另一个原因：你不必搜寻所有的孩子，你可以在加大工作量的时候阅读标题）。

    理想情况下，在testing过程中，您会在服务器上负担很重的负担，以确保正常的生产负载不会使其开始颠簸交换空间。 同样，一旦你完成你的尺寸，你应该总是添加一些缓冲RAM（我使用10％以上，最坏的情况下运行结果），并确保您的系统有足够的内存来处理作为峰值负载条件。
    请记住：RAM很便宜，停机时间也很昂贵。 在服务器构build过程中，您可以随时抛出更多的RAM，边际成本可能会比closures系统以稍后添加RAM的成本更低。

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