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 再次襲擊之前不久觀察到的)。可能是什麼原因?沒有競爭過程。我能做些什麼呢?
因此,事實證明,一位同事正在試驗大頁面支持,並沒有恢復他所做的所有更改。當我跑
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 上對他的回答進行投票,而不是這個。