☰

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

Matthew Iveに感謝します。いいねを押してください彼の答えこのサイトの代わりにserverfault.comにアクセスしてください。

関連情報