보다 적극적인 파일 시스템 캐싱을 위해 Linux 시스템을 구성 할 수 있습니까? 파일을 적극적으로 프리 페치하기 위해 시스템을

나는 RAM 사용 (충분한)이나 실수로 종료 된 경우 (내 전원이 백업되고 시스템이 안정적이며 데이터가 중요하지 않은) 데이터 손실에 대해 걱정하지 않습니다. 그러나 나는 많은 파일 처리를 수행하고 약간의 성능 향상을 사용할 수 있습니다.

그렇기 때문에 파일 시스템 읽기 및 쓰기 캐싱에 더 많은 RAM을 사용하고 파일을 적극적으로 프리 페치하기 위해 시스템을 설정하려고합니다 (예 : 파일 크기가 정상이거나 최소 인 경우 애플리케이션이 액세스 한 전체 파일을 미리 읽기 그렇지 않으면 큰 덩어리를 미리 읽고 쓰기 버퍼를 덜 자주 플러시합니다. 이것을 달성하는 방법 (가능할 수도 있음)?

XUbuntu 11.10 x86과 함께 ext3 및 ntfs (ntfs를 많이 사용합니다!) 파일 시스템을 사용합니다.



답변

일반적으로 디스크 캐시 성능을 개선하면 않는 한 단지 파일 시스템 캐시 크기를 증가보다 더 전체 시스템이이 RAM 드라이브를 사용해야하는 경우 RAM에 맞는 ( tmpfs이 디스크에 다시 떨어지는 허용하기 때문에 당신이 어떤 경우에 RAM이 필요하면 좋다) 런타임 스토리지 (및 시작시 스토리지에서 RAM 드라이브로 시스템을 복사하는 initrd 스크립트)

저장 장치가 SSD인지 HDD인지 알 수 없습니다. 여기 내가 나를 위해 일한 것으로 나타났습니다 (제 경우 sda에는 HDD가 마운트되어 /home있고 sdbSSD는 SSD가 마운트되어 있습니다 /).

먼저 스토리지에서 캐시로로드 부분을 최적화하십시오.

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(보통 쓰기) slice_sync단일 프로세스가 높은 처리량을 얻을 수 있도록하는 것입니다 ( slice_sync여러 프로세스가 디스크에서 일부 데이터를 병렬로 기다리는 상황에 부딪 치면 더 낮은 수로 설정 됨). slice_idleHDD 의 경우 항상 타협이지만 디스크 사용 및 디스크 펌웨어에 따라 3-20 범위로 설정하는 것이 좋습니다. 낮은 값을 목표로 설정하지만 너무 낮게 설정하면 처리량이 파괴됩니다. 이 quantum설정은 처리량에 많은 영향을 미치는 것처럼 보이지만 가능한 한 낮은 수준으로 유지하여 대기 시간을 합리적인 수준으로 유지하십시오. quantum너무 낮게 설정하면 처리량이 파괴됩니다. 3-8 범위의 값은 HDD에서 잘 작동하는 것 같습니다. 읽기에 대한 최악의 대기 시간은 ( quantum* slice_sync) + ( slice_async_rq*slice_async) ms 커널 동작을 올바르게 이해했다면. 비동기 주로 쓰기에 사용하고 디스크에 쓰기를 지연 기꺼이 때문에 모두 설정 slice_async_rqslice_async매우 낮은 번호를. 그러나 slice_async_rq너무 낮은 값을 설정 하면 더 이상 읽기 후에 쓰기를 지연시킬 수 없으므로 읽기가 중단 될 수 있습니다. 당신은 또한 설정 전력 손실 데이터의 손실을 견딜 수 있기 때문에 내 설정 데이터가 커널에 전달 된 후 10 초 후에 대부분에서 디스크에 데이터를 기록하려고 하겠지만 fifo_expire_async위해 36000001 시간 디스크에 지연 괜찮 말을. slice_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_idle0제공하도록 설정하는 것이 좋지만 1전체적으로 가장 짧은 대기 시간 을 제공하도록 설정하는 것 같습니다 .

이러한 튜너 블에 대한 자세한 내용은 http://www.linux-mag.com/id/7572/를 참조 하십시오 .

합리적인 성능으로 디스크에서 캐시로 물건을로드하도록 커널을 구성 했으므로 이제 캐시 동작을 조정해야합니다.

내가 한 벤치 마크에 따르면, 나는 미리 읽은 설정을 귀찮게하지 않을 것 blockdev입니다. 커널 기본 설정은 괜찮습니다.

시스템이 응용 프로그램 코드보다 파일 데이터 교환을 선호하도록 설정합니다 ( 전체 파일 시스템 모든 응용 프로그램 코드 RAM에있는 응용 프로그램에 의해 할당 된 모든 가상 메모리 를 유지하기에 충분한 RAM이 있는지는 중요하지 않습니다 ). 이렇게하면 단일 응용 프로그램에서 큰 파일에 액세스하기위한 대기 시간에 비해 다른 응용 프로그램 간 교체 대기 시간이 줄어 듭니다.

echo 15 > /proc/sys/vm/swappiness

응용 프로그램을 거의 항상 RAM에 유지하려면 이것을 1로 설정할 수 있습니다.이 값을 0으로 설정하면 OOM을 피하기 위해 절대적으로 필요한 경우가 아니면 커널이 전혀 바뀌지 않습니다. 메모리가 제한되어 있고 큰 파일 (예 : HD 비디오 편집)을 사용하는 경우이를 100에 가깝게 설정하는 것이 좋습니다.

요즘 (2017)에는 충분한 RAM이 있으면 스왑이 전혀없는 것을 선호합니다. 스왑이 없으면 오래 실행되는 데스크톱 컴퓨터에서 일반적으로 200-1000MB의 RAM이 손실됩니다. 최악의 시나리오 대기 시간 (RAM이 가득 찼을 때 응용 프로그램 코드 스왑)을 피하기 위해 많은 것을 기꺼이 희생합니다. 실제로 이것은 OOM Killer를 스와핑하는 것을 선호합니다. 스와핑을 허용 / 필요한 경우 /proc/sys/vm/watermark_scale_factor약간의 대기 시간을 피하기 위해을 늘릴 수도 있습니다 . 100과 500 사이의 값을 제안합니다.이 설정은 스왑 대기 시간을 줄이기 위해 CPU 사용량을 거래하는 것으로 간주 할 수 있습니다. 기본값은 10이고 가능한 최대 값은 1000입니다. 커널 문서 에 따라 값이 높을수록 kswapd프로세스의 CPU 사용량이 높아지고 전체 스와핑 대기 시간이 줄어 듭니다.

다음으로, 일부 RAM을 해제해야 할 경우를 대비하여 파일 컨텐츠보다 디렉토리 계층 구조를 메모리에 유지하도록 커널에 지시하십시오.

echo 10 > /proc/sys/vm/vfs_cache_pressure

환경 vfs_cache_pressure대부분의 경우 커널은 캐시에서 파일 내용을 사용하기 전에 디렉토리 구조를 알아야하고 디렉토리 캐시를 너무 빨리 플러시하면 파일 캐시가 무가치하게됩니다. 작은 파일이 많은 경우이 설정을 사용하여 1로 줄이십시오 (시스템에는 약 150K 10 메가 픽셀 사진이 있으며 “많은 작은 파일”시스템으로 계산 됨). 시스템에 메모리가 부족하더라도 디렉토리 구조를 항상 메모리에 유지하거나 0으로 설정하지 마십시오. 이 값을 큰 값으로 설정하면 지속적으로 다시 읽는 큰 파일이 몇 개만있는 경우에만 의미가 있습니다 (다수의 RAM이없는 HD 비디오 편집이 좋은 예입니다). 공식 커널 문서는 “

예외 : 파일과 디렉토리의 양이 vfs_cache_pressure많고 거의 터치 / 읽기 / 목록이 거의없는 경우 100보다 높은 모든 파일 설정 이 현명 할 수 있습니다. 이는 충분한 RAM이없고 RAM에 전체 디렉토리 구조를 유지할 수없고 일반 파일 캐시 및 프로세스 (예 : 많은 아카이브 컨텐츠가있는 회사 전체 파일 서버)에 충분한 RAM을 보유 할 수없는 경우에만 적용됩니다. vfs_cache_pressure100 이상 으로 늘려야한다고 생각되면 충분한 RAM없이 실행 중입니다. 증가 vfs_cache_pressure하면 도움이 될 수 있지만 실제 수정 사항은 더 많은 RAM을 얻는 것입니다. 데 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

모든 것을 넣고 /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/usr, 경우에만 이렇게 당신 /home/usrRAM에 정말 적합)

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


