LINUX.ORG.RU
решено Форум — Admin  

Linux kernel 5.14.0+ memory used ~80%

 , , , ,


1

4

UPD №2: Локализировал диапазон Ядер, проблема начинается с ядра 5.14.0 (5.14.0-051400-generic), если учитывать версии релиз кандидатов то с 5.14.0-051400rc2-generic. В версии ядра 5.13.19 (5.13.19-051319-generic) проблема Не наблюдается. Ис пользовал как основу дистрибутив Ubuntu 20.04.6 на ядре 5.4.0. Для тестов использовал версии Ядер выложенные на https://kernel.ubuntu.com/mainline/

UPD №1: Обнаружилось что с ядром 5.15 (Ubuntu 22.04.1), проблема также наблюдается. Текст править не буду картина в целом сохраняется. Количество версий проблемных дистрибутивов, значительно расширяется.

На свеже установленных («пустых») дистрибутивах семейства Debian (пробовал Proxmox VE 8.3, Ubuntu 24.04, Debian 12, Astra Linux SE 1.8) с ядром 6.1 и выше - free , top, веб морда Proxmox и т.д. показывает used примерно 80% на постоянной основе. На дистрибутивах с 5м ядром (Ubuntu 20.04, Debian 11, Astra Linux SE 1.7) такой ерунды не наблюдается.

Может кто сталкивался, как победить?

Гуглинг пока что ни к чему схожему не привел, в основном все ссылаются на то что так устроена работа ядра с памятью и когда память понадобится, ядро ее отдаст, но судя по столбцам buff/cache/available вывода top - освобождаться там особо нечему - *Сужу со своей колокольни на основе вывода free и top, но это не точно - в виду невысокого опыта.

Ядро 6.1 (Debian 12) - проблемный:

~$ echo = = = Free = = =; free -m ; echo; echo = = = TOP = = =; top -bn1 -o%MEM | head
= = = Free = = =
               total        used        free      shared  buff/cache   available
Mem:            7577        5931        1446           1         452        1646
Swap:            975           0         975

= = = TOP = = =
top - 12:28:19 up  1:05,  1 user,  load average: 0,02, 0,05, 0,03
Tasks: 262 total,   1 running, 261 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,0 us,  2,2 sy,  0,0 ni, 94,6 id,  3,3 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   7577,3 total,   1443,6 free,   5933,8 used,    453,1 buff/cache
MiB Swap:    976,0 total,    976,0 free,      0,0 used.   1643,5 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    444 root      20   0  143592  84388  81228 S   5,9   1,1   0:14.57 systemd+
      1 root      20   0  167776  12172   9120 S   0,0   0,2   0:02.46 systemd
  20391 root      20   0   17732  10860   9260 S   0,0   0,1   0:00.07 sshd

Ядро 5.10 (Debian 11) - проблема НЕ наблюдается:

~$ echo = = = Free = = =; free -m ; echo; echo = = = TOP = = =; top -bn1 -o%MEM | head
= = = Free = = =
               total        used        free      shared  buff/cache   available
Mem:            7593         336        7124           1         132        7052
Swap:            975           0         975

= = = TOP = = =
top - 15:13:01 up 43 min,  1 user,  load average: 0,01, 0,01, 0,00
Tasks: 251 total,   1 running, 250 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,3 us,  0,3 sy,  0,0 ni, 99,4 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   7593,6 total,   7124,8 free,    336,1 used,    132,6 buff/cache
MiB Swap:    976,0 total,    976,0 free,      0,0 used.   7052,9 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    434 root      20   0   72800  32780  31876 S   0,0   0,4   0:00.30 systemd-journal
      1 root      20   0  163708  10092   7744 S   0,0   0,1   0:01.61 systemd
  10525 root      20   0   14452   8656   7428 S   0,0   0,1   0:00.07 sshd

В /proc/meminfo ничего не увидел криминального (возможно не туда смотрел в виду опыта) кроме как того что у проблемной версии ядер почему то низкий MemFree который задействуется в расчете used команд top и free

Ядро 6.1 (Debian 12) - проблемный:

