파일 시스템 캐싱에 있어 Linux 시스템을 보다 적극적으로 구성할 수 있습니까?

일반적으로 디스크 캐시 성능을 향상하려면 파일 시스템 캐시 크기를 늘리는 것 이상이 필요합니다.모두시스템은 RAM에 적합합니다. 이 경우 RAM 드라이브( tmpfs경우에 따라 RAM이 필요한 경우 디스크로 대체할 수 있기 때문에 좋습니다)를 런타임 저장소(및 시스템을 저장소에서 다른 저장소로 복사하는 initrd 스크립트일 수도 있음)로 사용해야 합니다. 부팅 시 RAM 드라이브)).

저장 장치가 SSD인지 HDD인지 알려주지 않았습니다. 제가 찾은 방법은 다음과 같습니다(제 경우에는 sdaHDD가 에 마운트되고 /homeSSD sdb가 에 마운트되었습니다 /).

먼저 스토리지에서 캐시로 콘텐츠를 로드하는 부분을 최적화합니다.

내 HDD 설정은 다음과 같습니다(전환된 경우 BIOS에서 AHCI+NCQ가 활성화되어 있는지 확인하세요).

    echo cfq > /sys/block/sda/queue/scheduler
    echo 10000 > /sys/block/sda/queue/iosched/fifo_expire_async
    echo 250 > /sys/block/sda/queue/iosched/fifo_expire_sync
    echo 80 > /sys/block/sda/queue/iosched/slice_async
    echo 1 > /sys/block/sda/queue/iosched/low_latency
    echo 6 > /sys/block/sda/queue/iosched/quantum
    echo 5 > /sys/block/sda/queue/iosched/slice_async_rq
    echo 3 > /sys/block/sda/queue/iosched/slice_idle
    echo 100 > /sys/block/sda/queue/iosched/slice_sync
    hdparm -q -M 254 /dev/sda

단일 프로세스가 높은 처리량을 얻을 수 있도록 HDD 케이스가 높음 fifo_expire_async(일반적으로 쓰기) 및 길게 설정되어 있다는 점은 주목할 가치가 있습니다( 또는 여러 프로세스가 디스크 번호의 일부 데이터를 병렬로 기다리는 상황이 발생하는 경우 더 낮음). . 이는 항상 HDD와의 절충안이지만 디스크 사용량 및 디스크 펌웨어에 따라 3~20 범위로 설정하는 것이 좋습니다. 저는 더 낮은 값을 목표로 삼는 것을 선호하지만, 너무 낮게 설정하면 처리량이 파괴됩니다. 이 설정은 처리량에 큰 영향을 미치는 것으로 보이지만 대기 시간을 합리적인 수준으로 유지하려면 가능한 한 낮게 유지하십시오. 너무 낮게 설정하면 처리량이 파괴됩니다. 3~8 범위의 값이 HDD에 적합한 것 같습니다. 커널 동작을 올바르게 이해한다면 최악의 읽기 대기 시간은 ( * ) + ( *) 밀리초입니다. 비동기는 주로 쓰기용이며 디스크에 쓰기를 지연시키려면 및 둘 다 매우 낮은 숫자 로 설정하십시오. 그러나 값을 너무 낮게 설정하면 읽기 후 쓰기가 더 이상 지연되지 않으므로 읽기가 불가능할 수 있습니다. 내 구성에서는 데이터가 커널에 전달된 후 최대 10초 동안 디스크에 데이터를 쓰려고 시도하지만 정전 시 데이터 손실을 허용할 수 있으므로 디스크에 1이 발생했음을 알리 도록 설정되어 있습니다. 한 시간 지연은 괜찮습니다. 그러나 값을 낮게 유지하십시오. 그렇지 않으면 읽기 대기 시간이 길어질 수 있습니다.slice_syncslice_syncslice_idlequantumquantumquantumslice_syncslice_async_rqslice_asyncslice_async_rqslice_asyncslice_async_rqfifo_expire_async3600000slice_async

이 hdparm명령은 AAM이 AHCI+NCQ에서 허용하는 대부분의 성능을 파괴하는 것을 방지하는 데 필요합니다. 디스크에 소음이 너무 많으면 이 단계를 건너뛰세요.

