Astropy: memmap 버그에 맞는 가능성 : memmap이 작동하지 않습니다.

어떤 OS?

ulimit -v 는 무엇을 반환합니까?

OS는 리눅스의 일부입니다. 내 머리 꼭대기에서 모르거나
가장 쉬운 명령입니다.

또한 python / astropy / numpy의 anaconda 설치를 사용했지만 업그레이드되었습니다.
pip를 통한 astropy.

$ ulimit -v
제한 없는

2013 년 8 월 27 일 화요일 오후 4:02에 Erik Bray [email protected] 은 다음과 같이 썼습니다.

어떤 OS?

ulimit -v는 무엇을 반환합니까?

—
이 이메일에 직접 회신하거나 Gi tHub에서 확인하십시오.
.

아담

cat /proc/meminfo 는 무엇을 보여줍니까?

$ cat /proc/meminfo
MemTotal:        1903396 kB
MemFree:          203864 kB
Buffers:          215320 kB
Cached:           884708 kB
SwapCached:         2268 kB
Active:           492052 kB
Inactive:         954324 kB
Active(anon):     165684 kB
Inactive(anon):   181096 kB
Active(file):     326368 kB
Inactive(file):   773228 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       1048568 kB
SwapFree:        1031460 kB
Dirty:                24 kB
Writeback:             0 kB
AnonPages:        344352 kB
Mapped:            65676 kB
Shmem:               432 kB
Slab:             191348 kB
SReclaimable:     151148 kB
SUnreclaim:        40200 kB
KernelStack:        2312 kB
PageTables:        22940 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     2000264 kB
Committed_AS:     847268 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      286128 kB
VmallocChunk:   34359439336 kB
HardwareCorrupted:     0 kB
AnonHugePages:     12288 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        8188 kB
DirectMap2M:     2070528 kB

... 그것은 아주 작은 양의 메모리처럼 보입니다. 2GB? 음.

@keflavich-여전히이 문제가 발생합니까?

이것에 대해 완전히 잊었습니다. MemTotal 는 사용 가능한 총 실제 메모리입니다. 이 2GB는 많지는 않지만 문제가되지는 않습니다. 여기서 중요한 것은 VmallocTotal 에 대해 약 32TB입니다. 원칙적으로 mmap은 대부분을 사용할 수 있어야합니다. 그래서 여기서 뭔가 수상한 일이 벌어지고 있습니다.

아! 여기에 문제가있는 것 같습니다. 기본적으로 PyFITS는 읽기 전용 모드에서 파일을 열 때 MAP_PRIVATE 사용하므로 사용자는 전체 파일이 주 메모리에 매핑 된 경우처럼 제자리에서 데이터 배열을 수정할 수 있습니다.

문제는 원칙적으로 전체 파일을 덮어 쓸 수 있다는 것을 의미하므로 mmap이 발생하는 경우 미리 충분한 메모리를 할당 할 수 있어야합니다. 이것이 여기서 일어나는 이유입니다. PyFITS / Astropy는 확실히 해당 시나리오를 포착하고 더 유용한 오류를 제공해야합니다.

현재이 문제를 해결하는 방법에는 두 가지가 있습니다. mode='denywrite 파일을 열 수 있습니다. 이 경우를 위해 특별히 조금 전에 추가했지만 거의 사용되지 않습니다. 그러면 MAP_SHARED | PROT_READ mmap이 열립니다. 이는 페이지가 읽기 전용임을 의미합니다 (배열을 수정하려고하면 예외가 발생 함). 그러나 필요한 모든 것이 데이터를 읽는 것이라면 잘 작동하며 스왑 공간을 할당 할 필요가 없다고 생각합니다.

또 다른 가능성은 mode='update' 로 여는 것입니다. 그런 다음 배열에 대한 모든 변경 사항을 파일에 직접 동기화 할 수 있습니다. 원하는 경우 괜찮지 만 그렇지 않은 경우에는 그다지 많지 않습니다.

man 페이지를 보면 적어도 Linux에는 MAP_NORESERVE 라는 플래그가있는 것 같습니다.이 플래그는 copy-on-write 공간을 미리 할당하지 못하게합니다. 따라서 전체 배열에 대한 변경 사항도 쓸 필요가 _ 필요하지 않은 경우. 하지만 스왑 공간이 부족 해지면 결과가 나오는 SIGSEGV를 파악할 수 있어야합니다.

이 문제를 직접 재현 할 수있었습니다. 실제로 제가 제공 한 두 가지 해결 방법 ( mode='denywrite' 및 mode='update' 작동합니다. MAP_NORESERVE 에 대해 내가 할 수있는 작업을 계속 확인하려고합니다. 이 오류를 포착하고 더 나은 오류 메시지를 제공합니다.

성가심 : numpy.memmap 에서는 mmap 호출에 전달되는 플래그를 조정할 수 없습니다. 그것을 살펴 보더라도 올바른 플래그로 mmap을 만든 다음 mmap을 버퍼로 사용하여 ndarray.__new__ 를 호출하는 작업을 처리하는 것은 ndarray 의 가벼운 하위 클래스에 지나지 않습니다. 또한 flush 메서드를 추가합니다.

numpy.memmap 사용을 아예 피하고 mmap을 직접 처리하는 것이 충분히 쉬워야합니다. 그러나 그것은 지금 당장 제가하고 싶은 것보다 더 많은 것입니다. 따라서 대신 오류를 포착하고 기존 해결 방법 중 하나를 제안하여이 문제를 해결하겠습니다.

# 7597에서는 더 이상 np.memmap 를 사용하지 않으므로 유용한 경우 다른 플래그를 사용하는 것이 더 쉬울 것입니다.

https://github.com/astropy/astropy/pull/7926에 해결 방법이 병합되었으므로 이제 닫을 수 있습니다 MAP_NORESERVE 은 Python에서 사용할 수 없으므로 불행히도 해결책이 아닙니다.