Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

5.3. 설정 도구

Red Hat Enterprise Linux에는 스토리지 및 파일 시스템을 설정할 때 관리자에게 유용한 여러 도구가 있습니다. 다음 부분에서는 이러한 도구에 대해 설명하고 Red Hat Enterprise Linux 7에서 I/O 및 파일 시스템 관련 성능 문제를 해결하는 방법에 대해 설명합니다.

5.3.1. 스토리지 성능의 프로파일 튜닝 설정

Tunedtuned-adm은 특정 사용 경우에서 성능을 개선하기 위한 여러 프로파일을 제공합니다. 특히 다음 프로파일은 스토리지 성능을 개선하는데 유용합니다.
  • latency-performance
  • throughput-performance (기본)
시스템에 프로파일을 설정하려면 다음 명령을 실행합니다. 여기서 name은 사용하고자 하는 프로파일 이름으로 변경합니다.
$ tuned-adm profile name
tuned-adm recommend 명령은 시스템에 적합한 프로파일을 권장합니다. 또한 이는 설치 시 시스템에 기본 프로파일을 설정하여 기본 프로파일로 돌아갈 때 사용할 수 있습니다.
이러한 프로파일이나 추가 설정 옵션에 대한 보다 자세한 내용은 A.6절. “tuned-adm”에서 참조하십시오.

5.3.2. 기본 I/O 스케줄러 설정

기본 I/O 스케줄러는 장치의 마운트 옵션에 지정된 스케줄러가 없을 경우 사용되는 스케줄러입니다.
기본 I/O 스케줄러를 설정하려면 부팅시 커널 명령행에 엘리베이터 매개 변수를 추가하거나 /etc/grub2.conf 파일을 편집하여 사용하려는 스케줄러를 설정합니다.
elevator=scheduler_name

5.3.3. 장치의 I/O 스케줄러 설정

특정 스토리지 장치의 스케줄러나 스케줄러 우선 순위를 설정하려면 /sys/block/devname/queue/scheduler 파일을 편집합니다. 여기서 devname은 설정하려는 장치 이름으로 변경합니다.
# echo cfq > /sys/block/hda/queue/scheduler

5.3.4. deadline 스케줄러 튜닝

deadline이 사용 중일 때 대기 큐에 있는 I/O 요청은 읽기 또는 쓰기 배치로 나뉘어 LBA 오름 차순으로 실행이 예약됩니다. 애플리케이션은 읽기 I/O에서 블록될 가능성이 높기 때문에 기본적으로 읽기 배치가 쓰기 배치보다 우선합니다. 배치 처리 후 deadline은 쓰기 작업의 프로세서 대기 시간을 확인하고 다음의 읽기 또는 쓰기 배치를 적절히 예약합니다.
다음 매개 변수는 deadline 스케줄러 동작에 영향을 미칠 수 있습니다.
fifo_batch
단일 배치에서 발생하는 읽기 또는 쓰기 작업 수입니다. 기본값은 16입니다. 값이 높을 수록 처리 능력도 증가하지만 대기 시간도 늘어납니다.
front_merges
워크로드가 전면 병합을 생성하지 않은경우 이 매개 변수를 0으로 설정할 수 있습니다. 하지만 이러한 검사의 오버헤드를 측정하지 않는 한 Red Hat은 기본 설정 1을 그대로 사용할 것을 권장합니다.
read_expire
읽기 요청을 실행할 시간을 밀리초 단위로 예약 설정할 수 있습니다. 기본값은 500 (0.5 초)입니다.
write_expire
쓰기 요청을 실행할 시간을 밀리초 단위로 예약 설정할 수 있습니다. 기본값은 5000 (5 초)입니다.
writes_starved
쓰기 배치를 처리하기 전 처리할 수 있는 읽기 배치 수를 지정합니다. 이 값을 높게 설정할 수록 읽기 배치가 우선적으로 처리됩니다.

5.3.5. cfq 스케줄러 튜닝

