Memory

VmHWM 只有 25% 而應該是 80% 左右

  • May 15, 2017

我有一個配備 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 再次襲擊之前不久觀察到的)。可能是什麼原因?沒有競爭過程。我能做些什麼呢?

因此,事實證明,一位同事正在試驗大頁面支持,並沒有恢復他所做的所有更改。當我跑

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

非常感謝 Matthew Ife。請在 serverfault.com 上對他的回答進行投票,而不是這個。

引用自:https://unix.stackexchange.com/questions/364643