VirtualBox를 시작한 후 컴퓨터가 느려지고 OOM으로 인해 완전히 정지됩니다. 일반적으로 OOM은 공간을 확보하기 위해 프로세스 종료를 시작해야 하지만, 이런 일은 발생하지 않습니다(이런 현상은 이번이 두 번째입니다).
SysRq텍스트 편집기에 저장되지 않은 중요한 작업이 있으므로 +를 사용하여 현재 콘솔의 모든 프로세스를 종료한 후 시스템 RAM에서 해당 작업을 찾으려고 합니다 K. 머신은 SSD를 대상 디스크로 사용하여 Linux x86_64 3.7.5를 실행하는 8GiB RAM이 있는 노트북입니다.
첫 번째 시도는 이었지만 dd if=/dev/mem of=memory
1MiB의 데이터를 읽은 후 실패했습니다. 다음으로 시도한 것은dd if=/dev/fmem of=memory bs=1M
, 그러나 3010461696바이트(정확히 2871MiB)를 읽은 후 중지됩니다. /proc/mtrr
아래에 표시된 내용을 살펴본 후 skip=4096
. (파일의 마지막 100MiB에는 최소 FF
s가 포함됩니다.)
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
몇 시간 동안 텍스트 편집기에 열려 있던 데이터를 찾을 수 없어서 덤프할 때 일부 메모리를 건너뛴 것 같습니다. 그렇다면 내 목표(사용자 공간 프로그램에서 데이터 복구)를 고려할 때 시스템 메모리를 파일로 덤프하는 가장 효율적인 방법은 무엇입니까? 그러한 덤프를 할 때 고려해야 할 사항은 무엇입니까?
답변1
이 프로젝트를 확인해 보세요:포리아나
Foriana 예(FOrensic Ram 이미지 분석기)
입력: (물리적) RAM 덤프 출력: 다양한 정보
버전 1.0은 i386/x86_64/arm linux/bsd 커널 메모리 덤프의 프로세스와 모듈을 나열할 수 있으며 덤프에서 선형 메모리를 읽는 옵션을 제공합니다.
커널 모듈 fmem이 있습니다:
Fmem은 /dev/fmem 장치를 생성하는 커널 드라이버입니다. /dev/fmem은 /dev/mem(물리적 메모리에 대한 직접 액세스)과 동일한 방식으로 작동하지만 /dev/mem의 제한은 없습니다. /dev/fmem을 통해 전체 물리적 메모리를 덤프하는 것이 가능합니다.
나는 그것을 사용했고 컴파일하기 쉽습니다.
답변2
ddrescue
액세스할 수 없는 데이터를 건너뛸 수 있는 유사한 프로그램을 사용하는 것이 좋습니다 . dd conv=noerror
도움이 될 수도 있습니다. 이것도 확인해보세요슈퍼유저에 대한 질문.
그러나 더 중요한 것은 OOM 상황이 발생하면 요청하는 응용 프로그램이 아닌 다른 곳에서 페이지를 교체하는 커널로 인해 속도가 느려질 가능성이 높다는 것입니다. 따라서 데이터를 원하면 대신 교환을 확인하세요 /dev/mem
. 데이터가 있을 가능성이 높습니다. 마찬가지로, OOM 킬러가 시작되지 않고 프로세스를 수동으로 종료하는 경우, 편집기가 먼저 종료된 후에도 메모리가 부족한 프로세스는 여전히 해당 페이지를 가져올 시간이 있을 수 있습니다.
Gilles가 의견에서 언급했듯이 데이터는 쉽게 특수 구조에 있을 수 있으므로 종료된 프로세스의 주소 공간 매핑을 재구성하더라도 쉽게 찾을 수 없습니다.그리고필요한 모든 페이지가 아직 손상되지 않은 상태에서 찾을 수 있는 충분한 행운이 있습니다.