🥇GlusterFS용 Linux 커널 설정

기사의 번역은 과정 시작 전날에 준비되었습니다. 관리자 리눅스. 전문적인".

주기적으로 여기저기서 커널 튜닝에 관한 Gluster의 권장 사항과 이것이 필요한지 여부에 대한 질문이 제기됩니다.

그러한 필요는 거의 발생하지 않습니다. 대부분의 워크로드에서 커널은 매우 잘 수행됩니다. 단점이 있지만. 역사적으로 Linux 커널은 성능 향상을 위한 주요 방법으로 캐싱을 포함하여 기회가 주어지면 많은 메모리를 기꺼이 소비했습니다.

대부분의 경우 이 방법은 잘 작동하지만 과부하 상태에서는 문제가 발생할 수 있습니다.

우리는 CAD, EDA 등과 같은 메모리 집약적 시스템에 대해 많은 경험을 가지고 있으며, 과부하 상태에서 속도가 느려지기 시작했습니다. 그리고 때때로 우리는 Gluster에서 문제에 부딪쳤습니다. 여러 날 동안 메모리 사용량과 디스크 대기 시간을 주의 깊게 관찰한 후 과부하, 엄청난 iowait, 커널 오류(커널 oops), 정지 등을 발견했습니다.

이 기사는 다양한 상황에서 수행된 많은 튜닝 실험의 결과입니다. 이러한 매개 변수 덕분에 전반적인 응답성이 향상되었을 뿐만 아니라 클러스터도 크게 안정화되었습니다.

메모리 튜닝과 관련하여 가장 먼저 살펴봐야 할 것은 가상 메모리 하위 시스템(VM, 가상 메모리)으로, 혼동을 줄 수 있는 많은 옵션이 있습니다.

VM.swappiness

매개 변수 vm.swappiness 커널이 RAM에 비해 스왑(스왑, 페이징)을 사용하는 양을 결정합니다. 또한 소스 코드에서 "매핑된 메모리를 훔치는 경향"으로 정의되어 있습니다. 높은 swappiness는 커널이 매핑된 페이지를 교체하는 경향이 있음을 의미합니다. 낮은 swappiness 값은 그 반대를 의미합니다. 즉, 커널이 메모리에서 더 적게 페이징됩니다. 즉, 값이 높을수록 vm.swappiness, 시스템이 스왑을 더 많이 사용합니다.

대량의 데이터 블록이 RAM에 로드 및 언로드되기 때문에 스와핑을 많이 사용하는 것은 바람직하지 않습니다. 많은 사람들이 swapiness 값이 커야 한다고 주장하지만 제 경험상 "0"으로 설정하면 성능이 더 좋아집니다.

여기에서 자세한 내용을 읽을 수 있습니다. lwn.net/Articles/100978

그러나 이러한 설정은 주의해서 적용해야 하며 특정 응용 프로그램을 테스트한 후에만 적용해야 합니다. 부하가 높은 스트리밍 애플리케이션의 경우 이 매개변수를 "0"으로 설정해야 합니다. "0"으로 변경하면 시스템 응답성이 향상됩니다.

vm.vfs_cache_압력

이 설정은 디렉토리 및 inode 개체(dentry 및 inode) 캐싱을 위해 커널에서 사용하는 메모리를 제어합니다.

기본값이 100인 경우 커널은 페이지 캐시 및 스왑 캐시에 대해 "공정한" 기준으로 dentry 및 inode 캐시를 해제하려고 시도합니다. vfs_cache_pressure를 줄이면 커널이 dentry 및 inode 캐시를 유지합니다. 값이 "0"이면 커널은 메모리 부족으로 인해 dentry 및 inode 캐시를 플러시하지 않으며 이로 인해 쉽게 메모리 부족 오류가 발생할 수 있습니다. vfs_cache_pressure를 100 이상으로 높이면 커널이 dentry 및 inode 플러시의 우선 순위를 지정합니다.

GlusterFS를 사용할 때 많은 양의 데이터와 많은 작은 파일을 가진 많은 사용자는 inode/dentry 캐싱으로 인해 서버에서 상당한 양의 RAM을 쉽게 사용할 수 있으며, 이는 커널이 시스템에서 데이터 구조를 처리해야 하므로 성능 저하로 이어질 수 있습니다. 40GB의 메모리로 . 이 값을 100 이상으로 설정하면 많은 사용자가 더 공정한 캐싱과 향상된 커널 응답성을 달성하는 데 도움이 되었습니다.

vm.dirty_background_ratio 및 vm.dirty_ratio

첫 번째 매개변수(vm.dirty_background_ratio)는 더티 페이지가 있는 메모리의 비율을 결정하며, 도달한 후 백그라운드에서 더티 페이지를 디스크로 플러시하기 시작해야 합니다. 이 비율에 도달할 때까지 페이지가 디스크로 플러시되지 않습니다. 재설정이 시작되면 실행 중인 프로세스를 중단하지 않고 백그라운드에서 실행됩니다.

두 번째 매개변수(vm.dirty_ratio)는 강제 플래시가 시작되기 전에 더티 페이지가 점유할 수 있는 메모리의 백분율을 정의합니다. 이 임계값에 도달하면 모든 프로세스가 동기(차단)되고 요청한 I/O가 실제로 완료되고 데이터가 디스크에 저장될 때까지 계속할 수 없습니다. I/O가 많은 경우 데이터 캐싱이 없고 I/O를 수행하는 모든 프로세스가 I/O를 기다리며 차단되기 때문에 문제가 발생합니다. 이로 인해 많은 수의 중단된 프로세스, 높은 부하, 시스템 불안정 및 성능 저하가 발생합니다.

