🥇커널 설정 Linux GlusterFS용

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

가끔 Gluster의 커널 튜닝에 대한 권장 사항과 그것이 필요한지에 대한 의문이 제기됩니다.

이러한 필요성은 거의 발생하지 않습니다. 대부분의 작업 부하에서 코어는 매우 뛰어난 성능을 보여줍니다. 하지만 단점이 있습니다. 과거에는 코어가 Linux 기회가 주어진다면 기꺼이 많은 메모리를 소비하며, 성능 향상의 주요 방법으로 캐싱을 활용합니다.

대부분의 경우에는 잘 작동하지만, 부하가 심할 경우 문제가 발생할 수 있습니다.

우리는 CAD, EDA 등과 같이 높은 부하에서 속도가 느려지는 메모리 집약적 시스템에 대한 광범위한 경험을 가지고 있습니다. 그리고 때때로 Gluster에서 문제가 발생하기도 했습니다. 1일 이상 메모리 사용량과 디스크 대기 시간을 주의 깊게 모니터링한 결과, 과부하, 엄청난 iowait, 커널 오류, 정지 등의 문제가 발생했습니다.

본 논문은 다양한 상황에서 수행된 많은 매개변수 튜닝 실험의 결과입니다. 이러한 매개변수 덕분에 전반적인 대응성이 향상되었을 뿐만 아니라 클러스터 운영도 상당히 안정화되었습니다.

메모리를 구성할 때 가장 먼저 살펴봐야 할 것은 가상 메모리(VM) 하위 시스템입니다. 여기에는 혼란스러울 수 있는 많은 옵션이 있습니다.

VM.swappiness

매개 변수 vm.swappiness 커널이 RAM에 비해 스왑을 얼마나 많이 사용하는지 결정합니다. 소스 코드에서는 이를 "매핑된 메모리를 훔치는 경향"으로 정의하기도 합니다. 스왑니스 값이 높으면 커널이 매핑된 페이지를 스왑 아웃할 가능성이 더 높다는 것을 의미합니다. 스왑니스 값이 낮으면 그 반대의 의미가 됩니다. 즉, 커널이 메모리에서 스왑하는 페이지 수가 줄어듭니다. 즉, 가치가 높을수록 vm.swappiness, 시스템이 스왑을 더 많이 사용하게 됩니다.

큰 스왑 사용은 엄청난 양의 데이터 블록이 RAM에 로드되고 언로드되기 때문에 바람직하지 않습니다. 많은 사람들은 스왑니스를 높게 설정해야 한다고 주장하지만, 제 경험상 0으로 설정하면 성능이 더 좋습니다.

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

하지만 이러한 설정은 신중하게 사용해야 하며 특정 애플리케이션을 테스트한 후에만 사용해야 합니다. 부하가 큰 스트리밍 애플리케이션의 경우 이 매개변수를 "0"으로 설정해야 합니다. "0"으로 변경하면 시스템 응답성이 향상됩니다.

vm.vfs_cache_pressure

이 매개변수는 커널이 디렉토리 객체와 inode를 캐싱하는 데 사용하는 메모리를 제어합니다.

기본값 100을 사용하면 커널은 pagecache 및 swapcache에 비해 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

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

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에서 nftables 사용하기 Linux 8

출처 : habr.com

커널 설정 Linux GlusterFS용