相关疑难解决方法(0)

这看起来很基本，但我对手动更新独立 VMware ESXi 主机所涉及的修补策略感到困惑。VMware vSphere 博客试图对此进行解释，但实际过程对我来说仍然不清楚。

来自博客：
Say Patch01 包括以下 VIB 的更新：“esxi-base”、“driver10”和“driver 44”。然后后来 Patch02 推出了对“esxi-base”、“driver20”和“driver 44”的更新。P2 是累积性的，因为“esxi-base”和“driver44”VIB 将包含 Patch01 中的更新。但是，重要的是要注意 Patch02 不包括“驱动程序 10”VIB，因为该模块未更新。

这篇VMware 社区帖子给出了不同的答案。这一个与另一个矛盾。

我遇到的许多 ESXi 安装都是独立的，不使用Update Manager。可以使用通过VMWare 补丁下载门户提供的补丁更新单个主机。这个过程很简单，所以这部分是有道理的。

更大的问题是确定什么确切实际下载和安装。就我而言，我有大量特定于 HP 的 ESXi 版本，其中包含适用于 HP ProLiant 硬件的传感器和管理。

• 假设这些服务器从 9/2011 开始使用 ESXi build #474610。
• 查看下面的补丁门户屏幕截图，有一个适用于 ESXi update01 的补丁，版本号 #623860。还有 #653509 和 #702118 版本的补丁。
• 即将推出旧版 ESXi（例如供应商特定版本），使系统完全更新的正确方法是什么？哪些补丁是累积的，哪些需要按顺序应用？安装最新版本是正确的方法，还是我需要退后一步并逐步修补？
• 另一个考虑因素是补丁下载量很大。在带宽有限的站点，下载多个~300mb 的补丁很困难。

尽管我的系统上有足够多的可用 RAM，但 OOM 杀手似乎正在杀死一些东西：

（全分辨率）

（全分辨率）

27 分钟和 408 个进程后，系统再次开始响应。大约一个小时后我重新启动它，此后不久内存利用率恢复正常（对于这台机器）。

经过检查，我的盒子上运行了一些有趣的进程：

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
[...snip...]
root      1399 60702042  0.2 482288 1868 ?     Sl   Feb21 21114574:24 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
[...snip...]
mysql     2022 60730428  5.1 1606028 38760 ?   Sl   Feb21 21096396:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
[...snip...]

这个特定的服务器已经运行了大约。8 小时，这是仅有的两个具有这种……奇数值的过程。我怀疑是“其他事情”正在发生，可能与这些荒谬的价值观有关。具体来说，我认为系统认为内存不足，而实际上并非如此。毕竟，它认为 rsyslogd 始终使用 55383984% 的 CPU，而无论如何在该系统上理论最大值为 400%。

这是具有 768MB RAM 的完全最新的 CentOS 6 安装 (6.2)。任何有关如何弄清楚为什么会发生这种情况的建议将不胜感激！

编辑：附加虚拟机。sysctl 可调参数..我一直在玩swappiness（它是100），我还在运行一个非常糟糕的脚本，它转储我的缓冲区和缓存（vm.drop_caches 是3）+同步磁盘每个15分钟。这就是为什么在重新启动后，缓存数据增长到正常大小，但随后又迅速下降的原因。我认识到拥有缓存是一件非常好的事情，但是直到我弄清楚... …