이러한 설정을 낮추면 데이터가 더 자주 디스크로 플러시되고 RAM에 저장되지 않습니다. 이는 45-90GB 페이지 캐시를 디스크로 플러시하는 것이 일반적인 메모리 사용량이 많은 시스템에 도움이 될 수 있으며, 이로 인해 프런트 엔드 애플리케이션의 대기 시간이 길어져 전반적인 응답성과 상호 작용이 감소합니다.

"1" > /proc/sys/vm/pagecache

페이지 캐시는 파일 및 실행 프로그램의 데이터를 저장하는 캐시입니다. 즉, 파일 또는 블록 장치의 실제 내용이 있는 페이지입니다. 이 캐시는 디스크 읽기 수를 줄이는 데 사용됩니다. "1" 값은 RAM의 1%가 캐시에 사용되고 RAM보다 디스크에서 더 많은 읽기가 있음을 의미합니다. 이 설정을 변경할 필요는 없지만 페이지 캐시 제어에 대해 편집증이 있는 경우 사용할 수 있습니다.

"기한" > /sys/block/sdc/queue/scheduler

I/O 스케줄러는 읽기 및 쓰기 대기열을 처리하는 Linux 커널 구성 요소입니다. 이론적으로 스마트 RAID 컨트롤러에 "noop"를 사용하는 것이 좋습니다. Linux는 디스크의 물리적 구조에 대해 아무것도 모르기 때문입니다. 따라서 디스크 구조를 잘 알고 있는 컨트롤러가 최대한 빨리 요청을 처리하도록 하는 것이 더 효율적입니다 가능한. 그러나 "마감"이 성능을 향상시키는 것처럼 보입니다. Linux 커널 소스 코드 문서에서 스케줄러에 대한 자세한 내용을 읽을 수 있습니다. linux/Documentation/block/*osched.txt. 또한 혼합 작업(많은 쓰기 작업) 중에 읽기 처리량이 증가하는 것을 보았습니다.

"256" > /sys/block/sdc/queue/nr_requests

스케줄러에 전달되기 전에 버퍼에 있는 I/O 요청 수입니다. 일부 컨트롤러의 내부 큐 크기(queue_depth)는 I/O 스케줄러의 nr_requests보다 크므로 I/O 스케줄러가 요청의 우선 순위를 적절하게 지정하고 병합할 가능성이 거의 없습니다. 최종 기한 및 CFQ 스케줄러의 경우 nr_requests가 컨트롤러의 내부 대기열의 2배인 것이 더 좋습니다. 요청을 병합하고 재정렬하면 스케줄러가 과부하 상태에서 더 빠르게 응답할 수 있습니다.

echo "16" > /proc/sys/vm/page-cluster

page-cluster 매개변수는 한 번에 스왑에 기록되는 페이지 수를 제어합니다. 위의 예에서 RAID 스트라이프 크기 16KB에 따라 값이 "64"으로 설정되었습니다. swappiness = 0에서는 의미가 없지만 swappiness를 10 또는 20으로 설정하면 이 값을 사용하면 RAID 스트라이프 크기가 64K일 때 도움이 됩니다.

blockdev --setra 4096 /dev/`<`개발명`>` (-sdb, hdc 또는 dev_mapper)

많은 RAID 컨트롤러에 대한 기본 블록 장치 설정은 종종 끔찍한 성능을 초래합니다. 위 옵션을 추가하면 4096 * 512바이트 섹터에 대한 미리 읽기가 설정됩니다. 적어도 스트리밍 작업의 경우 커널이 I/O를 준비하는 데 사용하는 기간 동안 온칩 디스크 캐시를 미리 읽기로 채워 속도를 높입니다. 캐시에는 다음에 읽을 때 요청되는 데이터가 포함될 수 있습니다. 프리페치가 너무 많으면 잠재적으로 유용한 디스크 시간을 사용하거나 캐시 외부에서 데이터를 로드하는 경우 대용량 파일에 대한 임의 I/O가 중단될 수 있습니다.

다음은 파일 시스템 수준에서 몇 가지 추가 권장 사항입니다. 그러나 그들은 아직 테스트되지 않았습니다. 파일 시스템이 스트라이프 크기와 어레이의 디스크 수를 알고 있는지 확인하십시오. 예를 들어, 이것은 5개의 디스크로 구성된 64K 스트라이프 raidXNUMX 어레이입니다(하나의 디스크가 패리티에 사용되기 때문에 실제로는 XNUMX개). 이러한 권장 사항은 이론적인 가정을 기반으로 하며 RAID 전문가의 다양한 블로그/기사에서 수집되었습니다.

-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))

큰 파일의 경우 위에 나열된 스트라이프 크기를 늘리는 것이 좋습니다.

주의 위에서 설명한 모든 것은 일부 유형의 응용 프로그램에 대해 매우 주관적입니다. 이 문서는 관련 응용 프로그램에 대한 사전 사용자 테스트 없이 개선을 보장하지 않습니다. 시스템의 전반적인 응답성을 개선하거나 현재 문제를 해결하는 경우에만 사용해야 합니다.

추가 자료 :

더 읽어보기

Red Hat Enterprise Linux 8에서 nftables 사용

출처 : habr.com

GlusterFS용 Linux 커널 설정