スワップメモリの異常
現在、centos7.6ディストリビューションでメモリの問題が発生しています。
最大80GBのRAMが利用可能であるはずだったにもかかわらず、それは私のシステムの交換から始まりました。
free -m
total used free shared buff/cache available
Mem: 321931 239140 1291 79929 81498 1188
Swap: 30015 29681 334
以前の結果は0スワップフリーでした
スワッピネスは10に設定されているため、この動作は最初から発生しないことに注意してください。
df -hは、devtmpfs（/ dev）によって占有されている多くのスペースを示していますが、使用中の一時メモリーである必要があるため、そうではないはずです。
~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vlmgrp1-OS 79G 51G 28G 65% /
devtmpfs 158G 100G 58G 64% /dev
tmpfs 158G 0 158G 0% /dev/shm
tmpfs 158G 4.0G 154G 3% /run
tmpfs 158G 0 158G 0% /sys/fs/cgroup
/dev/nvme0n1p2 1014M 232M 783M 23% /boot
tmpfs 32G 0 32G 0% /run/user/0
tmpfs 32G 0 32G 0% /run/user/993
ご覧のとおり、/ devは100GBを使用しており、shared/buff/cacheは80GBの物理RAMを保持しており、システムにリリースしていません。
最初にsync; echo 1 | Sudo tee /proc/sys/vm/drop_cachesを実行してキャッシュをクリアしようとしましたが、これにより4GBが解放されました。しかし、これは30秒以内に取り戻されました。次に、sync; echo 2 | Sudo tee /proc/sys/vm/drop_cachesとsync; echo 3 | Sudo tee /proc/sys/vm/drop_cachesは、それ以上何もリリースしませんでした。
swapoff -a && swapon -aも結果を出さず、5時間と重い負荷の後、スワップにはまだ0の空きがありました。
~]# ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
出力なし
~]# ipcs -lm
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 18014398509465599
max total shared memory (kbytes) = 18014398442373116
min seg size (bytes) = 1
~]# cat /proc/meminfo
MemTotal: 329657664 kB
MemFree: 1817656 kB
MemAvailable: 1476420 kB
Buffers: 14968 kB
Cached: 81813132 kB
SwapCached: 1098308 kB
Active: 231698396 kB
Inactive: 90111876 kB
Active(anon): 231527424 kB
Inactive(anon): 90073660 kB
Active(file): 170972 kB
Inactive(file): 38216 kB
Unevictable: 25724 kB
Mlocked: 25724 kB
SwapTotal: 30736380 kB
SwapFree: 10668 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 238909760 kB
Mapped: 57984 kB
Shmem: 81611272 kB
Slab: 1126844 kB
SReclaimable: 454628 kB
SUnreclaim: 672216 kB
KernelStack: 35296 kB
PageTables: 566588 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 195565212 kB
Committed_AS: 446505420 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 2154028 kB
VmallocChunk: 34189572924 kB
HardwareCorrupted: 0 kB
AnonHugePages: 44908544 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 816952 kB
DirectMap2M: 146685952 kB
DirectMap1G: 189792256 kB
~]# grep -R swap /usr/lib/tuned | grep swappiness
/usr/lib/tuned/latency-performance/tuned.conf:# The swappiness parameter controls the tendency of the kernel to move
/usr/lib/tuned/latency-performance/tuned.conf:vm.swappiness=10
/usr/lib/tuned/throughput-performance/tuned.conf:# The swappiness parameter controls the tendency of the kernel to move
/usr/lib/tuned/throughput-performance/tuned.conf:vm.swappiness=10
/usr/lib/tuned/virtual-guest/tuned.conf:vm.swappiness = 10
したがって、システムはこの程度までスワップを開始するべきではなかったようですが、それでもスワップはいっぱいで、おそらく80GBが使用可能ですRAMはアクセスできません。devtmpfsに注意を向けました。 100GBを使用していますか？
このジャンクションでは、このサーバーが仮想化され、パーティション化されていることに言及する必要があると思います。 LVMを使用し、かなりの数のVMがあります。その上に5つのメインボリュームグループがあります。
~]# vgscan
Reading volume groups from cache.
Found volume group "vg1" using metadata type lvm2
Found volume group "vg2" using metadata type lvm2
Found volume group "vg3" using metadata type lvm2
Found volume group "vg" using metadata type lvm2
Found volume group "nvmessd1" using metadata type lvm2
/ devで100GBを使用しているものを探して、これを見つけました
~]# du -h /dev
0 /dev/system
0 /dev/pve
0 /dev/centos
0 /dev/vg
0 /dev/vg3
100G /dev/vg2
0 /dev/vg1
0 /dev/nvmessd1
0 /dev/vfio
0 /dev/snd
0 /dev/net
0 /dev/mqueue
0 /dev/hugepages/libvirt/qemu
0 /dev/hugepages/libvirt
0 /dev/hugepages
0 /dev/vlmgrp1
0 /dev/disk/by-label
0 /dev/disk/by-partuuid
0 /dev/disk/by-partlabel
0 /dev/disk/by-uuid
0 /dev/disk/by-path
0 /dev/disk/by-id
0 /dev/disk
0 /dev/block
0 /dev/bsg
0 /dev/dri
0 /dev/char
0 /dev/mapper
0 /dev/pts
0 /dev/shm
0 /dev/input/by-path
0 /dev/input/by-id
0 /dev/input
0 /dev/bus/usb/002
0 /dev/bus/usb/001
0 /dev/bus/usb
0 /dev/bus
0 /dev/raw
0 /dev/cpu/23
0 /dev/cpu/22
0 /dev/cpu/21
0 /dev/cpu/20
0 /dev/cpu/19
0 /dev/cpu/18
0 /dev/cpu/17
0 /dev/cpu/16
0 /dev/cpu/15
0 /dev/cpu/14
0 /dev/cpu/13
0 /dev/cpu/12
0 /dev/cpu/11
0 /dev/cpu/10
0 /dev/cpu/9
0 /dev/cpu/8
0 /dev/cpu/7
0 /dev/cpu/6
0 /dev/cpu/5
0 /dev/cpu/4
0 /dev/cpu/3
0 /dev/cpu/2
0 /dev/cpu/1
0 /dev/cpu/0
0 /dev/cpu
100G /dev
私には、/ dev/vg2が実際にスワップメモリを使用しているように見えます。これはどのように可能ですか？
私はここで何が起こっているのか正確にはわかりませんし、そのような行動を目撃したことはありません。再起動せずにスワップといくつかのRAMを復元したいのですが、現在途方に暮れているので、これが可能な方法はありますか？.
ありがとう。
編集
pvsにも奇妙なエラーがありますが、これはこの問題に関連していると推測でき、vg2が正しい場所にありません。
~]# pvs
Error reading device /dev/centos/root at 0 length 512.
Error reading device /dev/centos/root at 0 length 4.
Error reading device /dev/centos/root at 4096 length 4.
Error reading device /dev/system/var at 0 length 512.
Error reading device /dev/system/var at 0 length 4.
Error reading device /dev/system/var at 4096 length 4.
Error reading device /dev/system/tmp at 0 length 512.
Error reading device /dev/system/tmp at 0 length 4.
Error reading device /dev/system/tmp at 4096 length 4.
Error reading device /dev/system/swap at 0 length 512.
Error reading device /dev/system/swap at 0 length 4.
Error reading device /dev/system/swap at 4096 length 4.
Error reading device /dev/system/backup at 0 length 512.
Error reading device /dev/system/backup at 0 length 4.
Error reading device /dev/system/backup at 4096 length 4.
PV VG Fmt Attr PSize PFree
/dev/mapper/vg2-vsv1685--dsakekjloo2ddm0a--eahin7pr71l0fwlc2 vg lvm2 a-- <99.88g 0
/dev/nvme0n1p3 vg3 lvm2 a-- 1.86t 651.28g
/dev/nvme1n1 nvmessd1 lvm2 a-- 1.86t <555.72g
/dev/sda1 vg1 lvm2 a-- <9.10t 4.04t
/dev/sdb1 vg2 lvm2 a-- <9.10t 3.74t
ご覧のとおり、vg2は、10TBのストレージであるパーティション番号1（ディスク全体）のsdbディスクにあるボリュームグループです。
pvsを使用して物理ボリュームを確認します。 /dev/vg2の下に表示されている場合は、共有メモリ内の/devファイルシステムをディスクとして使用しています。データが次回の再起動後も存続することに関心がある場合は、pvmoveを使用してこれをすぐに移行してください。
今後これを回避するには、/dev/disk/の下にある既存のデバイスなどのディスクデバイスでのみVGを作成および拡張します。さらに、論理ボリュームで作業する場合、先頭の/devは必要ないため、lvextend vg2/lv3です。
/proc/sys/vm/drop_cachesは、パフォーマンスベンチマークのコールドキャッシュにのみ役立ちます。わざわざ操作に使用しないでください。
スワップ性は10に設定されているため、この動作は最初から発生しないことに注意してください。
使用しないのに、なぜページングスペースがあるのでしょうか。 Committed_ASは合計メモリの135％であり、ページアウトします。
確かに約100GBが疑わしいです。 （データベース用に）共有メモリを構成する予定がない場合は、正しく構成されていません。そうした場合、巨大なページは効率を改善します。