Consumo de memoria.

Preocupado por los bugs en los customs sobre el bucle de reinicio, o bien el del cuelgue al apagar, estaba yo mirando los temas de uso de la memoria.

El caso es que con el custom 3.4, recien inciado el sistema, de 256 MB que parece tener el LG, 30 MB están libres de media.

Buscando posible información "relacionada" en el foro, me ha llamado mucho la atención el hilo sobre el crontab del paquete busybox, donde el gran Vic muestra la salida del comando top en su LG, echad un vistazo:

https://ms450.forosactivos.net/t88-usando-los-temporizadores-crontab#417

-------------------------------
el comando top nos permite ver cuales son los comandos que mas cpu usan, memoria, etc

ejecutar top en mi lg produce:

Mem: 174928K used, 75800K free, 0K shrd, 59608K buff, 23408K cached
CPU: 0.1% usr 1.3% sys 0.0% nic 98.0% idle 0.0% io 0.0% irq 0.3% sirq
Load average: 0.00 0.00 0.00 3/64 799
PID PPID USER STAT VSZ %MEM %CPU COMMAND
14 1 root SW 0 0.0 0.7 [eth0]
...
-------------------------------

!!!Ostras!!!, si nos fijamos en la salida del comando, de 75 MB libres a los actuales 30 MB recien iniciado hay algo de diferencia ¿no?. No digo que esto tenga algo que ver con los bugs, pero no sé, quizás deberíamos investigar sobre el swap en este misp o algo.

JBL escribió:Preocupado por los bugs en los customs sobre el bucle de reinicio, o bien el del cuelgue al apagar, estaba yo mirando los temas de uso de la memoria. El caso es que con el custom 3.4, recien inciado el sistema, de 256 MB que parece tener el LG, 30 MB están libres de media. [...]el comando top nos permite ver cuales son los comandos que mas cpu usan, memoria, etc [...]

Mem: 174928K used, 75800K free, 0K shrd, 59608K buff, 23408K cached
[...]
!!!Ostras!!!, si nos fijamos en la salida del comando, de 75 MB libres a los actuales 30 MB recien iniciado hay algo de diferencia ¿no?. No digo que esto tenga algo que ver con los bugs, pero no sé, quizás deberíamos investigar sobre el swap en este misp o algo.

Hola JBL,
Tanto la memoria libre que aparece en el mensaje que comentas, como la que dices que te queda en tu reciente mensaje (60Mbytes) ¡es muy poca!. Es probable que esto llegue a causar problemas ante un pico de demanda de la aplicación principal (DvdPlayer). Como comento aquí, llevo unos días de buen funcionamiento con la versión de firmware de prueba con el último firmware oficial y solo PipeManagemet. Con este firmware, free (o top) me reporta (tras iniciar):

	total	used	free	shared	buffers
Mem	250728	117316	133412	0	12648
Swap:	160672	0	160672

Con el uso de los menús de DvdPlayer la memoria free va disminuyendo, pero nunca lo he visto bajar de los 100KBytes. Quizás aún más importante es vigilar que la swap used nunca llegue a subir (significativamente) de 0.

Resumiendo: te recomiendo que te instales el firmware de prueba que está explicado en este mensaje.
y nos vayas diciendo cómo te vá en este sondeo.

Saludos,

Gracias por el consejo evr, ya lo tenía presente pero quiero investigar un poco más, más que nada por echar un cable a los custommen...

Me sorprende mucho lo que comentas, ¿133 MB libres recien inciado?, no lo entiendo, ¿cual es la diferencia entre quitar del init.d los procesos y el beta propuesto?. Esta claro que hay algo más que no esta activo, digo, en referencia a https://ms450.forosactivos.net/t598p20-custom-kv-probable-causante-de-los-cuelgues#5436

JBL escribió:[...]Me sorprende mucho lo que comentas, ¿133 MB libres recien inciado?, no lo entiendo, ¿cual es la diferencia entre quitar del init.d los procesos y el beta propuesto?. Esta claro que hay algo más que no esta activo[...]

No conozco los detalles exactos de lo que hay en el Custom-KV. Para entenderlo bien y poder ayudar a mejorar y a depurar problemas, sería necesario tener todo el árbol de fuentes y utilidades que se usan para producirlo ... pero no parece que Keltek esté muy dispuesto a compartirlo amigablemente (ver este hilo).

Aún así hay varias cosas claras: si lo tienes activado, lighttpd (el servidor web) consume mucho. Además, su uso seguramente necesita servicios de sqlite que cualquiera sabe hasta cuánta memoria pueden llegar a necesitar. Por otra parte, la versión de busybox del Custom-KV también es bastante más grande y consumidora que la que viene con el firmware original -- y busybox está siempre en marcha ya que PipeManagement lo usa (idirectamente, mediante el famoso "tail -f ...") para enviar comandos a DvdPlayer (esto se puede evitar como explico en este hilo, pero eso será en el futuro).

En fín, justo porque no sabemos muy bien qué es lo que hace Custom-KV para que la memoria disminuya tanto, propuse a Vic que preparara el firmware con PipeManagement y la última versión oficial de firmware LG, que es la que yo estoy usando ahora y estoy proponiendo que usemos todos (al menos los afectados por cuelgues varios) a ver si así podemos encontrar las causas de las inestabilidades que tanto nos fastidian.

Saludos,

Bueno pues en relación al swap, con 160 MB, y por el momento todo libre pues que como que da margen al sistema, supongo.