내 SSD(Intel 320 시리즈) 설정은 다음과 같습니다.

    echo cfq > /sys/block/sdb/queue/scheduler
    echo 1 > /sys/block/sdb/queue/iosched/back_seek_penalty
    echo 10000 > /sys/block/sdb/queue/iosched/fifo_expire_async
    echo 20 > /sys/block/sdb/queue/iosched/fifo_expire_sync
    echo 1 > /sys/block/sdb/queue/iosched/low_latency
    echo 6 > /sys/block/sdb/queue/iosched/quantum
    echo 2 > /sys/block/sdb/queue/iosched/slice_async
    echo 10 > /sys/block/sdb/queue/iosched/slice_async_rq
    echo 1 > /sys/block/sdb/queue/iosched/slice_idle
    echo 20 > /sys/block/sdb/queue/iosched/slice_sync

여기서 주목할만한 점은 다양한 슬라이싱 설정에 대한 낮은 값입니다. SSD의 가장 중요한 설정은 slice_idle0-1로 설정되어야 합니다. 0으로 설정하면 모든 순서 결정이 기본 NCQ로 이동하고, 1로 설정하면 커널이 요청 순서를 지정할 수 있습니다(그러나 NCQ가 활성화된 경우 하드웨어는 부분적으로 커널 순서를 무시할 수 있습니다). 두 값을 모두 테스트하고 차이가 있는지 확인하세요. Intel 320 시리즈의 경우 최고의 처리량을 제공 slide_idle하도록 설정되어 있는 것으로 보이지만 전체 지연 시간이 가장 좋은(최저) 0설정은 아닙니다 . 1충분히 새로운 커널이 있는 경우 slide_idle_us밀리초 대신 마이크로초 단위로 값을 설정할 수 있으며 echo 14 > slice_idle_us대신 비슷한 것을 사용할 수 있습니다. 좋은 값은 저장 장치가 지원할 수 있는 최대 실제 IOPS로 나눈 700000에 가까운 것으로 보이므로 합리적으로 빠른 SSD 장치의 경우 14가 괜찮을 것입니다.

이러한 조정 가능 매개변수에 대한 자세한 내용은 다음을 참조하세요.https://www.kernel.org/doc/Documentation/block/cfq-iosched.txt.

업데이트 2020, 커널 버전 5.3(cfq는 더 이상 사용할 수 없음):

#!/bin/bash
modprobe bfq
for d in /sys/block/sd?; do
  # HDD (tuned for Seagate SMR drive)
  echo bfq >"$d/queue/scheduler"
  echo 4 >"$d/queue/nr_requests"
  echo 32000 >"$d/queue/iosched/back_seek_max"
  echo 3 >"$d/queue/iosched/back_seek_penalty"
  echo 80 >"$d/queue/iosched/fifo_expire_sync"
  echo 1000 >"$d/queue/iosched/fifo_expire_async"
  echo 5300 >"$d/queue/iosched/slice_idle_us"
  echo 1 >"$d/queue/iosched/low_latency"
  echo 200 >"$d/queue/iosched/timeout_sync"
  echo 0 >"$d/queue/iosched/max_budget"
  echo 1 >"$d/queue/iosched/strict_guarantees"

  # additional tweaks for SSD (tuned for Samsung EVO 850):
  if test $(cat "$d/queue/rotational") = "0"; then
    echo 36 >"$d/queue/nr_requests"
    echo 1 >"$d/queue/iosched/back_seek_penalty"
    # slice_idle_us should be ~ 0.7/IOPS in µs
    echo 16 >"$d/queue/iosched/slice_idle_us"
    echo 10 >"$d/queue/iosched/fifo_expire_sync"
    echo 250 >"$d/queue/iosched/fifo_expire_async"
    echo 10 >"$d/queue/iosched/timeout_sync"
    echo 0 >"$d/queue/iosched/strict_guarantees"
  fi
done

