내 시스템 디스크 사용량은 다음과 같습니다.
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rhel-root 50G 39G 12G 77% /
devtmpfs 5.8G 0 5.8G 0% /dev
tmpfs 5.8G 240K 5.8G 1% /dev/shm
tmpfs 5.8G 50M 5.8G 1% /run
tmpfs 5.8G 0 5.8G 0% /sys/fs/cgroup
/dev/mapper/rhel-home 1.3T 5.4G 1.3T 1% /home
/dev/sda2 497M 212M 285M 43% /boot
/dev/sda1 200M 9.5M 191M 5% /boot/efi
tmpfs 1.2G 16K 1.2G 1% /run/user/1200
tmpfs 1.2G 16K 1.2G 1% /run/user/1000
tmpfs 1.2G 0 1.2G 0% /run/user/0
다음에 대해 질문이 있습니다 2. (1) devtmpfstmpfs
devtmpfs 5.8G 0 5.8G 0% /dev
tmpfs 5.8G 240K 5.8G 1% /dev/shm
tmpfs 5.8G 50M 5.8G 1% /run
tmpfs 5.8G 0 5.8G 0% /sys/fs/cgroup
위의 공간은 모두 5.8G동일한 메모리 공간을 공유합니까?
(2)
tmpfs 1.2G 16K 1.2G 1% /run/user/1200
tmpfs 1.2G 16K 1.2G 1% /run/user/1000
tmpfs 1.2G 0 1.2G 0% /run/user/0
/run/user각 사용자는 파티션 내 공유 공간이 아닌 자신만의 전용 메모리 공간을 갖고 있나요 ?
답변1
"Avail"은 모든 tmpfs 마운트에 대한 인위적인 제한입니다. tmpfs 마운트의 기본 크기는 RAM의 절반입니다. 설치 중에 조정될 수 있습니다. ( man mount, tmpfs)로 스크롤합니다.
마운트를 채우면 더 이상 "사용됨"으로 표시되지 않으며 반드시 데이터 쓰기를 방해하지 않기 때문에 마운트는 동일한 공간을 공유하지 /dev/shm않습니다 /dev./dev
( tmpfs단일 tmpfs에서 마운트를 바인딩하여 공유 공간 설치를 설계할 수 있습니다. 그러나 기본적으로 설치가 설정되는 방식은 아닙니다.)
둘 다 시스템 메모리로 지원되므로 동일한 공간을 공유합니다. /dev/shm및 을 모두 채우려고 하면 /dev물리적 RAM과 동일한 공간을 할당하게 됩니다. 스왑 공간이 있다고 가정하면 이는 전적으로 가능합니다. 그러나 이는 일반적으로 좋은 생각이 아니며 결국 나쁜 결과를 낳게 됩니다.
이는 여러 사용자가 액세스할 수 있는 tmpfs 마운트를 갖는다는 아이디어에 맞지 않습니다. 많은 시스템에서 + 입니다 /dev/shm. /tmp라고 할 수 있다회의두 개의 대형 설치물이 같은 공간을 공유한다면 더 좋을 것입니다. (Posix SHM은 실제로 사용자가 액세스할 수 있는 tmpfs에서 파일을 열기 위한 인터페이스입니다.)
/dev/, /run은 /sys/fs/cgroups시스템 디렉터리입니다. 크기가 작아야 하며 많은 양의 데이터를 저장하는 데 사용되지 않아야 하므로 문제가 발생하지 않아야 합니다. Debian(8)은 500MB 시스템에서 제한을 설정하는 것이 더 나은 것 같습니다. 10, 100, 250MB와 5로 제한되어 있습니다 /run/lock.
/run내 시스템에서는 약 2MB가 사용됩니다. systemd-journal은 이것의 큰 부분을 차지하며 기본적으로 "Avail"의 10%까지 증가할 수 있습니다. ( RuntimeMaxUse옵션), 내 모델에 맞지 않습니다.
그래서 50MB가 있는 것 같아요. 물리적 RAM의 5%에 해당하는 로그 파일을 사용하도록 허용합니다... 개인적으로 그 자체로는 큰 문제는 아니지만 예쁘지는 않으며 버그/누락이라고 부르고 싶습니다. 2MB 표시와 같은 순서로 캡을 설정하면 더 좋을 것 같습니다.
현재는 /run팽창으로 인한 사망을 방지하려면 각 시스템마다 크기를 수동으로 설정하는 것이 좋습니다. (내 데비안 예에서) 2%조차도 매우 주제넘은 것 같습니다.
답변2
각 tmpfs인스턴스는 독립적이므로 메모리를 과도하게 할당할 수 있으며, 큰 파일로 전체 메모리를 채우면 tmpfs더 이상 사용할 수 있는 메모리가 없어 시스템이 결국 정지되고 메모리를 해제할 수 없게 됩니다. ( tmpfs파일을 삭제하거나 언로드하지 않고) .
tmpfs스왑 파티션을 사용하여 데이터를 스왑 아웃하는 것이 가능하지만, 이러한 파일을 적극적으로 읽고 쓰고 있고 해당 시점에서 다시 스왑해야 하는 경우에는 도움이 되지 않습니다.
기본적으로 설치된 인스턴스 수가 많은 시스템은 인스턴스 가 존재하는 한 실제로 한도까지 채워지지 않을 tmpfs것이라는 가정하에 작동하는 경우가 많습니다 .tmpfs
이 작업을 시도하고 싶다면(아무 것도 설치하지 않은 Live CD를 사용하는 것이 좋습니다) 작동 방법은 다음과 같습니다.
mkdir a b c
mount -t tmpfs tmpfs a
mount -t tmpfs tmpfs b
mount -t tmpfs tmpfs c
truncate -s 1T a/a b/b c/c
shred -v -n 1 a/a b/b c/c
이렇게 하면 각각 기본적으로 메모리 제한이 50%인 3개의 인스턴스가 생성되므로 tmpfs총 150%가 됩니다(스왑을 제외하고 스왑이 있는 경우 자유롭게 추가하세요 d e f ...).
출력은 shred다음과 같습니다.
shred: a/a: pass 1/1 (random)...
shred: a/a: error writing at offset 1049104384: No space left on device
shred: b/b: pass 1/1 (random)...
# system hangs indefinitely at this point, without swap it never reaches c/c #
답변3
(1) 모든 기반 파일 시스템은 tmpfs운영 체제에서 백엔드로 사용할 수 있는 가상 메모리를 공유합니다. devtmpfs우연히 같은 공간을 사용하게 되지만, 전자와 달리 데이터를 담지 않기 때문에 커지면 안 된다.
(2) /run/users하위 디렉터리는 systemd에 의해 개인 임시 /tmp디렉터리로 생성됩니다. 또한 다른 모든 파일 기반 시스템과 tmpfs동일한 가상 메모리 공간을 공유합니다 . 더 작게 나타나는 이유는 단일 사용자가 이 디렉토리를 채워 다른 모든 사용자에게 영향을 주지 않도록 제한이 설정되어 있기 때문입니다.