미칠 것 같은 느낌이 들거나 tmpfs는 장기간 사용하기에 적합하지 않습니다.
내 워크로드는 /dev/shm/[일부 디렉터리 트리]에 파일을 매우 빠르게 생성하고 연결을 해제합니다. Linux 슬랩 사용량(크기 64 및 크기 128)은 inode 할당/링크 해제에 따라 선형적으로 증가하며 절대 다운되지 않습니다(메모리는 meminfo를 통해 회수 불가능으로 나열되고, slabinfo는 수백만 개의 라이브 객체를 표시합니다).
이 메모리는 결코 회수되지 않으며 계속하도록 허용되면 OOM이 발생합니다. 유일한 수정 방법은 /dev/shm을 제거하고 다시 설치하는 것입니다.
몇 년 전에 다른 사용자가 이 질문을 했지만 답변이 실제로 문제의 문제를 다루지는 않았습니다(/dev/shm의 작업으로 인해 오버플로가 발생했습니다.).
이것은 단지 tmpfs의 설계 결정입니까, 아니면 다른 것이 있습니까? 인덱스 노드가 한 번 할당되면 해제되지 않는다는 점은 정말 안타깝습니다.
타임라인: 이 프로세스는 한 번에 하나씩 500만 개의 파일을 생성하고 생성 후 즉시 각 파일의 연결을 해제합니다. 이 시점에서 모든 사용자 프로세스가 종료됩니다. 메모리 사용량은 /dev/shm에 여전히 5백만 개의 inode가 있는 것처럼 보이지만 df -i 및 df -h는 /dev/shm이 본질적으로 비어 있다고 보고합니다. 프로세스 루프를 추가로 반복하면 시스템 메모리가 완전히 부족하고 OOM이 발생할 때까지 메모리 사용량이 선형적으로 증가합니다.
편집: 나중에 이 문제가 발생하는 경우 이는 제가 실행 중인 이전 커널(SLES 11, 2.6.32 등)의 아티팩트인 것으로 보입니다. 최신 커널에서는 문제를 재현할 수 없습니다.
답변1
이는 이 특정 시스템에서 실행되는 이전 커널의 버그인 것 같습니다. 최신 커널 패치가 설치된 최신 RHEL 6 시스템에서는 이를 재현할 수 없습니다.
답변2
명확성을 위해 우리가 의견에서 논의한 내용에 대해 어느 정도 스크립트 테스트를 추가했습니다. 이 시간은커널 4.7.2문제가 발생하지 않는 경우:
$ cd /dev/shm
$ free
total used free shared buff/cache available
Mem: 1794788 673948 873668 19300 247172 963316
Swap: 2097148 0 2097148
$ for i in `seq 100000`; do touch node$i; done
$ ls -1|wc -l # oops, there are extra three pulseaudio files here
100003
$ free
total used free shared buff/cache available
Mem: 1794788 738240 811944 19300 244604 890184
Swap: 2097148 0 2097148
좋아요, 메모리 공간을 확보했습니다. 하지만 rm클리어해
$ rm node*
$ free
total used free shared buff/cache available
Mem: 1794788 671484 896524 19300 226780 965884
Swap: 2097148 0 2097148
일부 캐시를 동시에 삭제했기 때문에 이 게임은 완벽하지 않습니다. 하지만 이 작은 실험의 시작과 끝에서는 사용 가능한 메모리의 양과 캐시에 있는 메모리의 양이 동일했습니다.
그렇습니다. 문제는 이전 커널 버전에서만 발생합니다. 이는 버그가 있었지만 수정되었음을 나타냅니다.