설정은 매우 유사하지만 후자가 최신 커널에서 작동하지 않기 때문에 지금 bfq은 대신 사용하고 있습니다. 나는 일정을 보다 정확하게 제어하기 위해 가능한 한 낮게 cfq유지하려고 노력합니다 . 적어도 삼성 SSD 드라이브는 높은 IOPS에서 실행하려면 상당히 깊은 대기열이 필요한 것 같습니다.nr_requestsbfq고쳐 쓰다:nr_requests많은 삼성 SSD에는 펌웨어 버그가 있어 펌웨어 버그가 너무 높아서 운영 체제가 많은 수의 요청을 신속하게 제출하는 경우 전체 장치가 중단될 수 있습니다. 높은 값(예: 32 또는 36)을 사용하면 약 2개월마다 무작위로 동결되는 것을 볼 수 있지만 지금까지는 nr_requests값이 안정적이었습니다. 6공식적인 수정은 으로 설정하는 것이지만, 1이는 성능에 큰 영향을 미칩니다! 자세한 내용은 다음을 참조하세요.https://bugzilla.kernel.org/show_bug.cgi?id=203475그리고https://bugzilla.kernel.org/show_bug.cgi?id=201693– 기본적으로 삼성 SSD 장치를 사용하고 있고 failed command: WRITE FPDMA QUEUED커널 로그에 이 내용이 표시된다면 이미 이 오류가 발생하고 있는 것입니다.

linux-lowlatency-hwe-18.04-edge모듈 로만 제공되는 커널 패키지와 함께 Ubuntu 18.04를 사용하고 있으므로 bfq전환하기 전에 이를 로드해야 합니다.

저도 지금 zram을 사용하고 있지만 zramRAM의 5%만 사용하고 있습니다. 이를 통해 Linux 커널은 디스크를 건드리지 않고도 스왑 관련 논리를 사용할 수 있습니다. 그러나 디스크 스왑을 사용하지 않기로 결정한 경우 애플리케이션에서 RAM이 누출되지 않는지 확인하세요. 그렇지 않으면 돈을 낭비하게 됩니다.

이제 적절한 성능으로 디스크의 콘텐츠를 캐시로 로드하도록 커널을 구성했으므로 이제 캐시 동작을 조정할 차례입니다.

내가 수행한 벤치마크에 따르면 사전 읽기 설정을 전혀 신경 쓰지 않을 것입니다 blockdev. 커널 기본 설정은 괜찮습니다.

애플리케이션 코드보다 스왑 파일 데이터를 선호하도록 시스템을 설정합니다. (데이터를 저장할 RAM이 충분한지는 중요하지 않습니다.)모두파일 시스템그리고모든 애플리케이션 코드그리고애플리케이션이 RAM에 할당한 모든 가상 메모리입니다. 이렇게 하면 단일 애플리케이션에서 대용량 파일에 액세스하는 데 걸리는 대기 시간이 아니라 여러 애플리케이션 간의 교환 대기 시간이 줄어듭니다.

echo 15 > /proc/sys/vm/swappiness

애플리케이션을 거의 항상 RAM에 유지하려면 이 값을 1로 설정할 수 있습니다. 0으로 설정하면 OOM을 피하기 위해 꼭 필요한 경우가 아니면 커널은 전혀 스왑하지 않습니다. 메모리가 제한되어 있고 대용량 파일(예: HD 비디오 편집)로 작업해야 하는 경우 100에 가깝게 설정하는 것이 합리적일 수 있습니다.

RAM이 충분하다면 지금(2017)은 스왑을 전혀 사용하지 않는 것을 선호합니다. 장기간 실행되는 데스크탑에서는 교체하지 않으면 일반적으로 200-1000MB의 RAM이 손실됩니다. 최악의 대기 시간(RAM이 가득 찼을 때 애플리케이션 코드 교체)을 피하기 위해 그 정도를 희생할 의향이 있습니다. 실질적으로 말하자면 이는 Swap보다 OOM Killer를 선호한다는 의미입니다. 스왑을 허용/요구하는 경우 /proc/sys/vm/watermark_scale_factor지연을 피하기 위해 스왑을 늘리는 것이 좋습니다 . 100에서 500 사이의 값을 사용하는 것이 좋습니다. 이 설정은 더 낮은 전환 대기 시간을 위해 CPU 사용량을 교환하는 것으로 생각할 수 있습니다. 기본값은 10이고, 가능한 최대값은 1000입니다. 더 높은 값은 (에 따라)커널 문서) kswapd프로세스의 CPU 사용량이 늘어나고 전체 전환 대기 시간이 낮아집니다.

다음으로, 일부 RAM을 비워야 할 경우를 대비해 파일 내용과 페이지 캐시의 나머지 부분보다 메모리의 디렉터리 계층 구조를 유지하는 데 우선 순위를 두도록 커널에 지시합니다(다시 말하지만, 모든 것이 RAM에 맞는 경우 이 설정은 아무 작업도 수행하지 않습니다).

echo 10 > /proc/sys/vm/vfs_cache_pressure

