☰

VmHWM 只有 25%，而应该在 80% 左右

tag-icon • tag-icon memory out-of-memory
VmHWM 只有 25%，而应该在 80% 左右

我有一个配备 128 GB RAM 的专用 MySQL 服务器。 MySQL 最近被 oom-killer 杀死，尽管 MySQL 配置为在最坏情况下使用 95 GB。在我的研究中我发现了这一点：

# cat /proc/11895/status
Name:   mysqld
State:  S (sleeping)
Tgid:   11895
Pid:    11895
PPid:   24530
TracerPid:      0
Uid:    27      27      27      27
Gid:    27      27      27      27
Utrace: 0
FDSize: 1024
Groups: 27
VmPeak: 72188044 kB
VmSize: 72122508 kB
VmLck:         0 kB
VmHWM:  33294036 kB
VmRSS:  32829668 kB
VmData: 72076496 kB
VmStk:        88 kB
VmExe:     11800 kB
VmLib:      3608 kB
VmPTE:     73388 kB
VmSwap:  4139376 kB
Threads:        59

我想知道，为什么 VmHWM 和 VmRSS 只有 33 GB 左右，而在另一台服务器上（也是同一个主服务器的从属服务器，配置几乎相同（除了缓冲池），除了它有 256 GB RAM），输出如下：

# cat /proc/51298/status
Name:   mysqld
State:  S (sleeping)
Tgid:   51298
Pid:    51298
PPid:   50443
TracerPid:      0
Uid:    27      27      27      27
Gid:    27      27      27      27
Utrace: 0
FDSize: 2048
Groups: 27
VmPeak: 243701128 kB
VmSize: 239628932 kB
VmLck:         0 kB
VmHWM:  209331200 kB
VmRSS:  205515868 kB
VmData: 239582156 kB
VmStk:        88 kB
VmExe:     11800 kB
VmLib:      3608 kB
VmPTE:    409600 kB
VmSwap:        0 kB
Threads:        281

这里的内存使用率约为 80%，而在 oom-killed 服务器上，内存使用率约为 25%（请注意，这些值是在 oom-killer 再次攻击之前不久观察到的）。可能是什么原因？不存在竞争过程。我能做什么呢？

答案1

所以，事实证明，一位同事正在试验大页面支持并没有恢复他所做的所有更改。当我运行

sysctl -w vm.nr_hugepages=0

并在/etc/sysctl.conf

# Hugepage Support MySQL
#vm.hugetlb_shm_group = 27
#kernel.shmmax = 10737418240
#kernel.shmall = 23689185
#vm.nr_hugepages = 46268

它释放了 90 GB 被浪费的空间。这可以在以下输出中看到cat /proc/meminfo：

HugePages_Total:   46268
HugePages_Free:    46268
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

非常感谢马修·伊夫。请点赞他的回答访问 serverfault.com 而不是这个。

相关内容