☰

VmHWM은 25%에 불과하지만 약 80%여야 합니다.

tag-icon • tag-icon memory out-of-memory
VmHWM은 25%에 불과하지만 약 80%여야 합니다.

128GB RAM을 갖춘 전용 MySQL 서버가 있습니다. MySQL은 최악의 경우 95GB를 사용하도록 구성되어 있음에도 불구하고 최근 oom-killer에 의해 종료되었습니다. 내 연구에서 나는 다음을 발견했습니다.

# 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가 약 33GB에 불과한 반면 다른 서버(동일한 마스터의 슬레이브이며 256GB 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

90GB의 낭비된 공간을 확보합니다. 이는 다음 출력에서 ​​볼 수 있습니다 cat /proc/meminfo.

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

매튜 아이브에게 깊은 감사를 드립니다. 좋아요를 눌러주세요그의 대답이 사이트 대신 serverfault.com을 방문하세요.

관련 정보