vfs_cache_pressure대부분의 경우 커널은 캐시의 파일 내용을 사용하기 전에 디렉터리 구조와 기타 파일 시스템 메타데이터를 알아야 하고, 디렉터리 캐시를 너무 일찍 플러시하면 파일 캐시가 거의 쓸모 없게 되기 때문에 더 낮은 값으로 설정하는 것이 좋습니다. . 그러나 페이지 캐시에는 다른 데이터도 포함되어 있지만 파일 콘텐츠만 포함되어 있으므로 이 설정은 시스템의 나머지 부분에 대한 메타데이터 캐시의 전체적인 중요성만큼 중요하게 간주되어야 합니다. 작은 파일이 많은 경우(내 시스템에는 약 150,000장의 10메가픽셀 사진이 있으며 이는 "작은 파일이 많은" 시스템으로 간주됨) 이 설정을 1로 낮추는 것이 좋습니다. 0으로 설정하지 마십시오. 그렇지 않으면 시스템 메모리가 부족하더라도 디렉토리 구조가 항상 메모리에 남아 있습니다. 지속적으로 다시 읽어야 하는 대용량 파일이 몇 개만 있는 경우에만 이 값을 더 큰 값으로 설정하십시오(충분한 RAM이 없는 HD 비디오 편집이 그 예입니다). 공식 커널 문서에는 "vfs_cache_Pressure를 100 이상으로 크게 높이면 성능에 부정적인 영향을 미칠 수 있습니다"라고 명시되어 있습니다.

2021년 업데이트:vfs_cache_pressure커널 버전 5.4를 충분히 오랫동안 실행한 후, 매우 낮은 설정(수년 동안 실행 1)으로 인해 이제 긴 일시 중지/나쁜 지연이 발생할 수 있다는 결론에 도달했습니다.메모리 압력이 충분히 높은 경우. 그러나 커널 버전 5.3 이하에서는 이러한 동작을 본 적이 없습니다.

2022년 업데이트:나는 1년 동안 커널 5.4.x 시리즈를 사용해 왔고, 내가 내린 결론은 vfs_cache_presure영구적으로 바뀌었습니다. 커널 버전 5.3 이하(1..5 범위의 값)를 사용하여 얻은 커널 메모리 관리자 동작은 실제 동작(100..120 범위의 값을 가진 5.4)과 일치하는 것 같습니다. 최신 커널에서는 이 조정이 더욱 중요하므로 vfs_cache_presure=120전반적인 낮은 대기 시간을 위해 지금 이 값을 사용하는 것이 좋습니다. 제 생각에는 커널 버전 5.3 이하에서는 매우 낮지만 0이 아닌 값을 사용해야 합니다.

예외:파일과 디렉터리가 많고 모두 터치/읽기/나열하는 경우가 거의 없다면 vfs_cache_pressure100보다 높게 설정하는 것이 좋습니다. 이는 RAM이 충분하지 않고 전체 디렉터리 구조를 RAM에 유지할 수 없지만 여전히 일반 파일 캐싱 및 프로세스에 충분한 RAM이 있는 경우에만 적용됩니다(예: 보관된 콘텐츠가 많은 회사 전체 파일 서버). . 100 이상으로 늘려야 한다고 생각되면 vfs_cache_pressureRAM이 부족한 것입니다. 더 많은 메모리가 vfs_cache_pressure도움이 될 수 있지만 유일한 실제 해결책은 더 많은 메모리를 확보하는 것입니다. 높은 숫자로 설정하면 vfs_cache_pressure전체 성능이 더욱 안정적으로 유지되기 위해 평균 성능이 희생됩니다. 즉, 매우 나쁜 최악의 동작은 피하지만 전체 성능이 더 나빠지는 경우를 처리해야 합니다.

마지막으로 커널에 최대 99%의 RAM을 쓰기 캐시로 사용하도록 지시하고 쓰기 프로세스 속도를 늦추기 전에 커널에 최대 50%의 RAM을 사용하도록 지시합니다(기본값은 dirty_background_ratio) 10.경고: 저는 개인적으로 이렇게 하지 않을 것입니다. 그러나 귀하는 RAM이 충분하고 데이터를 잃을 의향이 있다고 주장합니다.

echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio

그리고 1시간 쓰기 지연이 괜찮다고 하더군요시작디스크에 무언가 쓰기(다시 말하지만, 나는 이것을 하지 않을 것입니다):

echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs

