Pregunta Uso de la memoria misteriosa en Linux


Tenemos algunas cajas de Linux de 64 bits (RHEL6) que se ejecutan en Microsoft Windows 2012 Server (Hypervisor) con el mismo problema. Esos servidores invitados de Linux se ejecutan en MS Windows Cloud (Hyper-V) con 16 servidores host con 256 GB de RAM cada uno.

Comienzan con el siguiente uso de memoria:

# free -m
             total       used       free     shared    buffers     cached
Mem:         48259        653      47606          0         19        106
-/+ buffers/cache:        527      47732
Swap:        13999          0      13999



# cat /proc/meminfo
MemTotal:       49418204 kB
MemFree:        48749868 kB
Buffers:           20080 kB
Cached:           108564 kB
SwapCached:            0 kB
Active:           149652 kB
Inactive:          98856 kB
Active(anon):     120124 kB
Inactive(anon):     1884 kB
Active(file):      29528 kB
Inactive(file):    96972 kB
Unevictable:           4 kB
Mlocked:               4 kB
SwapTotal:      14335992 kB
SwapFree:       14335992 kB
Dirty:               788 kB
Writeback:             0 kB
AnonPages:        122196 kB
Mapped:            39844 kB
Shmem:              2132 kB
Slab:              51832 kB
SReclaimable:      14696 kB
SUnreclaim:        37136 kB
KernelStack:        5656 kB
PageTables:        15840 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    39045092 kB
Committed_AS:     490856 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      131964 kB
VmallocChunk:   34359602252 kB
HardwareCorrupted:     0 kB
AnonHugePages:     28672 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        8128 kB
DirectMap2M:    50323456 kB

(Ordenado por RES)

# top
top - 11:26:52 up 1 min,  1 user,  load average: 1.71, 0.73, 0.27
Tasks: 609 total,   1 running, 608 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.1%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.1%hi,  0.0%si,  0.0%st
Mem:  49418204k total,   674472k used, 48743732k free,    20472k buffers
Swap: 14335992k total,        0k used, 14335992k free,   111720k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1859 root      20   0  103m  28m 5784 S  0.0  0.1   0:00.85 Xvnc
 2037 root      20   0  508m  25m 8876 S  0.7  0.1   0:01.18 gnome-settings-
 2064 root      20   0  373m  17m  12m S  0.0  0.0   0:01.11 nautilus
 2141 root      20   0  464m  16m  12m S  0.0  0.0   0:00.14 clock-applet
 2063 root      20   0  319m  14m  10m S  0.0  0.0   0:00.28 gnome-panel
 2082 root      20   0  307m  12m 9100 S  0.0  0.0   0:00.11 nm-applet
 2139 root      20   0  381m  12m 9748 S  0.0  0.0   0:00.08 gdm-user-switch
 2093 root      20   0  442m  11m 9104 S  0.0  0.0   0:00.13 gnome-volume-co
 2116 root      20   0  299m  11m 9476 S  0.0  0.0   0:00.10 wnck-applet
 2118 root      20   0  307m  11m 8768 S  0.0  0.0   0:00.06 trashapplet
...

Y 6 minutos después, la memoria es consumida por un proceso desconocido o por el kernel:

uptime ; free -m
 11:31:52 up 6 min,  1 user,  load average: 1.05, 0.93, 0.47
             total       used       free     shared    buffers     cached
Mem:         48259      25296      22963          0         21        160
-/+ buffers/cache:      25115      23144
Swap:        13999          0      13999

]# cat /proc/meminfo
MemTotal:       49418204 kB
MemFree:        23514240 kB
Buffers:           21600 kB
Cached:           164428 kB
SwapCached:            0 kB
Active:           210768 kB
Inactive:         108108 kB
Active(anon):     133036 kB
Inactive(anon):     2332 kB
Active(file):      77732 kB
Inactive(file):   105776 kB
Unevictable:           8 kB
Mlocked:               8 kB
SwapTotal:      14335992 kB
SwapFree:       14335992 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:        132892 kB
Mapped:            41976 kB
Shmem:              2516 kB
Slab:              52624 kB
SReclaimable:      17628 kB
SUnreclaim:        34996 kB
KernelStack:        5752 kB
PageTables:        15756 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    39045092 kB
Committed_AS:     654848 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      131964 kB
VmallocChunk:   34359602252 kB
HardwareCorrupted:     0 kB
AnonHugePages:     45056 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        8128 kB
DirectMap2M:    50323456 kB

