보다 적극적인 파일 시스템 캐싱을 위해 Linux 시스템을 구성 할 수 있습니까?


119

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

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

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


6
RAM이 많은 경우 성능에 많은주의를 기울이고 데이터 손실에 신경 쓰지 말고 모든 데이터를 RAM 디스크에 복사 한 다음 디스크에서 서비스하면 충돌 / 종료시 모든 업데이트가 삭제됩니다. 그래도 문제가 해결되지 않으면 RAM에 대해 "충분한"자격을 갖추거나 데이터가 얼마나 중요하지 않은지 확인해야합니다.
James Youngman

1
@ Nils, 컴퓨터는 랩톱이므로 컨트롤러는 매우 평범하다고 ​​생각합니다.
Ivan

1
성능을 크게 향상시키는 한 가지 방법은 데이터의 내구성을 건너 뛰는 것입니다. 일부 앱이 동기화를 요청하더라도 디스크 동기화를 비활성화하면됩니다. 이것은 데이터 손실의 원인이됩니다 저장 장치는 지금까지 전력의 손실을 앓고있는 경우. 어쨌든 성능을 향상시키기 위해 희생하려는 파일 시스템 을 포함 하도록 실행 sudo mount -o ro,nobarrier /path/to/mountpoint하거나 조정하십시오 . 그러나 저장 장치에 Intel 320 SSD 시리즈와 같은 내장 배터리 가있는 경우 데이터를 사용 하지 않아도됩니다. /etc/fstabnobarriernobarrier
Mikko Rantalainen

1
쓰기 장벽의 부정적인 성능 영향은 무시할 수 있으므로 (약 3 %) Redbar Enterprise Linux 6에서는 nobarrier를 더 이상 사용하지 않는 것이 좋습니다. 쓰기 장벽의 이점은 일반적으로이를 사용하지 않는 경우의 성능 이점보다 큽니다. 또한 nobarrier 옵션은 가상 머신에 구성된 스토리지에서 사용해서는 안됩니다. access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/…
Ivailo Bardarov

1
두 가지 요점-1) Puppy Linux 및 AntiX Linux와 같은 데비안 또는 우분투 기반의 Linux 배포판과 전체 운영 체제를 계층화 된 램 디스크 부분 (예 : AUFS 또는 오버레이 파일)으로 배치하고 투명하게 관리하는 Linux 배포판이 있습니다. 매우 빠릅니다! -2) 캐시를 더 많이 던지면 성능이 저하 될 수있는 매우 큰 시스템의 실제 설계에서 발견되었습니다. 스토리지 속도가 증가함에 따라 (예 : SSD) 최적의 캐시 크기가 줄어 듭니다. 그래도 특정 시스템에서 실험하지 않고 그 크기가 무엇인지 알 수있는 방법은 없습니다. 증가가 작동하지 않으면 감소 시키십시오.
DocSalvager

답변:


107

일반적으로 디스크 캐시 성능을 개선하면 않는 한 단지 파일 시스템 캐시 크기를 증가보다 더 전체 시스템이이 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)&

3
인정 된 것보다 잘 알고 전체적으로 훨씬 더 나은 답변! 이 사람은 과소 평가된다. 나는 대부분의 사람들이 그들이 실제로 하는 일을 이해하지 않고 간단한 지시를 원한다고 생각한다 .
Vladimir Panteleev

2
@Phpdevpad : 또한, 질문은 "RAM 사용에 대해 걱정하지 않습니다 ...]라고 말하였습니다.-Maemo 장치가 자격이 있다고 생각하지 않습니다.
Mikko Rantalainen

1
noop 또는 데드 라인이 SSD의 더 나은 스케줄러가 아닙니까?
rep_movsd

1
@rep_movsd 인텔 SSD 드라이브 만 사용하고 있지만 CFQ와 같은보다 지능적인 스케줄러를 사용하면 전반적인 드라이브 성능이 향상 될 수있을 정도로 속도가 느립니다. SSD 드라이브가 100K 이상의 임의 IOPS를 처리 할 수 ​​있다면 빠른 CPU에서도 noop 또는 데드 라인을 사용하는 것이 합리적이라고 생각합니다. "고속 CPU"란 IO에만 사용할 수있는 3GHz 이상의 코어가 여러 개있는 것을 의미합니다.
Mikko Rantalainen