이러한 조정 가능 매개변수에 대한 자세한 내용은 다음을 참조하세요.https://www.kernel.org/doc/Documentation/sysctl/vm.txt

이 모든 것을 /etc/rc.local끝에 넣고 다음을 포함하면 부팅 후 가능한 한 빨리 모든 것이 캐시에 저장됩니다(파일 시스템이 실제로 RAM에 적합한 경우에만 이 작업을 수행하십시오).

(nice find / -type f -and -not -path '/sys/*' -and -not -path '/proc/*' -print0 2>/dev/null | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

또는 더 잘 작동할 수 있는 더 간단한 대안(합계를 캐시하기만 하면 됩니다. /home합 이 실제로 RAM에 맞는 /usr경우에만 이 작업을 수행하십시오 ):/home/usr

(nice find /home /usr -type f -print0 | nice ionice -c 3 wc -l --files0-from - > /dev/null)&

우선, Linux에서 ntfs를 구현하면 항상 성능 및 보안 문제가 발생하기 때문에 NTFS를 계속 사용하지 않는 것이 좋습니다.

수행할 수 있는 작업은 여러 가지가 있습니다.

• ext4또는 같은 최신 파일 시스템을 사용하십시오.btrfs
• 예를 들어 io 스케줄러를 변경해 보세요.bfq
• 가까운 교환
• 다음과 같은 자동 프리로더를 사용하세요.preload
• systemd시작 시 미리 로드하는 것과 같은 것을 사용하십시오 .
• ...더있다

어쩌면 당신은 그것을 시도하고 싶을 것입니다 :-)

계속 읽으세요:

32비트 시스템의 경우:

blockdev --setra 8388607 /dev/sda

64비트 시스템의 경우:

blockdev --setra 4294967295 /dev/sda

캐시 뒤에 쓰기:

echo 90 > /proc/sys/vm/dirty_ratio # too high rates can cause crash

이렇게 하면 사용 가능한 메모리의 최대 90%가 쓰기 캐시로 사용됩니다.

아니면 전력을 다해 tmpfs를 사용할 수도 있습니다. 이는 RAM이 충분한 경우에만 의미가 있습니다. 이것을 에 넣으세요 /etc/fstab. 50%를 원하는 금액으로 대체하세요. 이는 항상 전체 RAM의 백분율입니다. 또한 8G는 8GB, 3M은 3MB에 해당합니다.

tmpfs /mnt/tmpfs tmpfs size=50%,rw,nosuid,nodev 0 0 # you can do that with more things, as the /tmp folder. The 50% can be replaced with 4G, 5G... 50% is the half of the whole ram. Also higher values work because it will go into swap

그 다음에:

mkdir /mnt/tmpfs; mount -a

그런 다음 /mnt/tmpfs를 사용하십시오.

쓰기 캐싱과 관련이 없지만 쓰기와 관련이 있습니다.

• ext4 시스템의 경우 다음을 수행할 수 있습니다.저널링을 완전히 비활성화합니다.

  이렇게 하면 특정 업데이트에 대한 디스크 쓰기 횟수가 줄어들지만 예기치 않은 종료 후 파일 시스템이 일관되지 않은 상태가 되어 fsck 이상이 필요할 수 있습니다.

디스크 읽기가 디스크 쓰기를 트리거하지 않도록 하려면 다음을 수행하세요.

• 설치 및관계 시간또는노아템옵션

  파일을 읽으면 일반적으로 파일의 "마지막으로 액세스한" 메타데이터가 업데이트됩니다. 이 noatime옵션은 이 동작을 비활성화합니다. 이렇게 하면 불필요한 디스크 쓰기가 줄어들지만 더 이상 해당 메타데이터가 없습니다. 일부 배포판(예: Manjaro)에서는 이를 모든 파티션의 기본값으로 설정했습니다(아마도 이전 모델 SSD의 수명을 연장하기 위해).

  relatimeatime을 사용하는 애플리케이션을 지원하는 데 도움이 되는 경험적 방법을 기반으로 액세스 시간이 덜 자주 업데이트됩니다. 이는 Red Hat Enterprise Linux의 기본 설정입니다.

다른 옵션:

• 위 댓글에서 Mikko는 설치 가능성을 공유했습니다.접근성옵션. 댄 이바일로견적RedHat누가 이에 대해 경고했습니까? 그 추가 3%를 얼마나 간절히 원하시나요?