내 VPS 호스트의 구성용 웹 인터페이스에는 /tmp.
기본값은 "16MB RAM"이고 대안은 "하드디스크"입니다.
16MB만 사용하면 /tmp일부 소프트웨어에 문제가 발생할 수 있습니까? 아니면?
답변1
16MB의 /tmp만 사용하면 일부 소프트웨어에 문제가 발생할 수 있습니까?
예, 일부 소프트웨어가 쓰기를 원 /tmp하고 해당 소프트웨어나 다른 소프트웨어가 이미 파티션을 채운 경우 가능합니다. 일반적으로 이는 시스템의 잘못된 구성, 사용 가능한 리소스에 대한 정당한 제한 또는 다른 소프트웨어 부분의 오작동을 나타냅니다. 어떤 경우에도 작성하려는 소프트웨어가 자체적으로 솔루션을 찾으려고 시도할 가능성이 거의 없습니다. 오류가 발생합니다.
일부 소프트웨어는 에 대용량 파일을 쓸 수 있다고 가정합니다 /tmp. 이는 공정한 가정입니다. 이 문제는 "잘못된 구성" 오류에 속합니다.
스스로에게 물어봐야 할 첫 번째 질문은 "RAM을 사용하면 어떤 이점이 있습니까 /tmp?" 입니다. 가장 분명한잠재적인이점은 RAM에 액세스하는 것이 디스크에 액세스하는 것보다 훨씬 빠르다는 것입니다. 그러나 명백히 명백한 이 잠재적 이점은 다음과 같은 이유로 실제로는 그다지 유익하지 않을 것입니다.
시스템은 자주 액세스하는 파일을 RAM에 캐시합니다. 이 캐시에 사용할 수 있는 RAM의 양을 줄이는 것은
/tmp약간 어리석은 일입니다. 이는 자주 사용되지 않는 파일이/tmp캐시에서 자주 사용되는 파일을 대체한다는 의미이기 때문입니다.응용프로그램은 이미 RAM에 항목을 자유롭게 저장할 수 있습니다. 일반적으로 파일에 항목을 저장하는 것보다 쉽기 때문에 무언가를 tmp 파일에 넣으면 RAM에 저장하는 것이 도움이 될 가능성이 거의 없습니다. 실제로 에 무엇이 있는지 살펴보면
/tmp아마도 대부분 소켓과 fifo 또는 약간의 IPC 데이터일 것입니다. RAM 기반 파일 시스템을 통해 액세스하는 것이 개념적으로는 더 깔끔하지만 실제로 차이가 있는지 의심됩니다.
그렇다면 왜 /tmpRAM에 구현됩니까?
/tmp이는 의 기본 속성 , 즉 종료 시 지워지는 속성의 구현을 단순화합니다 .하드웨어의 마모를 약간 줄일 수 있습니다. 이는 저장용으로 저렴하고 수명이 제한된 플래시만 있거나 쓰기 가능한 저장 장치가 전혀 없는 상황(예: 임베디드 시스템)에서 훨씬 더 중요합니다.
/tmp남용되지 않는다고 가정하면 RAM을 사용하면 일반적으로 최신 하드웨어의 막대한 메모리 용량을 활용할 수 있습니다. 즉, 이러한 항목은 RAM에 있을 수도 있으며 RAM에 있을 수도 있습니다.
16MB~할 수 있었다충분하지만 일부 프로세스가 문제가 발생하면 여전히 그렇게 많지 않으며 /tmp누구나 쓸 수 있어야 합니다. 그러나 일부 프로세스가 에 내용을 쓰는 데 문제가 있는 경우 /tmp결국 하드 드라이브를 채우거나 RAM 파티션을 모두 소모했기 때문에 더 빨리 위험 신호를 보내는 것이 더 좋을까요?
사용 중인 소프트웨어에 확신이 있다면 후자가 더 적합하므로 RAM 파티션을 선택할 수 있습니다. /tmp비정상적인 일이 발생할 경우를 대비하여 먼저 실제 사용량을 조금 조사해야 합니다 (예: du -h /tmp). "정상 임계값"을 생각해 내고 크론 작업을 통해 이를 확인하여 임계값이 초과되면 누군가에게 알리거나 긴급 청소를 수행할 수 있습니다.
불행하게도 일부 앱은 /tmp갑자기 오류가 발생해도 제거되지 않는 항목을 가끔 덤프할 수 있으며 자주 종료되지 않는 서버에서는 무기한 남아 있을 수 있습니다. 이는 매우 무해하게 발생할 수 있습니다. 예를 들어 누군가 로그인하여 무언가를 사용할 때 연결이 임의로 닫히거나 중단됩니다.
따라서 RAM이 아닌 것이 /tmp더 안전합니다. 남용은 오랫동안 눈에 띄지 않을 수 있지만 RAM의 경우만큼 중요하지 않기 때문입니다. 게다가 실제로 문제가 발생하는 경우 문제의 원인을 나타내는 스모킹 건이 디스크에 남아 있을 것입니다.