В настоящее время я испытываю проблему с памятью в моем дистрибутиве centos 7.6.
Это началось с замены моей системы, хотя должно было быть доступно до 80 ГБ оперативной памяти.
free -m
total used free shared buff/cache available
Mem: 321931 239140 1291 79929 81498 1188
Swap: 30015 29681 334
Предыдущий результат был 0 без свопа
Имейте в виду, что для swapipiness установлено значение 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 ГБ, а общий / buff / cache содержит 80 ГБ физической ОЗУ и не передает ее системе.
Я попытался очистить кеш при первом запуске sync; echo 1 | sudo tee /proc/sys/vm/drop_caches что освободило 4гб. Но это было возвращено в течение 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 ГБ доступной оперативной памяти недоступны. Я снова обратил внимание на devtmpfs. Что может быть за 100 ГБ?
Я думаю, что на этом стыке я должен упомянуть, что этот сервер виртуализирован и разделен на разделы. Он использует LVM и имеет довольно много виртуальных машин. На нем 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
Я пошел на поиски того, что использовало 100 ГБ в / dev, и нашел это
~]# 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 на самом деле использует память подкачки. Как это возможно?
Я не совсем уверен, что здесь происходит, и никогда не видел такого поведения. Я бы предпочел восстановить своп и немного ОЗУ без перезагрузки, но есть ли способ, которым это возможно, поскольку я сейчас в затруднении?
Спасибо.
РЕДАКТИРОВАТЬ
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 - это просто группа томов, находящаяся на диске sdb в разделе номер 1 (весь диск), который представляет собой хранилище 10 ТБ.
Просмотрите физические тома с помощью pvs. Если вы видите один под /dev/vg2 вы использовали /dev файловая система в разделяемой памяти как диск. Немедленно перенесите это с помощью pvmove если вы заботитесь о том, чтобы ваши данные сохранились после следующей перезагрузки.
Чтобы избежать этого в будущем, создавайте и расширяйте группы VG только с дисковыми устройствами, например, существующее устройство под /dev/disk/. Кроме того, при работе с логическими томами ведущие /dev, так lvextend vg2/lv3.
/proc/sys/vm/drop_caches полезен только для холодных кешей в тестах производительности. Не пытайтесь использовать его для операций.
Имейте в виду, что для swapipiness установлено значение 10, поэтому такого поведения не должно быть.
Зачем вам пространство подкачки, если его нельзя использовать? Committed_AS составляет 135% от общей памяти, он будет выгружен.
Конечно, около 100 ГБ - подозрение. Если вы не собираетесь настраивать общую память (вероятно, для баз данных), она настроена неправильно. Если вы это сделаете, большие страницы повысят эффективность.