(Ordenado por RES)

# top
top - 11:32:45 up 7 min,  1 user,  load average: 1.02, 0.94, 0.50
Tasks: 607 total,   1 running, 606 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.1%us,  0.1%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  49418204k total, 25904096k used, 23514108k free,    21600k buffers
Swap: 14335992k total,        0k used, 14335992k free,   164428k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1859 root      20   0  103m  28m 6176 S  0.0  0.1   0:00.87 Xvnc
 2037 root      20   0  508m  25m 8916 S  0.0  0.1   0:01.19 gnome-settings-
 2064 root      20   0  373m  17m  12m S  0.0  0.0   0:01.61 nautilus
 2141 root      20   0  464m  16m  12m S  0.0  0.0   0:00.15 clock-applet
 2063 root      20   0  319m  14m  10m S  0.0  0.0   0:00.29 gnome-panel
 1788 root      20   0  779m  13m 5808 S  0.0  0.0   0:00.18 scxcimserver
 2082 root      20   0  307m  12m 9100 S  0.0  0.0   0:00.11 nm-applet
 2139 root      20   0  381m  12m 9748 S  0.0  0.0   0:00.08 gdm-user-switch
 2093 root      20   0  442m  11m 9104 S  0.0  0.0   0:00.13 gnome-volume-co
 2116 root      20   0  299m  11m 9476 S  0.0  0.0   0:00.10 wnck-applet
...

La suma de memoria RSS reportada por ps en MB es aproximadamente 388:

# ps aux | awk '{sum+=$6} END {print sum / 1024}'
387.898

¿Qué más puedo comprobar para saber qué consume la memoria?


5
2018-01-30 16:46


origen


¿Su hipervisor está sobrealimentado? - Nathan C
Ahora que lo veo mejor, 49418204 tiene ~ 48 GB de memoria ... ¿está asignando la memoria RAM de todo su host a este invitado o algo así? - Nathan C
No, esos invitados se ejecutan en una granja de MS Windows (Cloud) con 16 servidores como Host. Cada uno de esos servidores tiene 256 GB de RAM. - jorgernan


Respuestas:


Parece que Hyper-V está robando la memoria porque su host está aprovisionado en exceso, un proceso llamado globo de memoria (o memoria dinámica en el mundo Hyper-V).


11
2018-01-30 19:15



Este es el escenario más probable. La memoria dinámica provocará el comportamiento exacto descrito en un host con exceso de dispositivos o en un huésped subutilizado. El módulo del kernel que lo habilita en Linux es hv_balloon y puedes comprobarlo con lsmod | grep hv_ - MDMarra
Sí, usa esos módulos del kernel: # lsmod | grep hv_ hv_balloon 12019 0 [permanent] hv_netvsc 23702 0 hv_utils 9149 0 hv_storvsc 11323 2 hv_vmbus 144850 6 hv_balloon,hid_hyperv,hv_netvsc,hv_utils,hyperv_fb,hv_storvsc - jorgernan
¿Es ese el comportamiento esperado? ¿El consumo de memoria en el nivel de invitado o la máquina virtual invitada debe verse afectado por un MemTotal reducido? - jorgernan
@jorgernan Ballooning trabaja "robando" la memoria RAM del invitado para el anfitrión. El kernel informa sobre la memoria utilizada, aunque en realidad no está "utilizada" por un proceso. Probablemente esto se deba a que su invitado está subutilizado, por lo que asigna la RAM a otro lugar. - Nathan C
@jorgernan, si no quiere que eso ocurra, deshabilite la memoria dinámica o aumente el valor mínimo. Dicho esto, si su invitado necesita la memoria y el host tiene recursos disponibles, su invitado podrá usar la memoria RAM. Todo lo que significa en este punto es que has aprovisionado drásticamente a tu invitado. - MDMarra