파일 시스템 집약적인 스크립트가 RAM 디스크에서 빠르지 않은 이유

파일 시스템 집약적인 스크립트가 RAM 디스크에서 빠르지 않은 이유

많은 파일과 디렉토리를 생성하는 스크립트가 있습니다. 이 스크립트는 많은 수의 파일과 디렉터리를 처리하는 프로그램의 블랙박스 테스트를 수행합니다. 테스트 횟수가 늘어나고 테스트 시간이 너무 깁니다(2초 이상). 램디스크에서 테스트를 실행하고 있다고 생각했습니다.

에서 테스트를 진행했습니다 /dev/shm. 이상한 점은 더 빨리 실행되지 않는다는 것입니다. 평균 실행 시간은 일반 하드 드라이브와 거의 같습니다. 나도 시도했다Perl로 작성된 퓨즈 기반 RAM 디스크. 사이트는 없어졌는데 난 남아있네인터넷 아카이브. Fuse RAM 디스크의 평균 런타임은 훨씬 더 느립니다. 어쩌면 Perl 코드의 구현이 이상적이지 않기 때문일 수도 있습니다.

내 스크립트의 단순화된 버전은 다음과 같습니다.

#! /bin/sh

preparedir() {
  mkdir foo
  mkdir bar
  touch bar/file
  mkdir bar/baz
  echo qux > bar/baz/file
}

systemundertest() {
  # here is the black box program that i am testing
  # i do not know what it does exactly
  # but it must be reading the files
  # since it behaves differently based on them
  find $1 -type f -execdir cat '{}' \; > /dev/null

singletest() {
  mkdir actual
  (cd actual; preparedir)
  systemundertest actual
  mkdir expected
  (cd expected; preparedir)
  diff -qr actual expected
}

manytests() {
  while read dirname; do
    rm -rf $dirname
    mkdir $dirname
    (cd $dirname; singletest)
  done
}

seq 100 | manytests

실제 스크립트는 더 많은 오류 검사, 결과 수집 및 요약을 수행합니다. 이것은 find제가 테스트하고 있는 실제 프로그램에 대한 더미 프로그램입니다.

내 파일 시스템 집약적 스크립트가 메모리 지원 파일 시스템에서 왜 그렇게 빠르게 실행되지 않는지 궁금합니다. Linux 커널이 파일 시스템 캐시를 매우 효율적으로 처리하여 실제로는 메모리 기반 파일 시스템이기 때문일까요?

답변1

일반적으로 모든 작업은 RAM에서 먼저 발생합니다. 즉, 파일 시스템이 캐시됩니다. 이 규칙에는 예외가 있지만 이러한 다소 특별한 상황은 일반적으로 매우 구체적인 요구 사항에서 비롯됩니다. 따라서 캐시 플러시를 시작할 때까지 차이점을 알 수 없습니다.

또 다른 것은 성능이 다음에 달려 있다는 것입니다.많은정확한 파일 시스템에서 - 일부 목표는 다수의 작은 파일에 대한 보다 쉬운 액세스이고, 일부는 대용량 파일의 효율적인 실시간 데이터 전송(멀티미디어 캡처/스트리밍)이며, 일부는 데이터 일관성을 강조하고, 일부는 설계 가능합니다. 작은 메모리를 가집니다. /코드 발자국.

사용 사례로 돌아가서: 루프에서 약 20개의 새로운 프로세스를 생성하며, 대부분은 단일 디렉터리/파일만 생성합니다( ()하위 쉘은 일치할 때마다 생성되고 find생성됩니다 cat). 병목 현상은 실제로 파일 시스템이 아닙니다. 귀하의 시스템이 사용하는ASLR그리고 빠른 엔트로피 소스가 없기 때문에 시스템의 임의성 풀도 매우 빠르게 고갈됩니다. Perl로 작성된 FUSE도 마찬가지입니다. 이는 작업에 적합한 도구가 아닙니다.

답변2

주로 소규모 거래로 구성된 테스트에 대한 내 의견보다 약간 긴 답변입니다.

테스트할 작업이 충분하지 않습니다.

파일 시스템을 스트레스 테스트하려면 더 큰 작업 세트가 필요합니다.

상자에 얼마나 많은 메모리가 있는지에 따라 수십 또는 수천 번의 폴더 생성 작업이라도 눈에 띄는 차이를 나타내지 않습니다. 따라서 버퍼로 사용될 메모리를 고려하여 파일 시스템을 완전히 테스트하도록 워크로드를 수정하십시오.

시스템 메모리의 장점과 테스트 결과에 영향을 미칠 수 있는 기타 요소를 상쇄하기 위해 테스트를 설계하는 방법에는 여러 가지가 있습니다.

또는 bonnie++와 같은 표준화된 테스트 도구 모음을 사용할 수 있습니다.

관련 정보