☰

파일을 캐시에 로드한 후 파일 액세스 시간

tag-icon • tag-icon cache ram
파일을 캐시에 로드한 후 파일 액세스 시간

나는에서 읽었다여기더 빠른 액세스를 위해 다음 명령을 사용하여 파일을 RAM에 로드할 수 있습니다.

cat filename > /dev/null

하지만 저는 위의 말이 사실인지 테스트해보고 싶었습니다. 그래서 다음 테스트를 해봤습니다.

  1. 아래와 같이 2.5GB 테스트 파일을 생성합니다.

    dd if=/dev/zero of=demo.txt bs=100M count=10

  2. 이제 다음과 같이 파일 액세스 시간을 계산합니다.

    mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )"
echo $mytime
real 0m19.191s user 0m0.007s sys 0m1.295s

  3. 명령에서 제안한 대로 이제 파일을 캐시 메모리에 추가해야 합니다. 그래서 나는 그랬다.

    cat demo.txt > /dev/null

  4. 이제 파일이 캐시에 로드되었다고 가정합니다. 그래서 파일을 다시 불러오는 데 걸리는 시간을 계산해봤습니다. 이것이 내가 얻는 가치입니다.

    mytime="$(time ( cat demo.txt ) 2>&1 1>/dev/null )"
echo $mytime
real 0m18.701s user 0m0.010s sys 0m1.275s

  5. 시간을 계산하기 위해 4단계를 5번 반복했는데 이것이 제가 얻은 값입니다.

    real 0m18.574s user 0m0.007s sys 0m1.279s
real 0m18.584s user 0m0.012s sys 0m1.267s
real 0m19.017s user 0m0.009s sys 0m1.268s
real 0m18.533s user 0m0.012s sys 0m1.263s
real 0m18.757s user 0m0.005s sys 0m1.274s

그래서 내 질문은 파일이 캐시에 로드될 때에도 시간이 변경되는 이유는 무엇입니까? 파일이 캐시에 로드되므로 각 반복에 대한 시간이 줄어들 것이라고 예상했지만 그렇지 않은 것 같습니다.

답변1

아니, 아니!

그런 일은 일어나지 않았습니다. Linux(커널)는 일부 파일을 캐시에 저장하고 필요할 때 삭제하도록 선택할 수 있습니다. 캐시에 아무것도 있는지 실제로 확신할 수 없습니다. 이 명령은 그 내용을 크게 변경하지 않습니다.

귀하가 제공한 링크의 조언은 여러 면에서 잘못되었습니다!

  1. 캐싱은 운영 체제에 관한 것입니다. 이 기능을 활용하는 cat데는 이 파일이 필요하지 않습니다 . /dev/nullLinux가 파일을 한 번 더 읽도록 강제하기 때문에 이것은 실제로 매우 어리석은 일입니다. 예를 들어 파일을 4번 읽으려는 경우입니다. 신경 쓰지 않으면 첫 번째 읽기는 느려지고 이후 3개의 읽기는 더 빨라집니다(캐싱으로 인해). 이 "트릭"을 사용하면 첫 번째 판독이 매우 느려집니다.4후속 항목은 더 빨라야 합니다(그러나 비어 있으면 안 됨).Linux에서 처리하도록 하세요..
  2. 이 명령은 Linux가 이를 RAM에 유지하도록 하려는 경우에만 유용합니다. 따라서 시스템이 유휴 상태일 때 자주 실행해야 합니다. 그러나 내가 말했듯이 이것은 또한 어리석은 일입니다. Linux가 실제로 파일을 RAM에 캐시하는지 확신할 수 없으며, 캐시한다고 해도 RAM이나 디스크에서 파일을 읽는 데 시간을 소비하게 되기 때문입니다(캐시하지 않는 경우). ) 캐시되었거나 이미 캐시되어 있음) 캐시에서 제거됨)
  3. 큰 파일에 대해 이 작업을 반복적으로 수행하면 기본적으로 Linux가 생성한 다른 파일을 희생하면서 파일이 RAM에 있어야 한다고 생각하도록 속이는 것입니다.실제로더 자주 사용하세요.

따라서 여기서 중요한 점은 다음과 같습니다. 이 트릭을 수행하지 마십시오. 일반적으로 비생산적입니다.

하지만, RAM 크기에 비해 일부 작은 파일이 RAM 액세스를 통해 실제로 이점을 얻을 수 있다는 것을 알고 있다면 다음을 사용할 수 있습니다.tmpfs 산거기에 파일을 저장하세요. 최신 배포판에서 /tmp폴더는 일반적 tmpfs으로 .