1
vm 커널 문서 에서 이러한 vm 튜너 블에 대해 읽을 수도 있습니다 .
joeytwiddle

16

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

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

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

어쩌면 시도해보고 싶을 수도 있습니다 :-)


1
이미 NTFS에서 ext4로 완전히 한 번 옮겨서 NTFS 파티션 만 Windows 시스템 파티션으로 남겨 두었습니다. 그러나 그것은 많은 불편을 겪었고 주 데이터 파티션 (모든 문서, 다운로드, 프로젝트, 소스 코드 등을 저장하는 곳) 파일 시스템으로 NTFS로 되돌아갔습니다. 파티션 구조와 워크 플로 (Windows를 덜 사용하기 위해)를 다시 생각하지는 않지만 NTFS를 포기하는 것은 현실적인 옵션이 아닙니다.
Ivan

Windows에서도 데이터를 사용해야하는 경우 NTFS가 유일한 옵션 일 수 있습니다. (Linux에서 VM처럼 Windows를 사용할 수 있다면 다른 많은 옵션을 사용할 수 있습니다)
Felix Yan

1
이러한 문제가 NTFS에 어떤 문제가 있는지 요약하면 유용했을 것입니다.
underscore_d

2
Linux의 NTFS는 성능을 제외하고 거의 수용 가능합니다. 파일 시스템 성능 향상에 대한 문제라는 점을 고려할 때 NTFS를 가장 먼저 고려해야합니다.
Mikko Rantalainen

비록 btrfs최근에 파일 시스템을 설계, 나는 성능이 필요한 경우 피하기 것입니다. 우리는 다른 시스템 btrfsext4파일 시스템을 사용하여 동일한 시스템을 실행 ext4했으며 실제 환경에서 큰 차이로 승리했습니다 ( 동일한 성능 수준에 대한 요구 btrfs는 약 4 배의 CPU 시간이 ext4필요하고 단일 논리 명령으로 더 많은 디스크 작업을 유발합니다). 작업 부하에 따라, 나는 제안 ext4, jfs또는 xfs어떤 성능을 요구하는 작업.
Mikko Rantalainen

8

미리 읽기 :

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를 사용하십시오.


5
3GB 또는 2TB 미리 읽기? 정말? 이 옵션들이 무엇을하는지 아십니까?
Cobra_Fast

1
@Cobra_Fast 무슨 뜻인지 아십니까? 나는 정말로 모른다. 그리고 나는 지금 관심이있다.
syss

3
@syss 판독 헤드 설정은 바이트 또는 비트가 아닌 메모리 "블록"수로 저장됩니다. 한 블록의 크기는 커널 컴파일 타임 (판독 헤드 블록이 메모리 블록이므로) 또는 파일 시스템 생성 시간에 결정됩니다 (일부 경우). 일반적으로 1 블록에는 512 또는 4096 바이트가 포함됩니다.
Cobra_Fast

6

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


2

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

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에서 발생하고 디스크 쓰기는 매우 늦습니다.


4
vfs_cache_pressure너무 높게 설정하면 ( 너무 높은 것으로 간주 2000) 디렉토리 목록과 같이 캐시에 쉽게 맞아야하는 간단한 항목에도 불필요한 디스크 액세스가 발생합니다. 얼마나 많은 RAM이 있고 시스템으로 무엇을하고 있습니까? 내 대답에 쓴 것처럼이 설정에 높은 값을 사용하면 RAM이 제한된 HD 비디오 편집에 적합합니다.
Mikko Rantalainen

2
" vfs_cache_pressure를 100 이상으로 크게 늘리면 성능에 부정적인 영향을 줄 수 있습니다. 교정 코드는 사용 가능한 디렉토리 및 inode 객체를 찾기 위해 다양한 잠금을 수행해야합니다. vfs_cache_pressure = 1000을 사용하면 사용 가능한 객체보다 10 배 더 많은 사용 가능한 객체를 찾을 수 있습니다. 아르."
Mikko Rantalainen

1

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

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

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

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

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

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

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

다른 옵션:

  • 위의 의견에서 Mikko는 nobarrier 옵션 으로 장착 가능성을 공유했습니다 . 그러나 Ivailo 는 이에 대해주의를 기울이는 RedHat인용 했습니다. 그 여분의 3 %를 얼마나 심하게 원하십니까?
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.