Después de iniciar VirtualBox, la computadora se volvió lenta y luego se colgó por completo debido a OOM. Por lo general, OOM debería comenzar a matar procesos para liberar espacio, pero esto no sucedió (esta fue la segunda vez que experimenté esto).
Tenía un trabajo importante no guardado en un editor de texto, por lo que esperaba encontrarlo de nuevo en la RAM del sistema después de eliminar todos los procesos en la consola actual usando SysRq+ K. La máquina en cuestión es una computadora portátil con 8 GiB RAM que ejecuta Linux x86_64 3.7.5 con un SSD como disco de destino.
Mi primer intento fue dd if=/dev/mem of=memory, pero esto falló después de leer 1MiB de datos. Luego, lo intenté dd if=/dev/fmem of=memory bs=1M, pero esto se detuvo después de leer 3010461696 bytes (exactamente 2871 MiB). Después de mirar /proc/mtrr(se muestra a continuación), decidí intentar agregar skip=4096. Esto finalmente se ralentizó, leyendo a una velocidad de solo 3 MiB / seg, por lo que lo interrumpí (produciendo un archivo de 5.8 GiB). (al menos los últimos 100 MiB del archivo contienen FFs)
reg01: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg02: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg03: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg04: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg05: base=0x23c000000 ( 9152MB), size= 64MB, count=1: uncachable
reg06: base=0x0b4000000 ( 2880MB), size= 64MB, count=1: uncachable
reg07: base=0x0b8000000 ( 2944MB), size= 128MB, count=1: uncachable
No pude encontrar los datos que había abierto durante algunas horas en el editor de texto, así que creo que me he saltado algo de memoria mientras hacía un volcado. Entonces, dado mi objetivo (recuperación de datos de programas de espacio de usuario), ¿cuál es el método más eficiente para volcar la memoria del sistema en un archivo? ¿Cuáles son algunos puntos que deben tenerse en cuenta al hacer este volcado?
fuente
CONFIG_DEVKMEMestá deshabilitado, al mirar en el código fuente parece permitir el acceso sin restricciones, pero todavía no estoy convencido de que esta sea la mejor manera de hacerlo (¿acceso de IO mem?)Respuestas:
Mira este proyecto: foriana
Hay un módulo de kernel fmem:
Lo tengo, compilar bastante fácil.
fuente
/dev/fmem.Es posible que desee utilizar
ddrescueun programa similar o similar, que puede omitir datos inaccesibles.dd conv=noerrorpodría ser útil también También revise esta pregunta en superusuario .Sin embargo, lo más importante es que si te metiste en una situación de OOM, la lentitud probablemente fue causada por el intercambio de páginas del kernel de cualquier otra cosa que no sea la aplicación solicitante. Por lo tanto, si desea sus datos, verifique el intercambio en lugar de
/dev/mem: es probable que estén allí. Del mismo modo, si el asesino de OOM no se activa y usted mata los procesos a mano, una vez, por ejemplo, su editor es asesinado primero, el proceso de memoria aún puede pasar algún tiempo para tomar esas páginas.Como mencionó Gilles en el comentario, los datos pueden estar fácilmente en una estructura especial, por lo que no podrá encontrarlos fácilmente, incluso si logra reconstruir las asignaciones de espacio de direcciones del proceso finalizado y tiene la suerte de encontrar todo lo necesario páginas aún intactas.
fuente
ddrescueno me va a ayudar ya que 256 páginas (1 MiB) es un límite codificado. Esperaría entrar en una condición de OOM, pero el asesino de OOM no se activó ( pastebin.com/DvYTCcRK ). Hace una semana, tuve el mismo problema (todavía Linux 3.7.5, no lo he reiniciado, solo lo suspendí en RAM). No hay archivo / partición de intercambio ya que tengo un SSD. (intercambio = 60 (predeterminado)).