我目前正经历一个记忆问题,在我的中心7.6发行版。
它从我的系统交换开始,尽管应该有高达80 my的内存可用。
free -m
total used free shared buff/cache available
Mem: 321931 239140 1291 79929 81498 1188
Swap: 30015 29681 334之前的结果是零交换自由。
请记住,调皮是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使用的是100 it,共享/buff/cache保存的是80 it的物理内存,而不是将其释放给系统。
我试图首先清除运行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因此,系统似乎不应该开始这样的交换,但是,交换空间已经满了,而且我认为80 my的可用内存是不可访问的。我把注意力转回到了devtmpfs上。什么可能是使用100 be?
我想在这个交界处,我应该提到这台服务器是虚拟化和分区的。它使用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中搜索了使用100 in的内容,并找到了以下内容
~]# 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 ia只是驻留在分区号1(整个磁盘)中的sdb磁盘上的卷组,它是一个10 in存储。
发布于 2019-04-29 18:42:19
使用pvs查看物理卷。如果您在/dev/vg2下看到一个文件系统,您已经将共享内存中的/dev文件系统用作磁盘。如果您关心您的数据在下一次重新启动时幸存下来,请立即使用pvmove迁移。
为了避免将来发生这种情况,只需使用磁盘设备(例如/dev/disk/下的现有设备)创建和扩展VGs。此外,在处理逻辑卷时,不需要领先的/dev,因此不需要lvextend vg2/lv3。
/proc/sys/vm/drop_caches仅适用于性能基准测试中的冷缓存。不要费心尝试使用它来操作。
请记住,调皮是10,所以这种行为不应该发生在最初。
如果不使用分页空间,为什么要有分页空间?Committed_AS是您总内存的135%,它将分页退出。
当然,大约100 GB是可疑的。如果不打算配置共享内存(可能用于数据库),则配置不正确。如果你这么做了,那么巨大的页面将会提高效率。
https://serverfault.com/questions/965137
复制相似问题