cfq를 사용하고 있을 경우 프로세스는 실시간, 최선형, 유휴 상태의 3 가지 다른 클래스에 배치됩니다. 실시간 프로세스는 최선형 프로세스보다 먼저 스케줄 예약되고 최선형 프로세스는 유휴 상태 프로세스보다 먼저 스케줄 예약됩니다. 기본값으로 프로세스는 최선형 클래스에 배치됩니다. ionice 명령을 사용하여 프로세스를 수동으로 조정할 수 있습니다.
다음 매개 변수를 사용하여 cfq 스케줄러 동작을 추가로 설정할 수 있습니다. 이러한 매개 변수는 /sys/block/devname/queue/iosched 디렉토리 아래에 지정된 파일에서 장치 별로 설정을 변경합니다.
back_seek_max
cfq는 역방향 검색을 수행하는 최대 거리를 킬로바이트 단위로 지정합니다. 기본값은 16 KB입니다. 일반적으로 역방향 검색은 성능에 지장이 될 수 있으므로 큰 값을 사용하는 것을 권장하지 않습니다.
back_seek_penalty
디스크 헤드를 앞 또는 뒤로 이동할 지를 지정할 때 역방향 검색에 적용할 승수를 지정합니다. 기본값은 2입니다. 디스크 헤드 위치가 1024 KB이고 시스템에 등거리 요청 (예: 1008 KB 및 1040 KB)이 있을 경우 back_seek_penalty는 역박향 탐색거리에 적용되며 디스크는 앞으로 이동합니다.
fifo_expire_async
비동기 (버퍼 쓰기) 요청이 처리되지 않은 상태로 남아 있을 수 있는 시간을 밀리초 단위로 지정합니다. 지정된 시간이 경과하면 단일 비동기 처리 요청은 디스패치 목록으로 이동합니다. 기본값은 250 밀리초입니다.
fifo_expire_sync
동기화 (읽기 또는 O_DIRECT 쓰기) 요청이 최리되지 않은 상태로 남아 있을 수 있는 시간을 밀리초 단위로 지정합니다. 지정된 시간이 경과하면 단일 동기화 처리 요청은 디스패치 목록으로 이동합니다. 기본값은 125 밀리초입니다.
group_idle
이 매개 변수는 기본적으로 0 (비활성화)로 설정됩니다. 1 (활성화)로 설정되어 있을 경우 cfq 스케줄러는 제어 그룹에서 I/O를 발행하는 마지막 프로세스에서 유휴 상태가 됩니다. 비례 가중 I/O 제어 그룹을 사용하고 slice_idle0으로 (고속 스토리지) 설정되어 있을 때 유용합니다.
group_isolation
이 매개 변수는 기본적으로 0 (비활성화)로 설정되어 있습니다. 1 (활성화)로 설정되어 있을 경우 그룹 간의 분리를 강화하지만 연속 및 임의의 워크로드 모두에 공정성이 적용되므로 처리 능력이 감소됩니다. group_isolation이 비활성화 (0 설정)되어 있을 경우 공정성은 연속 워크로드에만 제공됩니다. 보다 자세한 내용은 /usr/share/doc/kernel-doc-version/Documentation/cgroups/blkio-controller.txt에 설치된 문서에서 참조하십시오.
low_latency
이 매개 변수는 기본적으로 1 (활성화)로 설정되어 있습니다. 활성화되어 있을 경우 cfq는 장치에 I/O를 발행하는 각 프로세스에 대해 최대 300 ms로 대기 시간을 제공하여 처리량 보다 공정성을 우선으로 합니다. 이 매개 변수가 0 (비활성화)로 설정되어 있을 경우 대상 지연 시간은 무시되고 각 프로세스는 전체 타임 슬라이스를 받습니다.
quantum
이 매개 변수는 cfq가 한 번에 하나의 장치에 보낼 수 있는 I/O 요청 수를 지정하며, 기본적으로 큐 깊이를 제한합니다. 기본값은 8입니다. 사용 장치는 더 깊은 큐 깊이를 지원할 수 있지만 quantum을 증가시키면 대기 시간이 늘어나며 특히 대량의 연속 쓰기 워크로드가 있을 경우 더욱 그러합니다.
slice_async
이 매개 변수는 비동기 I/O 요청을 발행하는 각 프로세스에 할당할 타임 슬라이스 (밀리초 단위) 길이를 지정합니다. 기본값은 40 밀리초입니다.
slice_idle
이는 추가 요청을 기다리는 동안 cfq의 유휴 상태 시간을 밀리초 단위로 지정합니다. 기본값은 0 (큐 또는 서비스 트리 레벨에서 유휴 상태가 아님)입니다. 외부 RAID 스토리지에서의 처리량의 경우 기본값을 사용하는 것이 좋지만 이는 전체 검색 수를 증가시키므로 내부의 비 RAID 스토리지에서의 처리량을 저하시킬 수 있습니다.
slice_sync
이 매개 변수는 비동기 I/O 요청을 발행하는 각 프로세스에 할당할 타임 슬라이스 (밀리초 단위) 길이를 지정합니다. 기본값은 100 밀리초입니다.

