Ubuntu 16.04 никогда не заменяется
Я использую Xubuntu 16.04 на своем ноутбуке, установленном из дистрибутива Xubuntu 14. Ноутбук имеет 10 ГБ оперативной памяти и 4 ГБ подкачки. Недавно я обновил ядро до версии: 4.15.0-51
Проблема в том, что во время нормальной работы система со временем выключается, но никогда не переключается обратно. Таким образом, после часов / дней безотказной работы пространство подкачки заполняется. Даже после закрытия всех основных процессов объем используемой оперативной памяти достигает нескольких сотен МБ, но подкачка остается полной. Кроме того, цикл по всем / proc / * / stats и grep VmSwap возвращает 0 кБ для всех процессов.
Как можно отладить, почему ядро не подменяется? Как будто ядро теряет информацию о том, кому принадлежат страницы подкачки. Я уже потратил значительное количество времени, пытаясь исправить это безуспешно. Единственный поворот, который у меня сейчас есть, - это скрипт, который создает и перерабатывает (swapoff; swapon) несколько файлов подкачки.
Спасибо за любую помощь.
2 ответа
Сегодня я дал его, другой пытается, нашел проблему.
Запущенный путем проверки снова meminfo информации. Вот вывод cat /proc/meminfo:
MemTotal: 10133276 kB
MemFree: 2617372 kB
MemAvailable: 4660420 kB
Buffers: 503472 kB
Cached: 3825884 kB
SwapCached: 59448 kB
Active: 3852624 kB
Inactive: 3112996 kB
Active(anon): 2688920 kB
Inactive(anon): 2245220 kB
Active(file): 1163704 kB
Inactive(file): 867776 kB
Unevictable: 32 kB
Mlocked: 32 kB
SwapTotal: 6096888 kB
SwapFree: 2644324 kB
Dirty: 52 kB
Writeback: 0 kB
AnonPages: 2576972 kB
Mapped: 770460 kB
Shmem: 2297836 kB
Slab: 391072 kB
SReclaimable: 325960 kB
SUnreclaim: 65112 kB
KernelStack: 15824 kB
PageTables: 53492 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 11163524 kB
Committed_AS: 12259512 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
HardwareCorrupted: 0 kB
AnonHugePages: 2048 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 349640 kB
DirectMap2M: 10039296 kB
Несмотря на проблему наличия 4 ГБ подкачки, используемой ничем, на этот раз, 2 ГБ используемого shmem привлекли мое внимание.
Ища это, я нашел этот вопрос с ответом: Высокое использование памяти SHMem!
Так, короче говоря, наличие высокого shmem использования может быть связано с tmpfs каталогами. В моем случае, /dev использовал почти 4,8 ГБ
Вот вывод df -h:
Filesystem Size Used Avail Use% Mounted on
udev 4,8G 4,8G 0 100% /dev
tmpfs 990M 34M 956M 4% /run
/dev/sda2 255G 232G 11G 96% /
tmpfs 4,9G 220M 4,7G 5% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 4,9G 0 4,9G 0% /sys/fs/cgroup
/dev/sda5 333G 208G 126G 63% /media/dados
cgmfs 100K 0 100K 0% /run/cgmanager/fs
tmpfs 990M 88K 990M 1% /run/user/1000
После этого я просто искал в /dev для преступника, использующего du команда. Равно как и упомянуто в потоке я связался выше, это было bootchart команда, которая хранила огромные файлы журнала в /dev каталог.
Спасибо за справку.
Вам не нужно беспокоиться об этом. Посмотрите, например, здесь . Ядро отслеживает его, и оно может освободить место в свопе.