¿Qué es la "memory dinámica del núcleo" según lo informado por smem?

Mientras diagnosticaba problemas de poca memory en mi máquina de escritorio (detalles en U & L ) noté que mi "memory dinámica de kernel" no enmascarada es grande :

# smem -twk Area Used Cache Noncache firmware/hardware 0 0 0 kernel image 0 0 0 kernel dynamic memory 1.1G 369.3M 801.7M userspace memory 2.0G 133.3M 1.9G free memory 734.1M 734.1M 0 ---------------------------------------------------------- 3.9G 1.2G 2.7G 

En otros dos sistemas, comprobé que era 150MiB (también una computadora de escritorio, pero con 8GiB o RAM) y 29MiB. En ninguna parte cerca del 20% de mi máquina de escritorio.

¿Cómo puedo averiguar qué lo hace tan grande?

Por cierto: ya revisé smem fonts de smem , básicamente lo hace (memtotal – espacio de usuario – libre – caching).

/proc/meminfo :

 # cat / proc / meminfo 
 MemTotal: 4051956 kB
 MemFree: 508276 kB
 Buffers: 35232 kB
 En caching: 651052 kB
 SwapCached: 121380 kB
 Activo: 1358008 kB
 Inactivo: 1351596 kB
 Activo (anon): 1184616 kB
 Inactivo (anon): 886904 kB
 Activo (file): 173392 kB
 Inactivo (file): 464692 kB
 Unevictable: 8616 kB
 Mlocked: 8616 kB
 SwapTotal: 4051952 kB
 SwapFree: 3815780 kB
 Sucio: 348 kB
 Reescritura: 0 kB
 AnonPages: 1971164 kB
 Mapeado: 140108 kB
 Shmem: 44656 kB
 Losa: 176564 kB
 SReclamable: 62080 kB
 SUnkey: 114484 kB
 KernelStack: 3352 kB
 Tablas de páginas: 43012 kB
 NFS_Unstable: 0 kB
 Bounce: 0 kB
 WritebackTmp: 0 kB
 CommitLimit: 6077928 kB
 Committed_AS: 3681164 kB
 VmallocTotal: 34359738367 kB
 VmallocUsed: 139780 kB
 VmallocChunk: 34359570976 kB
 Hardware Corrupto: 0 kB
 AnonHugePages: 448512 kB
 HugePages_Total: 0
 HugePages_Free: 0
 HugePages_Rsvd: 0
 HugePages_Surp: 0
 Hugepagesize: 2048 kB
 DirectMap4k: 2536128 kB
 DirectMap2M: 1656832 kB

Al ver otra publicación, supongo que estás usando zram. Entonces esa será mi suposition aquí.

Hice la experiencia para instalar zram y consumir mucha memory, y obtuve el mismo resultado de smem que tú. smem no tiene en count zram en su recuento , solo usa /proc/meminfo para calcular su valor, y si miras y tratas de entender el código verás que la ocupación zram RAM se obtiene al final contada bajo el noncache columna de la línea de memory dinámica del kernel .

Investigaciones más profundas

Siguiendo mi intuición de que zram estaba detrás de este comportamiento, configuré una máquina virtual con especificaciones similares a su máquina: 4 GB de RAM y 2 GB de intercambio zram, sin file de intercambio.

He cargado la máquina virtual con aplicaciones de gran peso y obtuve el siguiente estado:

 huygens@ubuntu:~$ smem -wt -K ~/vmlinuz-3.2.0-38-generic.unpacked -R 4096M Area Used Cache Noncache firmware/hardware 130717 0 130717 kernel image 13951 0 13951 kernel dynamic memory 1063520 922172 141348 userspace memory 2534684 257136 2277548 free memory 451432 451432 0 ---------------------------------------------------------- 4194304 1630740 2563564 huygens@ubuntu:~$ free -m total used free shanetworking buffers cached Mem: 3954 3528 426 0 79 858 -/+ buffers/cache: 2589 1365 Swap: 1977 0 1977 

Como puede ver, hay informes free 858 MB de memory caching y eso también es lo que smem parece informar dentro de la memory dinámica del kernel en caching.

Luego hice hincapié en que el sistema utiliza el browser Chromium. Al principio, solo se utilizaron 83 MB de swap. Pero luego de abrir algunas tabs más, el interruptor cambia rápidamente a casi su máximo y ¡experimenté OOM! zram tiene un lado realmente peligroso donde está mal configurado (tamaños demasiado grandes) que puede golpearlo rápidamente como un mecanismo parecido a un trebuchet.

En ese momento tenía los siguientes resultados:

 huygens@ubuntu:~$ smem -wt -K ~/vmlinuz-3.2.0-38-generic.unpacked -R 4096M Area Used Cache Noncache firmware/hardware 130717 0 130717 kernel image 13951 0 13951 kernel dynamic memory 1355344 124072 1231272 userspace memory 961004 36456 924548 free memory 1733288 1733288 0 ---------------------------------------------------------- 4194304 1893816 2300488 huygens@ubuntu:~$ free -m total used free shanetworking buffers cached Mem: 3954 2256 1698 0 4 132 -/+ buffers/cache: 2118 1835 Swap: 1977 1750 227 

Vea cómo la memory dinámica del núcleo (caching de columnas y no caching) parece invertida. Es porque en el primer caso, el kernel tenía memory "en caching" tal como se informó de forma free pero luego tenía memory swap mantenida por zram que smem no sabe cómo calcular (verifica el código fuente de smem, la ocupación zram no se informa en / proc / meminfo, esto no lo calcula smem que hace simple "mem total del kernel" – "tipo de memory reportada por meminfo que sé que es caching", lo que no sabe es que en el total de kernel calculado se ha agregado el tamaño del intercambio que está en la RAM!)

Cuando estaba en este estado, activé un intercambio de disco duro y apagué el intercambio zram y reinicié los dispositivos zram: echo 1 > /sys/block/zram0/reset .

Después de eso, la memory del núcleo no enmascarada se derritió como la nieve en verano y volvió al valor "normal".

Conclusión

smem no sabe acerca de zram (todavía) tal vez porque aún está en etapas y por lo tanto no forma parte de /proc/meminfo que informa los parameters globales (como (en) el tamaño de páginas activas, memory total) y luego solo informa sobre algunos parameters específicos. smem identificó algunos de estos parameters específicos como "caching", los resume y compara eso con la memory total. Debido a que la memory utilizada zram se count en la columna sin memory caching .

Nota: por cierto, en el kernel moderno, meminfo informa también la memory compartida consumida. smem no toma eso en count, así que incluso sin zram la salida de smem es considerar cuidadosamente esp. si usa una aplicación que hace un gran uso de la memory compartida.

Referencias utilizadas:

  • código fuente de smem
  • documentation oficial zram
  • / proc / meminfo explicado (aunque necesitaría una actualización)
  • código fuente de la salida meminfo

No me parece malo, hay muchos recuerdos fáciles de recuperar. Exactamente lo que no funciona (no solo "¡Oh, horror, mira los numbers <progtwig aleatorio> da!")? Los progtwigs se bloquean (OOM, sin memory, ¿gestor pateando?). Los progtwigs no comienzan? El sistema se siente lento Actividad de disco incesante?). ¿Alguna pista en los loggings?

(Linux llenará toda la memory disponible, es más barato simplemente save cosas que borrarlas activamente, y podría usarse de nuevo más tarde. Una máquina inactiva (o justo después del arranque) dará numbers muy diferentes a los que se usan activamente. .)