5.3.5.1. 고속 스토리지에 cfq 튜닝

외장형 스토리지 어레이나 SSD와 같은 대형 탐색 패널티의 영향을 받지 않는 하드웨어의 경우 cfq 스케줄러 사용을 권장하지 않습니다. 이러한 스토리지에서 cfq를 사용해야 할 경우 다음 설정 파일을 편집해야 합니다:
  • /sys/block/devname/queue/ionice/slice_idle0로 설정
  • /sys/block/devname/queue/ionice/quantum64로 설정
  • /sys/block/devname/queue/ionice/group_idle1로 설정

5.3.6. noop 스케줄러 튜닝

noop I/O 스케줄러는 주로 고속 스토리지를 사용하는 CPU 바인딩 시스템에 유용합니다. 요청은 블록층에서 병합되므로 noop 동작을 수정하려면 /sys/block/sdX/queue/ 디렉토리 아래에 있는 파일에서 블록 층 매개 변수를 편집합니다.
add_random
일부 I/O 이벤트는 /dev/random의 엔트로피 풀에 적용됩니다. 이러한 적용의 오버헤드가 측정 가능할 경우 이 매개 변수를 0로 설정할 수 있습니다.
max_sectors_kb
최대 I/O 요청 크기를 KB 단위로 지정합니다. 기본값은 512 KB입니다. 이 매개 변수의 최소값은 스토리지 장치의 논리적 블록 크기에 따라 지정됩니다. 이 매개 변수의 최대값은 max_hw_sectors_kb 값에 따라 지정됩니다.
I/O 요청이 내부 소거 블록 크기 보다 크면 일부 SSD 성능이 저하됩니다. 이러한 경우 Red Hat은 max_hw_sectors_kb를 내부 소거 블록 크기로 줄일 것을 권장합니다.
nomerges
요청 병합은 대부분의 워크로드에 효과적이지만 디버깅 목적의 경우 병합을 비활성화하는것이 유용합니다. 이 매개 변수를 0로 설정하여 병합을 비활성화합니다. 기본값으로 이는 비활성화 (1으로 설정)되어 있습니다.
nr_requests
한 번에 대기 큐에 둘 수 있는 최대 읽기 및 쓰기 요청 수를 지정합니다. 기본값은 128이며 이는 다음의 읽기 또는 쓰기 요청 프로세스를 수면 상태로 두기 전 128 개의 읽기 요청과 128 개의 쓰기 요청을 대기 큐에 둘 수 있음을 의미합니다.
대기 시간에 민감한 애플리케이션의 경우 이 매개 변수의 값을 낮추고 스토리지의 명령 큐 깊이를 제한하면 다시 쓰기 I/O는 쓰기 요청으로 장치 큐를 채울 수 없습니다. 장치 큐가 채워지면 I/O 동작을 실행하려고 하는 다른 프로세스는 큐를 사용할 수 있을 때 까지 수면 상태로 됩니다. 요청은 라운드 로빈 방식으로 할당되기 때문에 하나의 프로세스가 큐에서 지속적으로 소비되지 않게 합니다.
optimal_io_size
일부 스토리지 장치는 이러한 매개 변수를 통해 최적의 I/O 크기를 보고합니다. 이러한 값이 보고되면 Red Hat은 애플리케이션이 가능한 최적의 I/O 크기로 조정되어 그 배수의 I/O를 실행할 것을 권장합니다.
read_ahead_kb
페이지 캐시에서 곧 필요한 정보를 저장하기 위해 연속적인 읽기 동작 동안 운영 체제가 미리 읽기할 용량 (KB)을 지정합니다. 장치 매퍼는 read_ahead_kb 값을 높게 지정하여 이점을 갖는 경우가 종종 있습니다. 각 장치의 매핑 값을 128 KB로 시작하는 것이 좋습니다.
rotational
일부 SSD는 솔리드 스테이트 상태를 올바르게 보고하지 않아 기존 회전 디스크로 마운트됩니다. SSD 장치가 이 값을 자동으로 0으로 설정하지 않으면 이를 수동으로 설정하여 스케줄러에서 필요하지 않은 검색 시간 단축 설정을 비활성화합니다.
rq_affinity
기본적으로 I/O 요청을 발행한 프로세서가 아닌 다른 프로세서에서 I/O 완료를 처리할 수 있습니다. rq_affinity1로 설정하여 이 기능을 해제하고 I/O 요청을 발행하는 프로세서에서만 I/O 완료를 처리하도록 합니다. 이는 프로세서 데이터 캐시의 효율성을 향상시킬 수 있습니다.

