tmpfs가능성의 내림차순으로 :

┌───────────┬──────────────┬────────────────┐
│ /dev/shm  │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp      │ can be tmpfs │ FHS 1.0        │
├───────────┼──────────────┼────────────────┤
│ /var/tmp  │ never tmpfs  │ FHS 1.0        │
└───────────┴──────────────┴────────────────┘

Linux 특정 tmpfs 마운트 지점과 tmpfs 일 수 있는 이식 가능하게 정의 된 디렉토리 (sysadmin 및 배포판의 기본값에 따라 다름)에 대해 질문하므로 질문에 두 가지 측면이 있습니다. 다른 답변은 다르게 강조했습니다.

1. 모범 사례를 기반으로 이러한 디렉토리를 사용하는시기
2. tmpfs를 사용하는 것이 적절한 경우

좋은 습관

보수적 인 판 ( FHS 의 규칙 과 일반적인 사용의 혼합 ) :

• 확실하지 않은 경우을 사용하십시오 /tmp.
• /var/tmp램에 잘 맞지 않는 큰 데이터에 사용하십시오 .
• /var/tmp캐시와 같이 재부팅을 유지하는 데 유용한 데이터에 사용하십시오 .
• /dev/shm호출의 부작용으로 사용하십시오 shm_open(). 의도 한 대상은 끝없이 덮어 쓰는 경계 버퍼입니다. 따라서 이것은 내용이 변덕스럽고 크게 크지 않은 수명이 긴 파일을위한 것입니다.
• 여전히 의심스러운 경우 사용자가 대체 할 수있는 방법을 제공하십시오. 예를 들어, mktemp프로그램은 TMPDIR환경 변수를 존중합니다 .

실용적인 판 :

사용 /dev/shm이,의 tmpfs를 사용하는 것이 중요합니다 때 /var/tmp그렇지 않은 중요한 때 다른, /tmp.

tmpfs가 뛰어난 곳

fsynctmpfs에서 no-op입니다. 이 syscall은 (IO) 성능의 가장 큰 적이며, tmpfs (또는 eatmydata를 사용하여 자신을 찾는 경우 플래시 수명)) fsync를 물리 치기 위해 당신 (또는 체인의 다른 개발자)이 잘못하고 있습니다. 즉, 스토리지 장치에 대한 트랜잭션은 필요에 따라 불필요하게 세분화됩니다. 이제 모든 저장 장치를 완전히 파괴 한 것처럼 거의 성능 저하를 막기 위해 성능에 대한 일부 저장 점을 건너 뛰려고합니다. 또한, SSD를 보유함으로써 얻을 수있는 가장 큰 이점 중 일부는 트랜잭션 성능 영역에 있습니다. – 회전하는 디스크가 취할 수있는 것 (7200rpm = 120Hz)과 비교하여 괜찮은 SSD가 세상 밖에서 수행 될 것입니다. (다른 정보가없는 경우 액세스하는 경우) 플래시 메모리 카드는 말할 것도 없습니다. 플래시 메모리 카드는이 메트릭에 따라 크게 다릅니다 (특히 SD 카드 클래스 등급과 같이 순차적 성능과의 트레이드 오프이기 때문에). 그러니 조심하세요

우스운 이야기를 듣고 싶습니까? 첫 번째 fsync교훈 : Sqlite 데이터베이스 (테스트 케이스로 유지됨)를 끊임없이 변화하는 현재 형식으로 일상적으로 “업그레이드”하는 작업이있었습니다. “업그레이드”프레임 워크는 하나 이상의 데이터베이스를 업그레이드하기 위해 각각 하나 이상의 트랜잭션을 작성하여 많은 스크립트를 실행합니다. 물론, 데이터베이스를 병렬로 업그레이드했습니다 (8 개의 병렬 CPU가 있기 때문에 병렬로 8 개). 내가 발견하지만, 어떠한 병렬 처리 속도 향상 (오히려 약간 없었다 히트는 프로세스가 완전히 IO 바운드 때문에). 설득력있게 각 데이터베이스를 복사 한 스크립트에서 업그레이드 프레임 워크를 래핑하여 업그레이드 /dev/shm한 다음 디스크에 다시 복사하는 것은 100 배 더 빠릅니다 (여전히 8 개 병렬 처리). 보너스로 PC를 사용할 수 있었습니다 데이터베이스를 업그레이드하는 동안에도 마찬가지입니다.

tmpfs가 적절한 곳

tmpfs의 적절한 사용은 휘발성 데이터의 불필요한 쓰기를 피하는 것입니다. 일반 파일 시스템에서 무한대로 설정 하는 것과 같이 writeback을 효과적으로 비활성화 /proc/sys/vm/dirty_writeback_centisecs합니다.

이것은 성능과 관련이 거의 없으며 실패하면 fsync를 남용하는 것보다 훨씬 작은 관심사입니다. 후기 입 시간 초과는 페이지 캐시 내용 후 디스크 내용이 얼마나 느리게 업데이트되는지를 결정하며 컴퓨터의 기본값은 5 초입니다. – 응용 프로그램은 페이지 캐시에서 원하는만큼 파일을 덮어 쓸 수 있지만 디스크의 내용은 약 5 초마다 한 번 씩만 업데이트됩니다. 응용 프로그램이 fsync로 강제 실행하지 않는 한, 즉. 이 때 응용 프로그램이 작은 파일을 몇 번 출력 할 수 있는지 생각해보십시오. 모든 파일을 fsync하는 것이 더 큰 문제인 이유를 알 수 있습니다.

tmpfs가 당신을 도울 수없는 것

• 성능을 읽습니다. 데이터가 뜨거우면 (tmpfs에 보관하는 것이 좋습니다) 어쨌든 pagecache를 누르십시오. 차이점은 pagecache를 누르지 않을 때입니다. 이 경우 아래의 “tmpfs sux 위치”로 이동하십시오.
• 수명이 짧은 파일. 이들은 기록되기 전에 페이지 캐시 ( 더티 페이지) 에서 전체 수명을 유지할 수 있습니다 . fsync물론 강요하지 않는 한 .

여기서 tmpfs sux

차가운 데이터를 유지 합니다. 스왑에서 파일을 제공하는 것이 일반적인 파일 시스템만큼 효율적이라고 생각할 수도 있지만 그 이유는 다음과 같은 두 가지 이유가 있습니다.

• 가장 간단한 이유 : 현대 저장 장치 (하드 디스크 또는 플래시 기반)가 적절한 파일 시스템으로 깔끔하게 정리 된 순차 파일을 읽는 것보다 더 좋아하는 것은 없습니다. 4KiB 블록으로 스와핑하면 개선되지 않을 것입니다.
• 숨겨진 비용 : 스와핑 밖으로 . Tmpfs 페이지는 더럽습니다 . 즉각 제거 할 수있는 파일 백업 된 클린 페이지 와 달리 페이지 캐시에서 제거하려면 스왑을 위해 어딘가에 작성해야합니다 . 이것은 메모리와 경쟁하는 다른 모든 것에 대한 추가 쓰기 페널티입니다. tmpfs 페이지를 사용하는 것과 다른 시간에 다른 것에 영향을 미칩니다.

답변