☰

/dev/shm에 너무 많이 쓰면 스왑 파일이 자동으로 참여합니다.

tag-icon • tag-icon linux swap shared-memory
/dev/shm에 너무 많이 쓰면 스왑 파일이 자동으로 참여합니다.

오늘의 텍스트 분석 프로그래밍. 내 프로그램은 /dev/shm에 약 4,500만 개의 작은 임시 파일을 쓸 것이며, 그 크기는 177.0GB로 추정됩니다. 다음 단계 이후 즉시 삭제하겠습니다. 문제는 호스트 컴퓨터에 128GB의 물리적 RAM이 있는데 물리적 RAM이 충분하지 않다는 것입니다.

좋습니다. 질문: /dev/shm에 쓸 때 스왑이 자동으로 시작됩니까? 총 스왑 공간이 239GB이고 RAM이 128GB이므로 충분합니다.

두 번째 질문: 현재 /dev/shm에 100G가 할당되어 있습니다. /dev/shm을 미리 177G(또는 안전을 위해 190G)에 (물리적 RAM을 넘어) 과도하게 할당해야 합니까? 아니면 스왑이 현재 할당된 100G 이상의 사용량을 자동으로 처리하므로 /dev/shm 크기를 미리 190G로 설정할 필요가 없습니까?

그건 그렇고, 나는 이미 6천만 개의 inode를 가지고 있는데 이는 내 예상 필요량인 4천 5백만 개를 충족하기에 충분합니다. 이것은 좋다. 그런데, 나는 또한 Linux ext4가 디스크에 있는 약 1,050만 개의 파일에서 실패한다는 것을 발견했습니다. 이는 반복되지만 결정론적이지는 않습니다. Python 파일 쓰기에 관한 한 설계가 매우 느리게 진행되기 때문에 이는 시간 초과 문제인 것 같습니다. 아마도 파일 시스템 inode의 테이블 삽입을 위한 선형 시간 복잡도 알고리즘과 Python 파일 쓰기 인프라에 걸리는 시간이 너무 길면 더 많은 파일이 생성됩니다. , 명목상 20억 개의 파일 수 제한에도 불구하고. 여기서 SSD와 회전 디스크는 동일하게 작동하며 차이가 없습니다. inode도 괜찮고 여유 공간도 괜찮습니다. 단지 시간 초과로 인해 시스템이 종료되고 실제 파일 시스템에서 항상 OSError가 발생한다는 것뿐입니다(그래서 /dev/shm으로 이동합니다).

이 호스트는:

$ uname -a
Linux ga-HP-Z820 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64
ga@ga-HP-Z820:/mnt/fastssd/bot_subreddit_recom/tmp$ df -i /dev/shm
Filesystem       Inodes IUsed    IFree IUse% Mounted on
tmpfs          60000000     1 59999999    1% /dev/shm
ga@ga-HP-Z820:/mnt/fastssd/bot_subreddit_recom/tmp$ df -BG /dev/shm
Filesystem     1G-blocks  Used Available Use% Mounted on
tmpfs               100G    0G      100G   0% /dev/shm
ga@ga-HP-Z820:/mnt/fastssd/bot_subreddit_recom/tmp$

추가 정보:

IT는 여기에 말합니다

tmpfs 인스턴스가 너무 크면 OOM 핸들러가 해당 메모리를 해제할 수 없기 때문에 시스템이 교착 상태에 빠지게 됩니다.

. 그래서 난 안 할 것 같아! ! !https://www.cyberciti.biz/files/linux-kernel/Documentation/filesystems/tmpfs.txt

그래서 나는 교환이 모든 일을 처리하도록 놔두는지를 알아내기 위해 실험을 하기로 결정했습니다. 지금처럼 실행해 보세요. 내 파일이 /devshm에 할당된 크기를 초과하도록 하고 나머지는 스왑이 수행하도록 합니다.

답변1

/dev/shm에 너무 많은 파일을 쓰면 어떤 일이 일어나는지 살펴보겠습니다.

OSError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/fastssd/bot_subreddit_recom/write_user_docs.py", line 85, in <module>
    f.write(subreddits)
OSError: [Errno 28] No space left on device
inFile: RC_2018-01-02
outDir: tmp
outputToScreenOnly: 0
OSError: [Errno 28] No space left on device

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/fastssd/bot_subreddit_recom/write_user_docs.py", line 85, in <module>
    f.write(subreddits)
OSError: [Errno 28] No space left on device

파일을 입력한 지 33일 만에 위와 같이 '공간 부족' 상태가 되었습니다.

>>> 36.*33/12
99.0

따라서 약 99GB(100GB에 매우 가까움)의 파일이 "남은 공간 없음" 오류가 발생하는 곳입니다. 이것은 정확히 100G로 설정한 /dev/shm 장치의 크기입니다. 이는 필요할 때 실제로 스왑을 사용할 수 없음을 의미합니다. 불행하게도 이는 /dev/shm이 고갈되어 메모리가 부족할 때 스왑을 가상 메모리로 사용하여 계속 실행할 수 없음을 나타냅니다. 이제 우리는 이 실험을 통해 그것을 알게 되었습니다. /dev/shm이 작동하려면 실제 물리적 RAM만 필요하며, 스왑이라고도 불리는 가상 RAM은 /dev/shm에 전혀 도움이 되지 않습니다.

얻은 정보로 이익을 얻을 수 있는 다른 사람들과 공유하기 위해 이 답변을 게시합니다.

관련 정보