5.3.7. 성능 개선을 위한 파일 시스템 설정

다음 부분에서는 Red Hat Enterprise Linux 7에서 지원되는 각 파일 시스템의 특정 매개 변수 튜닝에 대해 설명합니다. 매개 변수는 스토리지 장치를 포맷할 때 매개 변수 값을 설정하는 경우와 포맷된 장치에 마운트할 때 매개 변수를 설정하는 경우로 나뉘어집니다.
파일 조각화 또는 리소스 경합으로 인해 성능 저하가 발생하는 경우 파일 시스템을 재설정하여 성능을 향상시킬 수 있습니다. 하지만 일부 경우 애플리케이션에 변경을 해야 하는 경우가 있습니다. 이러한 경우 Red Hat은 고객 지원팀에 문의할 것을 권장합니다.

5.3.7.1. XFS 튜닝

다음 부분에서는 XFS 파일 시스템 포맷이나 마운트 시 사용할 수 있는 일부 튜닝 매개 변수에 대해 설명합니다.
대부분의 워크로드에서 기본 XFS 포맷과 마운트 설정을 사용할 수 있습니다. Red Hat은 워크로드에 특정 설정 변경이 필요한 경우에만 변경할 것을 권장합니다.
5.3.7.1.1. 포맷 옵션
포맷 옵션에 대한 보다 자세한 내용은 man 페이지에서 참조하십시오:
$ man mkfs.xfs
디렉토리 블록 크기
디렉토리 블록 크기는 I/O 동작 마다 검색 또는 수정할 수 있는 디렉토리 정보 양에 영향을 미칩니다. 디렉토리 블록 크기의 최소 값은 파일 시스템 블록 크기 (기본4 KB )입니다. 최대 디렉토리 블록 크기 값은 64 KB입니다.
지정된 디렉토리 블록 크기에서 큰 디렉토리는 작은 디렉토리보다 많은 I/O를 필요로 합니다. 큰 디렉토리 블록 크기의 시스템이 작은 디렉토리 블록 크기의 시스템 보다 I/O 동작 당 처리량이 높습니다. 따라서 워크로그에서 디렉토리 및 디렉토리 블록 크기를 가능한 작게 할 것을 권장합니다.
Red Hat은 대량의 쓰기 작업이 및 읽기 작업이 있는 워크로드의 항목 수를 초과하지 않도록 파일 시스템에 대해 표 5.1. “디렉토리 블록 크기에 권장하는 최대 디렉토리 항목 수 ”에 나열된 디렉토리 블록 크기를 사용할 것을 권장하고 있습니다.
다른 크기의 파일 시스템에 있는 읽기 및 쓰기 워크로드에서 디렉토리 블록 크기에 미치는 영향에 대한 보다 자세한 내용은 XFS 문서에서 참조하십시오.
디렉토리 블록 크기를 설정하려면 mkfs.xfs -l 옵션을 사용합니다. 보다 자세한 내용은 mkfs.xfs man 페이지에서 참조하십시오.
할당 그룹
할당 그룹은 독립적인 구조로 파일 시스템 섹션에 할당된 inode 및 여유 공간의 인덱스를 생성합니다. 각 할당 그룹은 독립적으로 수정할 수 있기 때문에 XFS는 동시에 작업을 수행하는것이 다른 할당 그룹에 영향을 미치는 경우 할당 및 할당 해제 작업을 동시에 수행할 수 있습니다. 따라서 파일 시스템에서 실행할 수 있는 동시 작업 수는 할당 그룹 수와 동일합니다. 하지만 동시 작업을 실행할 수 있는 기능은 작업을 실행할 수 있는 프로세서 수에 의해 제한되므로 Red Hat은 할당 그룹 수를 시스템의 프로세서 수와 동일하게 또는 그 이상으로 할 것을 권장합니다.
단일 디렉토리는 여러 할당 그룹에서 동시에 변경할 수 없습니다. 따라서 Red Hat은 대량의 파일을 생성 및 삭제하는 애플리케이션은 단일 디렉토리에 모든 파일을 저장하지 못하게 할 것을 권장합니다.
할당 그룹을 설정하려면 mkfs.xfs -d 옵션을 사용합니다. 보다 자세한 내용은 mkfs.xfs man 페이지에서 참조하십시오.
증가 제약 조건
포맷 후 파일 시스템 크기를 증가시켜야 할 경우 (더 많은 하드웨어를 추가하거나 씬 프로비저닝을 통해), 포맷 완료 후 할당 그룹 크기를 변경할 수 없으므로 초기 파일 레이아웃을 주의 깊게 살펴보아야 합니다.
할당 그룹 크기는 초기 파일 시스템 용량이 아니라 최종 파일 시스템 용량에 따라 지정해야 합니다. 완전히 증가한 파일 시스템에 있는 할당 그룹 수는 할당 그룹이 최대 크기 (1 TB)가 아니면 수백을 초과해서는 안됩니다. 따라서 대부분의 파일 시스템에서 증가할 수 있는 최대 권장 크기는 초기 크기의 10배입니다.
RAID 어레이에서 파일 시스템을 증가시킬 때 장치 크기는 할당 그룹 크기의 배수로 새로운 할당 그룹 헤더가 새로 추가된 스토리지에 정렬되어야 하므로 추가적으로 주의를 기울여야 합니다. 새로운 스토리지는 기존 스토리지와 동일한 배열을 갖게 해야 하므로 포맷 후 배열을 변경할 수 없기 때문에 동일한 블록 장치에서 다른 배열의 스토리지를 최적화할 수 없습니다.
Inode 크기 및 인라인 속성
Inode에 사용 가능한 공간이 충분할 경우 XFS는 속성 이름과 값을 inode에 직접 쓸 수 있습니다. 이러한 인라인 속성은 추가 I/O가 필요하지 않기 때문에 별도의 속성 블록을 검색하는것 보다 신속하게 검색 및 변경할 수 있습니다.
기본 inode 크기는 256  바이트입니다. 여기서 약 100  바이트만 inode에 저장되는 데이터 범위 포인터 수에 따라 속성 스토리지에 사용할 수 있습니다. 파일 시스템 포맷 시 inode 크기를 증가시키면 스토리지 속성에 사용할 수 있는 공간 크기도 증가됩니다.
속성 이름 및 속성 값 모두 최대 254  바이트로 제한되어 있습니다. 속성 이름이나 속성 값 중 하나의 길이가 254  바이트를 초과하면 속성은 인라인에 저장되지 않고 별도의 속성 블록에 푸시됩니다.
inode 매개 변수를 설정하려면 mkfs.xfs -i 옵션을 사용합니다. 보다 자세한 내용은 mkfs.xfs man 페이지에서 참조하십시오.
RAID
소프트웨어 RAID를 사용하고 있는 경우 mkfs.xfs는 적절한 스트라이프 단위 및 너비로 기본 하드웨어를 자동으로 설정합니다. 하지만 스트라이프 단위 및 너비는 하드웨어 RAID가 사용 중일 경우 모든 하드웨어 RAID 장치가 이러한 정보를 내보내지 않으므로 수동으로 설정해야 할 필요가 있을 수 있습니다. 스트라이프 단위 및 너비를 설정하려면 mkfs.xfs -d 옵션을 사용합니다. 보다 자세한 내용은 mkfs.xfs man 페이지에서 참조하십시오.
로그 크기
보류중인 변경 사항은 로그에 기록될 부분에 동기화 이벤트가 발생할 때 까지 메모리에 집계됩니다. 로그 크기에 따라 한번에 실행할 수 있는 동시 수정 수를 지정합니다. 또한 메모리에 집계할 수 있는 최대 변경 크기를 지정하여 디스크에 데이터가 기록되는 빈도를 지정합니다. 로그가 작을 수록 데이터가 디스크에 기록되는 빈도가 많아집니다. 하지만 로그가 큰 경우 보류 중인 변경 내용을 기록하기 위해 큰 메모리를 사용하기 때문에 메모리 제한이 있는 시스템은 큰 로그를 사용해도 이점이 없습니다.
로그는 기본 스트라이프 단위로 정렬될 경우 성능이 향상됩니다. 즉 로그 스트라이프 단위의 경계에서 시작하고 종료하는 것입니다. 로그를 스트라이프 단위로 정렬하려면 mkfs.xfs -d 옵션을 사용합니다. 보다 자세한 내용은 mkfs.xfs man 페이지에서 참조하십시오.
로그 크기를 설정하려면 다음의 mkfs.xfs 옵션을 사용합니다. 여기서 logsize는 로그 크기로 변경합니다:
# mkfs.xfs -l size=logsize
보다 자세한 내용은 mkfs.xfs man 페이지에서 참조하십시오:
$ man mkfs.xfs
로그 스트라이프 단위
RAID5 또는 RAID6 레이아웃을 사용하여 스토리지 장치에 기록할 로그는 스트라이프 단위 경계에서 시작하고 종료 (기본 스트라이프에 정렬)할 때 성능이 향상됩니다. mkfs.xfs는 적절한 로그 스트라이프 단위로 자동 설정 시도하지만 이러한 정보를 내보내는 RAID 장치에 따라 다릅니다.
동기화 이벤트가 자주 발생하는 워크로드의 경우 로그 스트라이프 단위를 크게 설정하면 성능에 문제가 될 수 있습니다. 기록이 작으면 로그 스트라이프 단위 크기를 채워야 하기 때문에 대기 시간이 증가될 수 있기 때문입니다. 워크로드가 로그 기록 대기 시간에 제약을 받는 경우 Red Hat은 로그 스트라이프 단위를 1 블록에 설정하여 정렬되지 않은 로그 기록을 시작하게 할 것을 권장합니다.
지원되는 로그 스트라이프 단위의 최대 크기는 최대 로그 버퍼 크기 (256 KB)입니다. 따라서 기본 스토리지는 로그에 설정할 수 있는 스트라이프 단위 보다 큰 스트라이프 단위를 갖게 할 수 있습니다. 이러한 경우 mkfs.xfs는 경고를 발행하고 32 KB의 로그 스트라이프 단위가 설정됩니다.
로그 스트라이프 단위를 설정하려면 다음 옵션 중 하나를 사용합니다. 여기서 N은 스트라이프 단위로 사용할 블록 수로 변경하고 size는 스트라이프 단위 크기를 KB로 입력합니다.
mkfs.xfs -l sunit=Nb
mkfs.xfs -l su=size
보다 자세한 내용은 mkfs.xfs man 페이지에서 참조하십시오:
$ man mkfs.xfs
5.3.7.1.2. 마운트 옵션
Inode 할당
  • compress=zlib - 더 나은 압축 비율입니다. 이전 커널에 대해 기본값이며 사용 안전합니다. (기본값)
  • compress=lzo - 압축 속도는 빠르지만 zlib 만큼 압축하지 않습니다.
  • compress=no - 압축을 비활성화합니다. (커널 3.6부터 사용 가능)
  • compress-force=method - 비디오나 dd 디스크 이미지와 같이 압축이 잘 되지 않는 파일의 경우 이러한 압축을 사용합니다. 사용 가능한 옵션은 compress-force=zlib 및 compress-force=lzo입니다.
