诊断 Solaris 8 服务器内存和交换空间使用情况

诊断 Solaris 8 服务器内存和交换空间使用情况

本质上,我的问题与 Solaris 虚拟机的内存分配有关。

我在两台 Solaris 8 虚拟机上运行了几个旧的 Sun ONE 6 Java Web 服务器。我发现使用的交换空间数量合理,但我不确定这是否意味着需要为这些机器添加更多 RAM。

在服务高峰时段(通常是早上),这些服务器托管的 Web 应用程序的响应时间最多会跳升至 11 秒(对于相对简单的网页加载操作来说​​,这有点不利)。非高峰时段的平均响应时间约为 5 秒。

从下面的输出中,你能推断出这些机器的 RAM 使用情况吗?这些信息是否足够?或者我需要运行其他命令来排除服务器内存不足的情况?

最后,由于设置的核心是一个 Java 应用程序,因此我还考虑了:

1)跟踪堆的对象分配以检测潜在的内存泄漏。

2) 进行一些性能分析,看看这是否与网络延迟有关。我提到这一点是因为应用程序与单个 Oracle 数据库通信,但我怀疑情况并非如此,因为从网络分段的角度来看它们非常接近。

我感谢您提供的任何见解和反馈。

感谢您的时间和帮助。

服务器 1:

40 processes:  38 sleeping, 1 zombie, 1 on cpu
CPU states: 99.1% idle,  0.4% user,  0.4% kernel,  0.0% iowait,  0.0% swap
Memory: 2048M real, 295M free, 865M swap in use, 3788M swap free

   PID USERNAME THR PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
 12676 webservd 112  29   10  616M  242M sleep  103:37  0.48% webservd
 18317 root       1  59    0   23M   19M sleep   67:24  0.08% perl
  9479 support    1  59    0 6696K 2448K cpu/1    0:11  0.05% top
  8012 root      10  59    0   34M  704K sleep   80:54  0.04% java
  1881 root      33  29   10  110M   13M sleep   33:03  0.02% webservd
  7808 root       1  59    0   83M   67M sleep    7:59  0.00% perl
  1461 root      20  59    0 5328K 1392K sleep    6:49  0.00% syslogd
  1691 root       2  59    0   27M  680K sleep    4:22  0.00% webservd
 24386 root       1  59    0   15M   11M sleep    2:50  0.00% perl
 23259 root       1  59    0   11M 4240K sleep    2:42  0.00% perl
 24718 root       1  59    0   11M 5464K sleep    2:29  0.00% perl
 22810 root       1  59    0   19M   11M sleep    2:21  0.00% perl
 24451 root       1  53    2   11M 3800K sleep    2:18  0.00% perl
 18501 root       1  56    1   11M 3960K sleep    2:18  0.00% perl
 14450 root       1  56    1   15M 6920K sleep    1:49  0.00% perl

服务器 2

 42 processes:  40 sleeping, 1 zombie, 1 on cpu
CPU states: 98.8% idle,  0.4% user,  0.8% kernel,  0.0% iowait,  0.0% swap
Memory: 1024M real, 31M free, 554M swap in use, 3696M swap free

   PID USERNAME THR PRI NICE  SIZE   RES STATE    TIME    CPU COMMAND
  5607 webservd  74  29   10  284M  173M sleep   20:14  0.21% webservd
 15919 support    1  59    0 4056K 2520K cpu/1    0:08  0.09% top
 13138 root      10  59    0   34M 1952K sleep  210:51  0.08% java
 13753 root       1  59    0   22M   12M sleep  170:15  0.07% perl
 22979 root      33  29   10  112M 7864K sleep   85:07  0.04% webservd
 22930 root       1  59    0 3424K 1552K sleep   17:47  0.01% xntpd
 22978 root       2  59    0   27M 2296K sleep   10:49  0.00% webservd
 13571 root       1  59    0 9400K 5112K sleep    5:52  0.00% perl
  5606 root       2  29   10   29M 9056K sleep    0:36  0.00% webservd
 15910 support    1  59    0 9128K 2616K sleep    0:00  0.00% sshd
 13106 root       1  59    0   82M 3520K sleep    7:47  0.00% perl
 13547 root       1  59    0   12M 5528K sleep    6:38  0.00% perl
 13518 root       1  59    0 9336K 3792K sleep    6:24  0.00% perl
 13399 root       1  56    1 8072K 3616K sleep    5:18  0.00% perl
 13557 root       1  53    2 8248K 3624K sleep    5:12  0.00% perl

答案1

要确定您的服务器是否缺少 RAM,一个有用的指标是 vmstat 命令输出中的 sr 列。只需vmstat 10 10在参考和高峰期(每 10 秒 10 个样本)运行类似命令并发布输出。swap -s输出也很有用。除了 vmstat,您可能更喜欢运行sar -g 5 5 无论如何,根据“top”输出,server2 似乎缺少 RAM。Solaris 有一个类似于 top 的支持命令,它也可能有助于识别虚拟和物理内存消耗者:

prstat -s rss -n 5
prstat -s size -n 5

答案2

这些快照中让我印象深刻的是以下内容:

  • 大量 perl 进程
  • 多个 webservd 进程
  • 机器闲置率达 98% 和 99%

这些事实引出了以下问题...

  • 你能减少 perl 进程的数量吗?
  • 我认为没有办法切换到线程 Web 服务器模型?
  • 当机器承受压力时,系统顶部是什么样子的?

最后,我将执行以下操作来追踪此问题:

  • 使用 Wireshark 之类的网络嗅探器查看 HTTP 进程的哪一部分实际上被阻止了。是连接吗?是页面的传送吗?是页面动态部分的传送吗?
  • 获取 HTTP 压力工具并对您的 Web 服务器施加压力,以查看它们的反应。使用 vmstat 和 top 查看响应:我喜欢在终端中使用 screen 来执行此操作。

祝你好运!

答案3

我一直认为跟踪内存使用情况的最简单方法是系统记账。它可能会跳来跳去,因此至少要检查一周以了解使用模式。

编辑“sys”crontab,您将看到一些注释掉的脚本 /usr/lib/sa/sa1 的运行。它的运行频率决定了保存的会计数据的时间分辨率。我通常对 24x7 系统执行类似这样的操作:

20,40 * * * * /usr/lib/sa/sa1

这会按月日将统计信息存储在 /var/adm/sa 中。现在,您可以使用 sar 转储存储在其中的任何一天的内存统计信息。假设第 3 天是我的高峰日:

sar -f /var/adm/sa/sa03 -g

主要关注的列是 pgscan/s。如果该数字长时间超过 200,则系统内存不足。当值为 100 时,您可能会从更多内存中受益,但性能下降并不严重。如今磁盘交换比内存慢得多,除了短期跳跃外,我尝试将其保持在 0。

相关内容