Re: "oom-killer" (out of memory)
El día 30 de enero de 2010 18:32, Camaleón escribió: > El Fri, 29 Jan 2010 09:46:41 +, Camaleón escribió: > >> A última hora haré más pruebas con gedit, pero parece un patrón >> reproducible (archivo enorme -> gedit -> consumo elevado de ram -> >> bloqueo). Si alguien me puede confirmar este comportamiento (ojo que el >> equipo se queda ko), mejor que mejor :-) > > Tras hacer varias pruebas con varios tipos de archivos y buscando > información, he visto que se trata de un bug que aún no está cerrado: > > *** > gedit performs very slowly, hogs a ton of memory, and crashes on large > datasets without newlines > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360535 > > Bug 134682 - gedit needs to implement a workaround to deal with > GtkTextView/Buffer inability to handle long lines > https://bugzilla.gnome.org/show_bug.cgi?id=134682 > *** > En el intertanto, podrías probar con leafpad o abiword. Suerte. -- usuario linux #274354 normas de la lista: http://wiki.debian.org/NormasLista -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "oom-killer" (out of memory)
El Fri, 29 Jan 2010 09:46:41 +, Camaleón escribió: > A última hora haré más pruebas con gedit, pero parece un patrón > reproducible (archivo enorme -> gedit -> consumo elevado de ram -> > bloqueo). Si alguien me puede confirmar este comportamiento (ojo que el > equipo se queda ko), mejor que mejor :-) Tras hacer varias pruebas con varios tipos de archivos y buscando información, he visto que se trata de un bug que aún no está cerrado: *** gedit performs very slowly, hogs a ton of memory, and crashes on large datasets without newlines http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360535 Bug 134682 - gedit needs to implement a workaround to deal with GtkTextView/Buffer inability to handle long lines https://bugzilla.gnome.org/show_bug.cgi?id=134682 *** Saludos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "oom-killer" (out of memory)
El Fri, 29 Jan 2010 01:01:32 +0100, Marc escribió: (Javier, Marc, gracias por responder. Os contesto a los dos) > En/na Javier Barroso ha escrit: >> 2010/1/28 Camaleón: >> >>> Hola, >>> >>> Esta tarde se me ha quedado "frito" el equipo (lenny 64 bits), pero se >>> ha quedado bloqueado por ¿falta de memoria?. (...) >> Sin duda está paginando, debes tener algún proceso que se chupara toda >> la memoria. >> >> Yo probaría a instalar el atop y usar el atopsar para ver qué programas >> te cogían dicha memoria (realmente sé que te dice los programas que >> pilla la cpu, pero no estoy seguro que lo puedas ordenar por memoria, >> igual te da pistas) >> >> Cuando se te quede pillado, al arrancar ejecuta atopsar y a ver si te >> da pistas. Ayer estuve haciendo más pruebas. Cargué de nuevo el archivo xml en gedit y dejé en top corriendo, para ver el consumo de memoria y vaya, la memoria "utilizada" empezaba a subir de manera disparatada hasta >4 GiB (y subiendo) cuando detuve el proceso para evitar que el equipo se quedara colgado de nuevo (a ver si a última hora puedo hacer más pruebas). >> El free te reporta los 8 gigas ? Sip: s...@stt008:~$ free total used free sharedbuffers cached Mem: 820126411838007017464 0 51892 544164 -/+ buffers/cache: 5877447613520 Swap: 2104472 02104472 >> Con el top puedes ordenar por memoria con la 'M' y puedes ejecutar "ps >> vx krss" para ordenar (y ver más detalles del uso de memoria) la salida >> por uso de memoria con el ps. Al ver que el gedit se hacía con toda la ram, probé a cargar el mismo archivo xml con mcedit y con el top al lado para ver qué pasaba. El archivo se cargó (un poco lento, pero se cargó) y el consumo de memoria apenas subió unos megas. Pensando que el culpable podía ser el gedit, lo probé con OOo Writer y perfecto, lo abre como un tiro. Empieza a cargar las páginas, el uso de ram sube unos 300 MiB (estabilizado) pero me puedo desplazar por el documento sin problemas, va suave. >> En tus logs aparece liferea, pero no sé si es él el que genera el >> follón o que simplemente el ookiller decide "matarlo". Si, yo también creo que fue eso lo que pasó. De hecho, cuando estaba medio colgado el equipo, vi como desaparecía el icono del liferea de la bandeja del sistema. >> Parece que hace tiempo hubo un bug en liferea que era un memory leak, >> puede que venga por ahí el poblema: >> http://sourceforge.net/tracker/? func=detail&atid=581684&aid=1498277&group_id=87005 > si con las pruebas que te han comentado descubres que el problema es > realmente con el archivo "gordo", te recomiendo lo abras con scite > (aptitude install scite). Es el único editor de textos en gui que > siempre me ha abierto cualquier archivo de cualquier tamaño. Sí, gracias por el consejo. De hecho ese parece que es el problema: la aplicación (gedit) se desboca y empieza a consumir ram sin control. A última hora haré más pruebas con gedit, pero parece un patrón reproducible (archivo enorme -> gedit -> consumo elevado de ram -> bloqueo). Si alguien me puede confirmar este comportamiento (ojo que el equipo se queda ko), mejor que mejor :-) Saludos y gracias a los dos, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "oom-killer" (out of memory)
En/na Javier Barroso ha escrit: Hola, 2010/1/28 Camaleón : Hola, Esta tarde se me ha quedado "frito" el equipo (lenny 64 bits), pero se ha quedado bloqueado por ¿falta de memoria?. Tenía abiertas unas pocas aplicaciones (icedove, writer y iceweasel) y me he descargado de la web un archivo xml de unos 100 MiB. Lo abro con Epiphany y el programa se queda "atontao" (no lo carga) así que lo cierro y abro el xml con gedit. Como veo que le cuesta abrirlo (es un archivo "gordo", pero tampoco es para tanto :-P) ejecuto "top" para ver qué hace y al poco rato el equipo se medio-congela. - Puedo mover el ratón pero responde muy lentamente - Puedo acceder a una tty pero muuuy lentamente - Desde la tty puedo ejecutar comandos pero responde muy lentamente Sin duda está paginando, debes tener algún proceso que se chupara toda la memoria. Yo probaría a instalar el atop y usar el atopsar para ver qué programas te cogían dicha memoria (realmente sé que te dice los programas que pilla la cpu, pero no estoy seguro que lo puedas ordenar por memoria, igual te da pistas) Cuando se te quede pillado, al arrancar ejecuta atopsar y a ver si te da pistas. El free te reporta los 8 gigas ? Con el top puedes ordenar por memoria con la 'M' y puedes ejecutar "ps vx krss" para ordenar (y ver más detalles del uso de memoria) la salida por uso de memoria con el ps. En tus logs aparece liferea, pero no sé si es él el que genera el follón o que simplemente el ookiller decide "matarlo". Parece que hace tiempo hubo un bug en liferea que era un memory leak, puede que venga por ahí el poblema: http://sourceforge.net/tracker/?func=detail&atid=581684&aid=1498277&group_id=87005 Un saludo Hola, si con las pruebas que te han comentado descubres que el problema es realmente con el archivo "gordo", te recomiendo lo abras con scite (aptitude install scite). Es el único editor de textos en gui que siempre me ha abierto cualquier archivo de cualquier tamaño. Saludos. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "oom-killer" (out of memory)
Hola, 2010/1/28 Camaleón : > Hola, > > Esta tarde se me ha quedado "frito" el equipo (lenny 64 bits), pero se ha > quedado bloqueado por ¿falta de memoria?. > > Tenía abiertas unas pocas aplicaciones (icedove, writer y iceweasel) y me > he descargado de la web un archivo xml de unos 100 MiB. Lo abro con > Epiphany y el programa se queda "atontao" (no lo carga) así que lo cierro > y abro el xml con gedit. > > Como veo que le cuesta abrirlo (es un archivo "gordo", pero tampoco es > para tanto :-P) ejecuto "top" para ver qué hace y al poco rato el equipo > se medio-congela. > > - Puedo mover el ratón pero responde muy lentamente > - Puedo acceder a una tty pero muuuy lentamente > - Desde la tty puedo ejecutar comandos pero responde muy lentamente Sin duda está paginando, debes tener algún proceso que se chupara toda la memoria. Yo probaría a instalar el atop y usar el atopsar para ver qué programas te cogían dicha memoria (realmente sé que te dice los programas que pilla la cpu, pero no estoy seguro que lo puedas ordenar por memoria, igual te da pistas) Cuando se te quede pillado, al arrancar ejecuta atopsar y a ver si te da pistas. El free te reporta los 8 gigas ? Con el top puedes ordenar por memoria con la 'M' y puedes ejecutar "ps vx krss" para ordenar (y ver más detalles del uso de memoria) la salida por uso de memoria con el ps. En tus logs aparece liferea, pero no sé si es él el que genera el follón o que simplemente el ookiller decide "matarlo". Parece que hace tiempo hubo un bug en liferea que era un memory leak, puede que venga por ahí el poblema: http://sourceforge.net/tracker/?func=detail&atid=581684&aid=1498277&group_id=87005 Un saludo -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