1 TB 보다 큰 파일 시스템을 사용할 것을 권장합니다. inode64 매개 변수는 XFS가 전체 파일 시스템에 걸쳐 inode와 데이터를 할당하도록 설정합니다. 이는 파일 시스템 시작 부분에 inode가 대량 할당되지 않게하고 파일 시스템의 마지막 부분에 데이터가 대량으로 할당되지 않게하여 대량 파일 시스템의 성능을 향상시킬 수 있습니다.
로그 버퍼 크기 및 수
로그 버퍼가 클 수록 로그에 모든 변경 사항을 기록할 때 소요되는 I/O 작업 수가 줄어듭니다. 대량의 로그 버퍼는 비휘발성 쓰기 캐시가 없는 I/O 집중 워크로드에서 시스템 성능을 향상시킬 수 있습니다.
로그 버퍼 크기는 logbsize 마운트 옵션으로 설정되며 로그 버퍼에 저장할 수 있는 최대 정보량을 정의합니다. 로그 스트라이프 단위가 설정되어 있지 않을 경우 버퍼 쓰기는 최대 값보다 작아지기 때문에 동기화 작업이 많은 워크로드에 대해 로그 버퍼 크기를 작게할 필요가 없습니다. 기본 로그 버퍼 크기는 32 KB입니다. 최대 크기는 256 KB이며 기타 지원되는 크기는 64 KB, 128 KB 또는 32 KB와 256 KB 사이에서 로그 스트라이프 단위의 2 제곱 배수입니다.
로그 버퍼 수는 logbufs 마운트 옵션에 의해 지정됩니다. 기본값은 (최대) 8 로그 버퍼이지만 최소 2 로그 버퍼를 지정할 수 있습니다. 추가 로그 버퍼에 메모리를 할당할 여유가 없는 메모리 바인딩 시스템을 제외하고 로그 버퍼 수를 줄일 필요가 없습니다. 로그 버퍼 수를 줄이면 로그 성능이 저하되는 경향이 있으며 특히 로그 I/O 대기 시간에 제약이 있는 작업에서 더욱 그러합니다.
변경 기록 지연
XFS에는 변경 사항을 로그에 기록하기 전 메모리에 변경 사항을 집계해 둘 수 있는 옵션이 있습니다. delaylog 매개 변수를 사용하여 자주 변경되는 메타 데이터를 변경 사항이 있을 때 마다 기록하지 않고 주기적으로 로그에 기록할 수 있습니다. 이러한 옵션을 사용하면 크래시에서 손실될 수 있는 동작 수가 증가하고 메타 테이터를 추적하기 위해 사용되는 메모리 양도 증가합니다. 하지만 예상 작업량에 따라 메타데이터 변경 속도와 확장성을 증가시킬 수 있고 fsync, fdatasync, sync를 사용하여 디스크에 기록되는 데이터와 메타데이터를 확인하는 경우 데이터 또는 메타테이터의 무결성을 감소시킬 수 없습니다.