답변

첫째, Linux에서 ntfs를 구현하면 언제든지 성능 및 보안 문제가 발생하므로 NTFS를 계속 사용하지 않는 것이 좋습니다.

당신이 할 수있는 몇 가지가 있습니다 :

  • ext4또는 같은 새로운 fs를 사용하십시오btrfs
  • 예를 들어 io 스케줄러를 변경하십시오. bfq
  • 스왑을 해제
  • 다음과 같은 자동 프리 로더를 사용하십시오 preload
  • systemd부팅하는 동안 미리로드하는 것과 같은 것을 사용 하십시오.
  • … 그리고 더 많은 것

어쩌면 시도해보고 싶을 수도 있습니다 🙂


답변

미리 읽기 :

32 비트 시스템에서 :

blockdev --setra 8388607 /dev/sda

64 비트 시스템에서 :

blockdev --setra 4294967295 /dev/sda

캐시 뒤에 쓰기 :

echo 100 > /proc/sys/vm/dirty_ratio

이것은 사용 가능한 메모리의 최대 100 %를 쓰기 캐시로 사용합니다.

또는 tmpfs를 모두 사용할 수 있습니다. RAM이 충분한 경우에만 관련이 있습니다. 에 넣으십시오 /etc/fstab. 100G를 실제 RAM의 양으로 교체하십시오.