~$ cat /proc/meminfo
MemTotal:        7759188 kB
MemFree:         1483112 kB
MemAvailable:    1683256 kB
Buffers:          151028 kB
Cached:           242592 kB
SwapCached:            0 kB
Active:           256324 kB
Inactive:         168196 kB
Active(anon):        624 kB
Inactive(anon):    31752 kB
Active(file):     255700 kB
Inactive(file):   136444 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:        999420 kB
SwapFree:         999420 kB
Zswap:                 0 kB
Zswapped:              0 kB
Dirty:              2988 kB
Writeback:             0 kB
AnonPages:         30936 kB
Mapped:            65216 kB
Shmem:              1452 kB
KReclaimable:      65548 kB
Slab:             434408 kB
SReclaimable:      65548 kB
SUnreclaim:       368860 kB
KernelStack:        4536 kB
PageTables:         1472 kB
SecPageTables:         0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     4879012 kB
Committed_AS:     139948 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       36264 kB
VmallocChunk:          0 kB
Percpu:            32352 kB
HardwareCorrupted:     0 kB
AnonHugePages:      4096 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      220572 kB
DirectMap2M:     5699584 kB
DirectMap1G:     4194304 kB

Ткните куда копать, что не так.

Не знаю важно ли Железо, но есть с ним один нюанс:

  1. Процессор: Intel Xeon Silver 4210R 2,4GHz
  2. Память: Kingston DDR4 3200 MGz ECC REG 8Gb
  3. Материнская плата (собственно сам нюансик): Гравитон ЕЦРТ.469555.001 SMB-C621-ATX01 Тайга - Чипсет у нее Intel C621


Последнее исправление: alexla (всего исправлений: 10)
← fail2ban не блокирует при неудачных попытках sshd
Bond или есть более удачные решения? →
  1 2 →

Проверил все это дела в актуальном дистрибутиве (24.04.1) на актуальном ядре (6.8.0-51-generic), в общем ситуация аналогична ядру 5.14.0 . Фиксится также, выгрузкой группы модулей: irdma , ice , ib_uverbs , ib_core . Для отключения этой группы модулей достаточно добавить (в моем случае) blacklist irdma в /etc/modprobe.d/blacklist.conf . Какой конкретно виноват из этой группы модулей, видимо останется загадкой. Ну да и черт с ним, сервер пару дней работает, все вроде нормально, проблем не наблюдаю.

~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo
~$
~$
~$ hostnamectl
 Static hostname: server-1
       Icon name: computer-desktop
         Chassis: desktop 🖥️
      Machine ID: 58e1b330ff6b47f2a15d761974f360e7
         Boot ID: e0a6971d105f4428930ad385ae7e6c42
Operating System: Ubuntu 24.04.1 LTS
          Kernel: Linux 6.8.0-51-generic
    Architecture: x86-64
 Hardware Vendor: 3Logic Group
  Hardware Model: Server Graviton
Firmware Version: L2.19I
   Firmware Date: Thu 2024-06-13
    Firmware Age: 6month 4w
~$
~$
~$ echo = = = Free = = =; free -m ; echo; echo = = = TOP = = =; top -bn1 -o%MEM | head
= = = Free = = =
               total        used        free      shared  buff/cache   available
Mem:            7577         654        6903           1         263        6923
Swap:           4095           0        4095

= = = TOP = = =
top - 08:40:10 up 5 min,  2 users,  load average: 0,11, 0,17, 0,09
Tasks: 300 total,   1 running, 299 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0,3 us,  0,8 sy,  0,0 ni, 97,2 id,  1,7 wa,  0,0 hi,  0,0 si,  0,0 st
MiB Mem :   7577,4 total,   6902,2 free,    655,1 used,    264,0 buff/cache
MiB Swap:   4096,0 total,   4096,0 free,      0,0 used.   6922,2 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    587 root      rt   0  289112  26720   8480 S   0,0   0,3   0:00.08 multipa+
   1096 root      20   0  109672  22880  13600 S   0,0   0,3   0:00.20 unatten+
    539 root      19  -1   66860  16760  15960 S   0,0   0,2   0:00.36 systemd+
alexla
() автор топика
Ответ на: комментарий от alexla

Посмотреть, сколько памяти забрал модуль, оказалось сложнее, чем я думал. Пока не нашёл

Но. В процессе изучения кода модулей и dmesg из дампа у меня сложилось впечатление, что в этом 8 Гб сервере каким-то образом оказалась очень хорошая сетевая карта. И возможно, что она действительно поддерживает RDMA