개인적으로 가치 있다고 생각하는 또 다른 옵션은 BTRFS를 사용하여 예를 들어 FS 수준에서 파일을 압축하거나 파일을 수동으로 압축하는 것입니다(그러나 이를 위해서는 파일에 액세스하는 프로그램에 압축을 풀 수 있는 기능이 필요합니다). 물론 파일은 압축을 통해 이점을 얻을 수 있습니다. 그렇지 않으면 이것은 쓸모가 없습니다. 이렇게 하면 Linux가 압축된 파일을 RAM(더 작기 때문에)에 보관할 것이라는 확신을 가질 수 있으며, 애플리케이션이 IO 바인딩된 경우 디스크에서 10GB 대신 100MB를 로드하는 것이 훨씬 더 빠릅니다.

답변2

테스트를 반복하고 다음 명령을 실행했습니다.

dd if=/dev/zero of=/mnt/disk8/Marc/2GB.bin bs=100M count=20

이제 대상이 HDD임에도 불구하고 파일이 얼마나 빨리 생성되는지 확인하십시오.

20+0 records in
20+0 records out
2097152000 bytes (2.1 GB, 2.0 GiB) copied, 0.6319 s, 3.3 GB/s

무슨 일이에요:

  • 파일은 디스크에 기록되지 않고 RAM에 기록됩니다. 이유: vm.dirty_ratio기본값은 20입니다. 즉, 여유 RAM의 20%를 쓰기 캐시로 사용함을 의미합니다.
  • 얼마 후 서버 대시보드를 통해 HDD의 쓰기 전송률을 확인할 수 있었습니다. 이유: vm.dirty_expire_centisecs1500으로 설정합니다(내 Unraid 서버의 기본값, Linux 기본값은 3000). 이는 HDD에 대한 쓰기가 시간에 따라 이동됨을 의미합니다.

이제 파일을 읽는 데 걸리는 시간을 측정해 보겠습니다.

mytime="$(time ( cat /mnt/disk8/Marc/2GB.bin ) 2>&1 1>/dev/null )"
echo $mytime
real 0m0.193s user 0m0.012s sys 0m0.181s

무슨 일이에요:

  • 파일이 여전히 Linux 페이지 캐시에 있습니다.

이제 캐시를 지웁니다.

sync; echo 1 > /proc/sys/vm/drop_caches

다음 벤치마크는 느립니다.

real 0m8.330s user 0m0.017s sys 0m0.753s

캐시를 다시 지우고(벤치마크가 채우는 동안) 파일을 다시 열고 콘텐츠를 휴지통으로 옮깁니다("트릭"이라고 설명함).

cat /mnt/disk8/Marc/2GB.bin > /dev/null

다음 벤치마크는 빠르고 예상대로 작동합니다.

real 0m0.233s user 0m0.008s sys 0m0.225s

그것이 당신에게 효과가 없는 이유:

  • 테스트할 때 사용 가능한 RAM이 거의 없으므로 대부분의 파일을 캐시할 수 없습니다.
  • 다른 읽기 작업이 캐시 파일을 덮어썼습니다.

결론: 충분한 메모리가 필요하며 이 "트릭"은 오래 지속되지 않습니다. 파일을 수동으로 캐싱하는 것이 전반적으로 유용합니까? 때에 따라 다르지. Plex, Emby 또는 Jellyfin과 같은 미디어 서버 소프트웨어를 사용하고 있다고 가정해 보겠습니다. 그들은 모두 고객에게 영화 표지를 제공해야 합니다. RAM에 배치하면 로딩 시간이 빨라지므로 캐시하는 것이 좋습니다. Linux는 이 작업을 자동으로 수행하고 다음 위치에 저장합니다.이벤트 목록자주 로드되는 경우. 그러나 지금 이 트릭을 사용하는 것이 좋습니다. 사용 가능한 RAM과 같거나 그보다 더 큰 파일을 요청하면 캐시가 완전히 덮어쓰여집니다. Linux는 대용량 파일을 건너뛰지 않습니다. 이제 클라이언트가 영화 표지를 다시 로드하고 활성 및 비활성 목록으로 게임을 다시 시작할 때까지 캐시 파일이 더 이상 캐시되지 않습니다. 이것이 좋은 생각인 이유는 다음과 같습니다.O_DIRECT를 사용하여 대용량 파일 요청또는 이 트릭을 사용하는 대신가상 터치캐시에 잠그십시오.

관련 정보