root@Venus:~# cat /proc/version
Linux version 2.6.12.6-VENUS (root@robot) (gcc version 3.4.4 mipssde-6.03.01-20051114) #39 Wed Nov 18 16:45:11 CST 2009

root@Venus:~# cat /proc/cpuinfo
system type : Realtek Venus
processor : 0
cpu model : MIPS 24K V7.8
BogoMIPS : 269.51
wait instruction : yes
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes
ASEs implemented : mips16
VCED exceptions : not available
VCEI exceptions : not available

root@Venus:~# cat /proc/meminfo
MemTotal: 250728 kB
MemFree: 43892 kB
Buffers: 75520 kB
Cached: 25600 kB
SwapCached: 0 kB
Active: 59892 kB
Inactive: 47492 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 250728 kB
LowFree: 43892 kB
SwapTotal: 160672 kB
SwapFree: 160672 kB
Dirty: 4 kB
Writeback: 0 kB
Mapped: 13336 kB
Slab: 7628 kB
CommitLimit: 286036 kB
Committed_AS: 10768 kB
PageTables: 496 kB
VmallocTotal: 1048548 kB
VmallocUsed: 2096 kB
VmallocChunk: 1046136 kB

Sigo observando...

El otro día hago una copia de un archivo entre los dos HDD's pero previamente compruebo la memoria:

root@Venus:~# free
total used free shared buffers
Mem: 250728 108564 142164 0 864
-/+ buffers: 107700 143028
Swap: 160672 4 160668

copio un archivo de 4,5 GB entre los dos.

root@Venus:~# ls -l /tmp/hdd/volumes/HDD1/REC/HEAVY*
-rwxrwxrwx 1 root root 4365979648 Jan 9 11:16 /tmp/hdd/volumes/HDD1/REC/HEAVY METAL MATE_20110109_0928.ts

root@Venus:~# free
total used free shared buffers
Mem: 250728 247088 3640 0 268
-/+ buffers: 246820 3908
Swap: 160672 4 160668

En resumen de 140 MB libres, tras la copia quedan apenas 34 KB, ¿pero que pasa aquí?.
Si todo va así, raro es no sufrir más cuelgues... Supongo que despues la va liberando pero es una barbaridad, ¿que hace?, ¿cachear bloques como loco?

En fin, curioso, no copieis mucho...

Por cierto, 10 días cumplidos sin cuelgues: https://ms450.forosactivos.net/t598p20-custom-kv-probable-causante-de-los-cuelgues#5436

Seguiremos informando.

JBL escribió:El otro día hago una copia de un archivo entre los dos HDD's pero previamente compruebo la memoria: [...] copio un archivo de 4,5 GB entre los dos.
[...]
Mem: 250728 247088 3640 0 268
[...]
En resumen de 140 MB libres, tras la copia quedan apenas 34 KB, ¿pero que pasa aquí?.

¿Querrás decir 36Mbytes (3640 KBytes), no?

Si todo va así, raro es no sufrir más cuelgues... Supongo que despues la va liberando pero es una barbaridad, ¿que hace?, ¿cachear bloques como loco? [...]

El problema es del comando "cp" que es en realidad "busybox". Seguramente pide vorazmente toda la memoria posible para tratar de conseguir la máxima rapidez de la copia (lo que no parece buena idea con sistemas embedded como el LG).

Al ver tu mensaje he hecho una prueba similar: copiar un .ts de 2Gbytes de REC a otro directorio de HDD1. Ha ocurrido lo mismo que en tu caso; bueno, ¡mucho peor!: ha llegado por debajo de 30Mbytes free, luego ha subido un poco y al momento el LG se ha colgado totalmente (lo he resucitado con reset). Esto lo he hecho con el busybox del firmware oficial (que es una versión mucho más antigua que el de Harmony Pack). Esto concuerda con otra prueba que hice el otro día para ver la posibilidad de quitar totalmente el swap (ver aquí). Luego he probado a hacer la copia desde el menú del LG. En este caso todo ha ido bien, con valores de memoria libre que nunca han bajado de 125Mbytes (con unos 15Mbytes de buffers).

Al parecer, el código de copia implementado en DvdPlayer está mejor pensado que el de busybox para la escasa memoria del LG. Un día de estos haré un pequeño programa con un buffer de tamaño fijo que solo sirva para copiar a ver cómo se comporta...

Saludos,

evr escribió:
Al parecer, el código de copia implementado en DvdPlayer está mejor pensado que el de busybox para la escasa memoria del LG. Un día de estos haré un pequeño programa con un buffer de tamaño fijo que solo sirva para copiar a ver cómo se comporta...

Saludos,

Je, je, buena prueba, eso sí, la copia desde el aparato ya sabemos lo que pasa, que tiene sorpresas. Yo para evitarlas copio unicamente con cp, pero claro, si se puede quedar tieso en un momento dado, me parece que solo queda la de coger el disco y al PC.

JBL escribió:Je, je, buena prueba, eso sí, la copia desde el aparato ya sabemos lo que pasa, que tiene sorpresas. Yo para evitarlas copio unicamente con cp, pero claro, si se puede quedar tieso en un momento dado,

Ojo, que "cp" no existe; cuando escribes cp, en realidad estás ejecutando busybox.

me parece que solo queda la de coger el disco y al PC.

Si copias con cp desde el LG al PC, por en medio interviene samba, como cliente o como servidor, según lo tengas montado. En ese caso hay al menos dos posibles culpables: busybox y samba. Desde luego si te llevas el disco al PC, "muerto el perro se acabó la rabia" , claro

Saludos,