5.3.7.2. ext4 튜닝

다음 부분에서는 ext4 파일 시스템 포맷이나 마운트 시 사용할 수 있는 일부 튜닝 매개 변수에 대해 설명합니다.
5.3.7.2.1. 포맷 옵션
Inode 테이블 초기화
대형 파일 시스템에서 파일 시스템에 있는 모든 inode를 초기화하는 데는 시간이 오래 걸릴 수 있습니다. 기본적으로 초기화 프로세스는 미룰 수 있습니다 (이는 inode 테이블 초기화 지연이 활성화되어 있는 경우에 가능합니다만 시스템에 ext4 드라이버가 없을 경우 inode 테이블 초기화 지연은 기본적으로 비활성화되어 있습니다. 이는 lazy_itable_init을 1로 설정하여 활성화할 수 있습니다.) 이러한 경우 커널 프로세스는 마운트된 후 파일 시스템을 계속 초기화합니다.
다음 부분에서는 포맷 시 사용가능한 일부 옵션에 대해서만 설명합니다. 자세한 포맷 관련 매개 변수는 mkfs.ext4 man 페이지에서 참조하십시오:
$ man mkfs.ext4
5.3.7.2.2. 마운트 옵션
Inode 테이블 초기화 비율
inode 테이블 초기화 지연이 활성화되면 init_itable 매개 변수 값을 지정하여 초기화가 발생하는 비율을 제어할 수 있습니다. 백그라운드 초기화 실행에 걸리는 시간은 대략 이러한 매개 변수 값을 1로 나눈 값입니다. 기본값은 10입니다.
자동 파일 동기화
기존 파일 이름을 변경하거나 잘라내기 및 재작성 후 일부 애플리케이션에서 fsync가 제대로 작동하지 않는 경우가 있습니다. 기본적으로 ext4는 이러한 동작 후 파일 동기화가 자동으로 수행됩니다. 하지만 이러한 작업을 수행하는데는 시간이 걸릴 수 있습니다.
이러한 수준의 동기화 작업이 필요하지 않은 경우 마운트시 noauto_da_alloc 옵션을 지정하여 이러한 동작을 비활성화할 수 있습니다. noauto_da_alloc 옵션이 설정되면 애플리케이션은 데이터 지속성을 보장하기 위해 명시적으로 fsync를 사용해야 합니다.
저널 I/O 우선 순위
기본적으로 저널 I/O우 우선 순위는 일반적인 I/O 우선 순위 보다 약간 높은 3입니다. 마운트 시 journal_ioprio 매개 변수로 저널 I/O의 우선 순위를 제어할 수 있습니다. journal_ioprio 값으로 사용할 수 있는 범위는 0에서 7이며 0이 가장 우선 순위가 높은 I/O가 됩니다.
다음 부분에서는 마운트 시 사용할 수 있는 일부 옵션에 대해서만 설명합니다. 마운트 옵션에 대한 보다 자세한 내용은 mount man 페이지에서 참조하십시오:
$ man mount