tmpfs /mnt/tmpfs tmpfs size=100G,rw,nosuid,nodev 0 0

그때:

mkdir /mnt/tmpfs; mount -a

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


답변

다음과 같이 미리 읽기 크기를 설정할 수 있습니다 blockdev --setra sectors /dev/sda1. 여기서 sectors는 512 바이트 섹터에서 원하는 크기입니다.


답변

킬러 설정은 매우 간단하고 효과적입니다.

echo "2000" > /proc/sys/vm/vfs_cache_pressure

커널 문서 의 설명 :

vfs_cache_pressure

커널이 디렉토리 및 inode 객체를 캐싱하는 데 사용되는 메모리를 회수하는 경향을 제어합니다.

vfs_cache_pressure = 100의 기본값에서 커널은 pagecache 및 swapcache 재생과 관련하여 “공정한”속도로 덴 트리 및 inode를 재생하려고 시도합니다. vfs_cache_pressure를 줄이면 커널은 dentry 및 inode 캐시를 유지하는 것을 선호합니다. vfs_cache_pressure = 0이면 커널은 메모리 부족으로 인해 덴 트리와 아이 노드를 회수하지 않으므로 메모리 부족 상태로 쉽게 이어질 수 있습니다. vfs_cache_pressure를 100 이상으로 늘리면 커널이 덴 트리와 아이 노드를 재생하는 것을 선호합니다.

vfs_cache_pressure 2000에서 대부분의 컴퓨팅은 RAM에서 발생하고 디스크 쓰기는 매우 늦습니다.


답변

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

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

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

디스크 읽기를 트리거하여 디스크 읽기를 중지하려면 다음을 수행하십시오.

  • relatime 또는 noatime 옵션으로 마운트

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

    relatime한 번에 사용하는 응용 프로그램을 지원하는 휴리스틱에 따르면 액세스 시간이 덜 자주 업데이트됩니다. 이것이 Red Hat Enterprise Linux의 기본값입니다.

다른 옵션:

  • 위의 의견에서 Mikko는 nobarrier 옵션 으로 장착 가능성을 공유했습니다 . 그러나 Ivailo 는 이에 대해주의를 기울이는 RedHat인용 했습니다. 그 여분의 3 %를 얼마나 심하게 원하십니까?

답변