kern    info    1.503899        Task(179)       i40e 0000:1a:00.3: Features: PF-id[3] VFs: 32 VSIs: 34 QP: 20 RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA
[...]
kern    info    1.796096        Task(241)       i40e 0000:1a:00.3 enp26s0f3np3: renamed from eth3

Т.е. это не баг, а наоборот в ядро 5.14 intel добавил полноценную поддержку тех возможностей карты, про которые я раньше не слышал и которые на этом сервере скорее всего никогда и не пригодятся просто в силу микроскопического размера памяти. Во взрослом сервере эта карта как минимум сильно повысила бы производительность сети для гипервизора с большим числом виртуалок

Пока можно из любопытства посмотреть выводы утилит

rdma system 
rdma dev
rdma resource

ibv_devices

Но опять же, скорее всего это не пригодится. Предполагаю, что модуль ядра выделил для карты вполне адекватные ресурсы. Просто в сервере с 8 Гб новая сетевая карта с кучей фич оказалась случайно :)

router ★★★★★
()
Ответ на: комментарий от router

https://downloadmirror.intel.com/738730/README_irdma.txt

-------------------
Memory Requirements
-------------------
Default irdma initialization requires a minimum of ~210 MB (for E810) or
~160 MB (for X722) of memory per port.

For servers where the amount of memory is constrained, you can decrease the
required memory by lowering the resources available to E810 or X722 by loading
the driver with the following resource profile setting:

    modprobe irdma rsrc_profile=2
router ★★★★★
()
Ответ на: комментарий от router

Включил предварительно обратно модуль irdma для тестов.

~$ rdma system
netns shared copy-on-fork on
~$
~$ rdma dev
0: irdma0: node_type rnic fw 0.2 node_guid f2d7:afff:fe90:2e00 sys_image_guid f2d7:afff:fe90:2e00
1: irdma1: node_type rnic fw 0.2 node_guid f2d7:afff:fe90:2e01 sys_image_guid f2d7:afff:fe90:2e01
2: irdma2: node_type rnic fw 0.2 node_guid f2d7:afff:fe90:2e02 sys_image_guid f2d7:afff:fe90:2e02
3: irdma3: node_type rnic fw 0.2 node_guid f2d7:afff:fe90:2e03 sys_image_guid f2d7:afff:fe90:2e03
~$
~$ rdma resource
0: irdma0: pd 0 cq 0 qp 0 cm_id 0 mr 0 ctx 0 srq 0
1: irdma1: pd 0 cq 0 qp 0 cm_id 0 mr 0 ctx 0 srq 0
2: irdma2: pd 0 cq 0 qp 0 cm_id 0 mr 0 ctx 0 srq 0
3: irdma3: pd 0 cq 0 qp 0 cm_id 0 mr 0 ctx 0 srq 0
~$
~$ ibv_devices
    device                 node GUID
    ------              ----------------
    irdma0              f2d7affffe902e00
    irdma1              f2d7affffe902e01
    irdma2              f2d7affffe902e02
    irdma3              f2d7affffe902e03

Вот, есть руководство пользователя для материнки, вдруг будет интересно. В ней есть схематическое обозначение элементов материнской платы и краткая блок схема взаимодействия основных блоков. Про RDMA ничего не нашел в ней, но это возможно из за того что прокрутил и просмотрел содержимое бегло. https://disk.yandex.ru/i/mmIo_5gp5IwPBA

alexla
() автор топика
Ответ на: комментарий от router

Что касаемо случайности касаемо «карта с кучей фич». Скорее всего из подходящего под ТЗ у «интегратора» попросту не оказалось на складах или у поставщиков, поэтому слепили из того что было. А если учесть все «нововведения» в вопросе импортозамещения и требования определенной доли «отечественности» в «конечном продукте» при ГК - возможно и вообще не было других вариантов, в виду отсутствия их на отечественном рынке. Ну или закупщик ошибся цифрой для объема оперативной памяти при составлении ТЗ - или попросту не знает что в современных реалиях на серверах крутится виртуальные машины под гипервизором где объем оперативной памяти имеет очень не мало важное значение.

alexla
() автор топика
  1 2 →
← fail2ban не блокирует при неудачных попытках sshd
Admin
Bond или есть более удачные решения? →