5.3.7.3. BTRFS 튜닝

Red Hat Enterprise Linux 7.0에서 BTRFS는 기술 프리뷰로 제공됩니다. 항상 튜닝은 시스템의 현재 워크로드에 기반하여 시스템을 최적화하기 위해 수행됩니다. 다음 부분에서는 BTRFS를 최적화하는 방법만을 다루며 생성 및 마운트 옵션의 경우 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Storage_Administration_Guide/ch-btrfs.htmlRed Hat Enterprise Linux 7 Storage Administration Guide에서 참조하십시오.
5.3.7.3.1. 데이터 압축
기본 압축 알고리즘은 zlib이지만 워크로드에 따라 이를 변경할 수 있습니다. 예를 들어 대량의 파일 I/O가 있는 단일 스레드가 있는 경우 lzo 알고리즘을 사용할 수 있습니다. 마운트시 옵션은 다음과 같습니다:
  • compress=zlib - 더 나은 압축 비율입니다. 이전 커널에 대해 기본값이며 사용 안전합니다. (기본값)
  • compress=lzo - 압축 속도는 빠르지만 zlib 만큼 압축하지 않습니다.
  • compress=no - 압축을 비활성화합니다. (커널 3.6부터 사용 가능)
  • compress-force=method - 비디오나 디스크 이미지와 같이 압축이 잘 되지 않는 파일의 경우 이러한 압축을 사용합니다. 사용 가능한 옵션은 compress-force=zlib 및 compress-force=lzo입니다.
