답변:
/dev/shm백업 저장소에 RAM을 사용 하는 임시 파일 저장 파일 시스템 (예 : tmpfs )입니다. IPC 를 용이하게하는 공유 메모리 구현으로서 기능 할 수 있습니다 .
최근 2.6 Linux 커널 빌드는 / dev / shm을 램 디스크 형태로 공유 메모리로, 특히 / etc / default / tmpfs에 정의 된 한계를 가진 메모리에 저장되는 세계 쓰기 가능 디렉토리로 제공하기 시작했습니다. / dev / shm 지원은 커널 설정 파일에서 완전히 선택 사항입니다. 기본적으로 Fedora 및 Ubuntu 배포판에 포함되어 있으며 Pulseaudio 응용 프로그램에서 가장 광범위하게 사용됩니다. (공포도 추가됨)
/tmpFilesystem Hierarchy Standard에 정의 된 임시 파일의 위치이며 거의 모든 Unix 및 Linux 배포가 뒤 따릅니다.
RAM이 디스크 스토리지보다 훨씬 빠르기 때문에 프로세스가 I / O 집약적이고 임시 파일을 광범위하게 사용하는 경우 성능 향상 대신에 사용할/dev/shm/tmp 수 있습니다 .
당신의 질문에 대답하기 위해서 : 아니오, 당신은 항상 /dev/shm존재 하는 것에 의존 할 수는 없습니다 . 사용할 /tmp이유가 충분하지 않으면 사용해야합니다 /dev/shm.
그 기억 /tmp의 일부가 될 수 있습니다 /대신 별도의 마운트 파일 시스템, 필요에 따라 따라서 증가 할 수 있습니다. 크기는 /dev/shm시스템의 초과 RAM으로 인해 제한되므로이 파일 시스템의 공간이 부족할 가능성이 큽니다.
/dev/shm. /dev/shm디스크 (스왑)가 지원하는 메모리 (tmpfs)입니다. /var/tmp디스크 (온 디스크 파일 시스템)가 지원하는 메모리 (디스크 캐시)입니다. 실제로, 성능은 거의 같습니다 (tmpfs는 약간 우세하지만 중요하지는 않습니다). /tmp관리자가 구성한 방법에 따라 tmpfs이거나 아닐 수 있습니다. /dev/shm스크립트 에 사용할 이유가 없습니다 .
/tmp일반적인 위치입니다 ( $TMPDIR재정의). 선택 이끌어 /tmp스왑, 다른 디스크 공간 또는 아무것도의 지원은 관리자입니다.
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 및 배포판의 기본값에 따라 다름)에 대해 질문하므로 질문에 두 가지 측면이 있습니다. 다른 답변은 다르게 강조했습니다.
보수적 인 판 ( FHS 의 규칙 과 일반적인 사용의 혼합 ) :
/tmp./var/tmp램에 잘 맞지 않는 큰 데이터에 사용하십시오 ./var/tmp캐시와 같이 재부팅을 유지하는 데 유용한 데이터에 사용하십시오 ./dev/shm호출의 부작용으로 사용하십시오 shm_open(). 의도 한 대상은 끝없이 덮어 쓰는 경계 버퍼입니다. 따라서 이것은 내용이 변덕스럽고 크게 크지 않은 수명이 긴 파일을위한 것입니다.mktemp프로그램은 TMPDIR환경 변수를 존중합니다 .실용적인 판 :
사용 /dev/shm이,의 tmpfs를 사용하는 것이 중요합니다 때 /var/tmp그렇지 않은 중요한 때 다른, /tmp.
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의 적절한 사용은 휘발성 데이터의 불필요한 쓰기를 피하는 것입니다. 일반 파일 시스템에서 무한대로 설정 하는 것과 같이 writeback을 효과적으로 비활성화 /proc/sys/vm/dirty_writeback_centisecs합니다.
이것은 성능과 관련이 거의 없으며 실패하면 fsync를 남용하는 것보다 훨씬 작은 관심사입니다. 후기 입 시간 초과는 페이지 캐시 내용 후 디스크 내용이 얼마나 느리게 업데이트되는지를 결정하며 컴퓨터의 기본값은 5 초입니다. – 응용 프로그램은 페이지 캐시에서 원하는만큼 파일을 덮어 쓸 수 있지만 디스크의 내용은 약 5 초마다 한 번 씩만 업데이트됩니다. 응용 프로그램이 fsync로 강제 실행하지 않는 한, 즉. 이 때 응용 프로그램이 작은 파일을 몇 번 출력 할 수 있는지 생각해보십시오. 모든 파일을 fsync하는 것이 더 큰 문제인 이유를 알 수 있습니다.
fsync물론 강요하지 않는 한 .차가운 데이터를 유지 합니다. 스왑에서 파일을 제공하는 것이 일반적인 파일 시스템만큼 효율적이라고 생각할 수도 있지만 그 이유는 다음과 같은 두 가지 이유가 있습니다.
mount -t tmpfs "jarno is great" /mnt/jarno원하는 경우 가능합니다! 셋째, 기본 크기는 RAM의 절반입니다. 4GiB RAM이 있습니다.
자, 여기 현실이 있습니다.
tmpfs와 일반 파일 시스템은 디스크를 통한 메모리 캐시입니다.
tmpfs는 파일 시스템이 특정 디스크 영역을 사용하는 백업 저장소이므로 메모리와 스왑 공간을 사용합니다. 스왑 공간이 충분합니다.
데이터가 디스크에 기록 될 때 차이점이 있습니다. tmpfs의 경우 메모리가 가득 차거나 데이터를 곧 사용할 수 없을 때만 데이터가 기록됩니다. OTOH 대부분의 일반 Linux 파일 시스템은 디스크에 항상 일정한 데이터 세트를 갖도록 설계되었으므로 사용자가 플러그를 뽑으면 모든 것을 잃지 않습니다.
개인적으로 충돌하지 않는 운영 체제와 UPS 시스템 (예 : 랩탑 배터리)을 사용하는 데 익숙하므로 ext2 / 3 파일 시스템이 5-10 초의 체크 포인트 간격으로 편집증 적이라고 생각합니다. ext4 파일 시스템은 사용자 데이터를 두 번째 클래스로 취급하고 보호하지 않는 것을 제외하고는 10 분 체크 포인트로 더 좋습니다. (ext3은 동일하지만 5 초 검사 점으로 인해 눈치 채지 못함)
이 빈번한 검사 점은 / tmp의 경우에도 불필요한 데이터가 지속적으로 디스크에 기록됨을 의미합니다.
따라서 / tmp가 필요한만큼 (스왑 파일을 만들어야하는 경우에도) 스왑 공간을 만들고 그 공간을 사용하여 필요한 크기의 tmpfs를 / tmp에 마운트해야합니다.
/ dev / shm을 사용하지 마십시오.
그렇지 않으면 매우 작은 (아마도 mmap'd) IPC 파일에이 파일을 사용하고 있으며 파일이 존재하는지 (표준이 아님) 시스템에 충분한 메모리 + 스왑이 있는지 확인하십시오.
임시 파일에는 / tmp /를 사용하십시오. 공유 메모리 (예 : 파일을 통한 프로세스 간 통신)를 원하는 경우 / dev / shm /을 사용하십시오.
/ tmp /에 의존 할 수 있지만 / dev / shm /은 비교적 최근의 Linux 전용입니다.
1>/dev/null 2>&1. 수천 번 할 것이므로 tmpfs가 좋을 것입니다. tmpfs에 의존 할 수없는 스크립트를 출시합니다 /tmp. 일반적이지 않다는 생각이 들기 때문에 /dev/shm더 낫다면 나에게 더 좋습니다. 그러나 이식성 등에 관한 지침을 찾고 있습니다.
/ dev / shm (Linux 2.6 이상)을 사용해야하는 다른 경우 는 디스크에 쓸 수 있는지 알 수 없기 때문에 보장 된 tmpfs 파일 시스템이 필요할 때 입니다.
익숙한 모니터링 시스템은 중앙 서버에 제출할 보고서를 작성하는 동안 임시 파일을 작성해야합니다. 실제로 디스크 공간이 부족하거나 기본 RAID 오류로 인해 시스템이 하드웨어 읽기 전용 모드로 전환 된 파일 시스템에 쓰기를 방해 할 가능성이 있지만 경고 메시지를 표시 할 수 있습니다. tmpfs를 사용할 수 없도록 모든 사용 가능한 메모리를 나선형으로 만드는 것보다 (그리고 상자는 죽지 않을 것입니다). 이와 같은 경우 모니터링 시스템은 전체 디스크 또는 데드 / 다이닝 하드웨어에 대한 경고를 보낼 수 있도록 RAM에 쓰는 것을 선호합니다.
/ dev / shm은 공유 가상 메모리 시스템 특정 장치 드라이버 및 프로그램에 사용됩니다.
가상 메모리에 맵핑되어야하는 가상 메모리 힙이 필요한 프로그램을 작성하는 경우 이 프로세스는 메모리에 안전하게 액세스 할 수 있도록 여러 프로세스 나 스레드가 필요한 경우 두 배가됩니다.
사실 드라이버가 특별한 tmpfs 버전을 사용한다고해서 일반적인 tmpfs 파티션으로 사용해야한다는 의미는 아닙니다. 대신, 임시 디렉토리를 위해 다른 tmpfs 파티션을 작성해야합니다.
PERL에서 모든 시스템 (Linux Mint를 실행하는 모든 시스템)에 최소 8GB가 있으면 / dev /를 사용하여 수백만 건의 읽기 및 쓰기로 DB_File 기반 (파일의 데이터 구조) 복잡한 알고리즘을 수행하는 것이 좋습니다. m
다른 언어로, 모든 곳에서 공짜가없는 경우 일부 유형의 배치 파일을 사용하여 네트워크 전송 (클라이언트 서버 환경의 서버에있는 파일에서 로컬로 작업)의 시작과 중지를 피하기 위해 전체 (300-900MB) 파일을 한 번에 / dev / shm에 출력하고, / dev / shm에 출력하여 프로그램을 실행하고, 결과를 서버에 다시 쓰고, / dev / shm에서 삭제
당연히 RAM이 적 으면이 작업을 수행하지 않을 것입니다. 일반적으로 / dev / shm의 메모리 내 파일 시스템은 사용 가능한 RAM의 절반 크기로 읽습니다. 그러나 일반적인 RAM 사용은 일정합니다. 따라서 2GB 이하의 장치에서는 실제로이 작업을 수행 할 수 없습니다. 패러 프레이즈를 과장법으로 바꾸기 위해 종종 RAM조차도 시스템조차 제대로보고하지 않는 것들이 있습니다.
/dev/shm존재 하는지 확인 하거나 존재하는 경우 사용하거나로 대체합니다/tmp. 그거 좋은가요?