Вопрос или проблема
У меня есть системы Ubuntu 18, 22, 24. Когда пользовательские приложения не запущены, 18 и 22 версии обычно используют около 2-3 ГБ ОЗУ. Я заметил, что мои системы с версией 24 (все созданные с одного образа) используют около 8-9 ГБ ОЗУ. Это сразу после загрузки. У меня достаточно свободной оперативной памяти на этой системе, но на другой системе имеется всего 12 ГБ оперативной памяти, и остается 3 ГБ свободной, что привело к проблемам. Именно тогда я это впервые заметил.
# free -m
total used free shared buff/cache available
Mem: 64224 10426 53834 42 576 53797
Swap: 0 0 0
Глядя на top, это не соответствует примерно 16%. Как я могу выяснить, что использует так много памяти? Вывод htop аналогичен.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2687 user 20 0 4571444 470632 182356 S 0.3 0.7 9:03.54 gnome-shell
2917 user 20 0 1975104 398320 70580 S 0.0 0.6 13:43.18 remmina
2705 user 20 0 958204 139888 108592 S 0.0 0.2 0:02.58 mutter-x11-fram
3283 user 20 0 1118072 113120 88808 S 0.0 0.2 0:21.40 xdg-desktop-por
2924 user 20 0 1051268 109092 86856 S 0.0 0.2 0:00.62 evolution-alarm
2383 user 20 0 24.4g 99220 72736 S 0.0 0.2 5:48.55 Xorg
2780 user 20 0 1430308 88324 72836 S 0.0 0.1 0:00.22 evolution-sourc
1512 root 20 0 2293652 86172 56888 S 0.0 0.1 1:35.99 dockerd
327 root 19 -1 141412 68228 66820 S 0.0 0.1 0:17.99 systemd-journal
2836 user 20 0 455052 56988 41084 S 0.0 0.1 0:00.84 snapd-desktop-i
1113 root 20 0 67668 48068 46148 S 0.0 0.1 0:01.77 sssd_nss
1323 root 20 0 2170596 46068 32432 S 0.0 0.1 2:39.02 containerd
994 root 20 0 1765436 33856 20576 S 0.0 0.1 0:13.12 snapd
3818 user 20 0 571596 33808 26640 S 0.0 0.1 0:03.41 update-notifier
3024 user 20 0 418936 31336 18228 S 0.0 0.0 0:11.73 ibus-extension-
2865 user 20 0 667728 29764 22244 S 0.0 0.0 0:00.32 gsd-media-keys
3191 user 20 0 822840 29720 26008 S 0.0 0.0 0:00.07 evolution-addre
PS AUX, отсортированный по RSS, топ-10
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
user 2687 0.4 0.7 4571444 470740 ? Ssl Mar13 9:04 /usr/bin/gnome-shell
user 2917 0.7 0.6 1975104 398320 ? Sl Mar13 13:43 /usr/bin/remmina -i
user 2705 0.0 0.2 958204 139888 ? Sl Mar13 0:02 /usr/libexec/mutter-x11-frames
user 3283 0.0 0.1 1118072 113120 ? Ssl Mar13 0:21 /usr/libexec/xdg-desktop-portal-gnome
user 2924 0.0 0.1 1051268 109092 ? Sl Mar13 0:00 /usr/libexec/evolution-data-server/evolution-alarm-notify
user 2383 0.3 0.1 25551360 99220 tty2 Sl+ Mar13 5:48 /usr/lib/xorg/Xorg vt2 -displayfd 3 -auth /run/user/1017/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -ver
user 2780 0.0 0.1 1430308 88324 ? Ssl Mar13 0:00 /usr/libexec/evolution-source-registry
root 1512 0.0 0.1 2293652 86172 ? Ssl Mar13 1:36 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
root 327 0.0 0.1 141412 68356 ? S<s Mar13 0:18 /usr/lib/systemd/systemd-journald
user 2836 0.0 0.0 455052 56988 ? Sl Mar13 0:00 /snap/snapd-desktop-integration/253/usr/bin/snapd-desktop-integration
# ps aux | awk '{sum += $6} END {print sum}'
3155808
# df -h
Filesystem Size Used Avail Use% Mounted on
tmpfs 6.3G 2.0M 6.3G 1% /run
/dev/sda2 469G 40G 406G 9% /
tmpfs 32G 4.0K 32G 1% /dev/shm
tmpfs 5.0M 12K 5.0M 1% /run/lock
efivarfs 118K 79K 35K 70% /sys/firmware/efi/efivars
/dev/sda1 487M 6.2M 481M 2% /boot/efi
tmpfs 6.3G 2.7M 6.3G 1% /run/user/1017
Я думал, что проблема может заключаться в отсутствии swap, но добавление его ничего не изменило.
Я забыл, что добавлял HugePages несколько месяцев назад. Отключение их восстановило место в ОЗУ. Для всех в будущем, помните о /proc/meminfo
# cat /proc/meminfo
MemTotal: 65765460 kB
MemFree: 54239100 kB
MemAvailable: 55079148 kB
Buffers: 44960 kB
Cached: 1373816 kB
SwapCached: 0 kB
Active: 1825304 kB
Inactive: 707616 kB
Active(anon): 1157764 kB
Inactive(anon): 0 kB
Active(file): 667540 kB
Inactive(file): 707616 kB
Unevictable: 3160 kB
Mlocked: 88 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Zswap: 0 kB
Zswapped: 0 kB
Dirty: 436 kB
Writeback: 0 kB
AnonPages: 1117468 kB
Mapped: 582872 kB
Shmem: 43612 kB
KReclaimable: 49996 kB
Slab: 251364 kB
SReclaimable: 49996 kB
SUnreclaim: 201368 kB
KernelStack: 11296 kB
PageTables: 22548 kB
SecPageTables: 1052 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 28688424 kB
Committed_AS: 6037060 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 106508 kB
VmallocChunk: 0 kB
Percpu: 29504 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
Unaccepted: 0 kB
HugePages_Total: 8
HugePages_Free: 8
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 1048576 kB
Hugetlb: 8388608 kB
DirectMap4k: 586736 kB
DirectMap2M: 10866688 kB
DirectMap1G: 55574528 kB
Видимо, приложения gnome-shell и remmina могут использовать системную память, основываясь на выводе терминала. Если remmina не использует чрезмерно много памяти, система графики Xorg тоже может вызывать проблемы с памятью. К сожалению, за исключением remmina, эти процессы часто неизбежны в Ubuntu.
Какая польза от “неиспользуемой” оперативной памяти?
Ваша Linux-система использует оперативную память для буферов, нескольких уровней кэша, общих библиотек и т.д.
Каждая из них (кроме I/O буферов) может быть освобождена при необходимости.
Поскольку процессы выполняются в виртуальном адресном пространстве, количество свободной ОЗУ не имеет большой корреляции.
В каждом случае у вас должно быть от 1 x размера ОЗУ (минимальное требование для гибернации) до 2 x размера ОЗУ для более плавной работы системы.
Ответ или решение
К сожалению, ваш вопрос был закрыт, потому что проблема, описанная в нем, не может быть воспроизведена, а также может быть связана с очень специфичным периодом времени или уникальными для вашего случая обстоятельствами. Однако, предоставленный контекст все равно позволяет рассмотреть некоторые возможности и объяснения, касающиеся высокого использования оперативной памяти в системе Ubuntu 24.
Теория
Во-первых, важно понимать, как система Linux управляет оперативной памятью. Linux известен тем, что использует много RAM для кеширования и буферизации, что позволяет улучшить производительность за счет быстрого доступа к данным. Операционная система кэширует данные, чтобы ускорить доступ к файлам и запущенным приложениям, что зачастую может создавать иллюзию избыточного использования памяти, когда в действительности система просто оптимизирует производительность.
Далее, в современных настольных окружениях, таких как GNOME, используются значительные объёмы памяти. Это связано с обилием функций и сервисов, работающих в фоновом режиме для удобства пользователя.
Пример и разбор
Проблема, казалось, была связана с использованием HugePages. HugePages — это механизм памяти в Linux, который позволяет использовать большие страницы памяти для повышения производительности серверных приложений, таких как базы данных. Этот механизм требует предварительно зарезервировать часть оперативной памяти, что и могло стать причиной того, что внезапно было замечено использование такой большой части RAM.
Ваш вывод free -m показывает, что используется порядка 10GB оперативной памяти, в то время как доступно 53GB. В этом случае, ключевыми аспектами являются следующие строки:
-
Buffers и Cache: Эти категории памяти используются для ускорения доступа к данным. Когда возникают задачи или приложения, требующие больше оперативной памяти, ядро Linux может освободить эту память, обеспечивая достаточно ресурсов для новых или текущих задач.
-
Отсутствие Swap: Без пространства подкачки (swap), активная память должна полностью находиться в ОЗУ, что может временно увеличивать видимое использование памяти. Однако активация swap не решила вашу проблему, что наводит на мысль о том, что дело было в другом — в данном случае HugePages.
-
Механизм HugePages: Как отмечено, вы изначально использовали HugePages, что зарезервировало большую часть памяти. После отключения этого механизма вы восстановили доступную оперативную память.
Применение и рекомендации
-
Проверьте использование HugePages: Если использование HugePages нецелесообразно для вашего применения (например, если вы не запускаете большие серверные приложения, требующие оптимизации таким способом), его отключение вернет доступное количество RAM.
-
Мониторинг процессов: Использование утилит, таких как
htopилиtop, помогает отслеживать, какие процессы занимают больше всего памяти. Ваша проблема может быть системной (как GNOME или Xorg), но может быть и связана с некорректной конфигурацией объединенной рабочей среды. -
Расширение памяти или использование системы с большей RAM: Если ваше устройство должно одновременно обрабатывать множество интенсивных процессов, возможно, будет полезным добавить больше оперативной памяти или использовать обмен данными на более ресурсоемкой системе.
-
Настройка Virtual Memory Management: Изучите то, как именно ваше устройство управляет виртуальной памятью, и настройте параметры ядра, если это необходимо, для более эффективного использования RAM.
-
Планирование системы и профилирование нагрузки: Убедитесь, что вы знаете, для чего используется каждая часть установленного ПО, и оптимизируйте его использование на уровне задач и процессов.
В этой ситуации, поскольку вы обнаружили причину проблемы и смогли её решить, вы сделали важный шаг к более эффективному управлению ресурсами вашей системы. Однако, при переустановке или обновлении ПО, следите за настройками библиотек и системных служб, чтобы избежать повторения ситуации.