마운트 옵션 추가 후 생성 또는 변경된 파일만 압축합니다. 기존 파일을 압축하려면 다음 명령을 사용합니다:
$ btrfs filesystem defragment -calg
alg는 zlib 또는 lzo가 됩니다
lzo를 사용하여 파일을 다시 압축하려면 다음 명령을 사용합니다:
$ btrfs filesystem defragment -r -v -clzo /

5.3.7.4. GFS2 튜닝

다음 부분에서는 GFS2 파일 시스템 포맷이나 마운트 시 사용할 수 있는 일부 튜닝 매개 변수에 대해 설명합니다.
디렉토리 간격
GFS2 마운트 지점의 최상위 디렉토리에 생성된 모든 디렉토리는 자동으로 간격을 두어 단편화를 줄이고 디렉토리에 쓰기 속도를 가속화합니다. 최상위 디렉토리와 같이 다른 디렉토리에 간격을 두려면 다음과 같이 T 속성과 함께 디렉토리를 표시합니다. 여기서 dirname은 간격을 두려는 디렉토리 경로로 변경합니다.
# chattr +T dirname
chattre2fsprogs 패키지 일부로 제공됩니다.
경합 감소
GFS2는 클러스터 노드 간 통신을 필요로 하는 글로벌 잠금 메카니즘을 사용합니다. 여러 노드에서 파일 및 디렉토리 경합이 발생하면 성능이 저하됩니다. 여러 노드에서 공유되는 파일 시스템 공간을 최소화하여 캐시 무효화 위험을 감소시킬 수 있습니다.