6.5. GFS2 잠금 덤프를 사용하여 GFS2 성능 문제 해결
GFS2 캐싱을 비효율적으로 사용하기 때문에 클러스터 성능이 저하되는 경우 대규모 I/O 대기 시간이 증가할 수 있습니다. GFS2의 잠금 덤프 정보를 사용하여 문제의 원인을 확인할 수 있습니다.
debugfs
가 /sys/kernel/debug/
에 마운트되었다고 가정하면 debug2 잠금 덤프 정보를 debugfs
파일에서 수집할 수 있습니다.
/sys/kernel/debug/gfs2/fsname/glocks
/sys/kernel/debug/gfs2/fsname/glocks
파일의 내용은 일련의 행입니다. G:로 시작하는 각 줄은 하나의 glock을 나타내며, 다음 줄은 파일에서 바로 glock과 관련된 정보 항목을 하나의 공백으로 나타냅니다.
debugfs
파일을 사용하는 가장 좋은 방법은 cat
명령을 사용하여 파일의 전체 콘텐츠 복사본을 사용하는 것입니다(애플리케이션에 많은 RAM과 캐시된 inode가 있는 경우 시간이 오래 걸릴 수 있음) 애플리케이션에서 문제가 발생하는 동안 나중에 결과 데이터를 확인하는 것입니다.
debugfs
파일의 두 사본을 몇 초 또는 1분 또는 2분 후에 생성하는 것이 유용할 수 있습니다. 동일한 glock 번호와 관련된 두 가지 추적의 보유자 정보를 비교하면 워크로드가 진행 중인지(중지 느림)인지를 알 수 있습니다(항상 버그이므로 Red Hat 지원에 즉시 보고해야 함).
H: (holders)로 시작하는 debugfs
파일의 행은 부여되거나 부여 대기 중인 잠금 요청을 나타냅니다. holders line f:의 flags 필드는 다음을 보여줍니다. 'W' 플래그는 대기 요청을 나타냅니다. 'H' 플래그는 부여된 요청을 나타냅니다. 많은 수의 대기 요청이 있는 glock은 특정 경합이 발생하는 것일 수 있습니다.
다음 표에서는 glock 플래그와 glock 홀더 플래그의 의미를 보여줍니다.
플래그 | 이름 | meaning |
---|---|---|
b | 차단 | 잠긴 플래그가 설정된 경우 유효하고 DLM에서 요청된 작업이 차단될 수 있음을 나타냅니다. 이 플래그는 demotion 작업 및 "try" 잠금을 위해 지워집니다. 이 플래그를 사용하면 다른 노드에서 demote 잠금으로 걸리는 시간과 관계없이 DLM 응답 시간 통계를 수집할 수 있습니다. |
d | 보류 중인 데모 | Deploying (remote) demote 요청 |
D | 데모 | 데모 요청(로컬 또는 원격) |
f | 로그 플러시 | 이 glock을 해제하기 전에 로그를 커밋해야합니다. |
F | 설정되지 않았습니다. | 원격 노드의 응답 무시 - 복구가 진행 중입니다. 이 플래그는 다른 메커니즘을 사용하는 파일 시스템 정지와 관련이 없지만 복구에서만 사용됩니다. |
i | 진행 중 검증 | 이 glock 아래의 페이지를 무효화하는 과정에서 |
I | 초기 | DLM 잠금이 이 glock과 연결될 때 설정 |
l | 잠긴 | glock이 상태를 변경하는 중입니다. |
L | LRU | LRU 목록에 glock이 있을 때 설정 |
o | 개체 | glock이 오브젝트와 연결될 때 설정(즉, 유형 2 glock의 inode, 유형 3 glock의 리소스 그룹) |
p | 진행 중인 데모 | glock은 데모 요청에 응답하는 중입니다. |
q | Queue | 홀더가 glock에 대기 중일 때 설정된 후 glock이 유지될 때 지워지지만 남아 있는 홀더는 없습니다. 알고리즘의 일부로 사용되는 경우 glock의 최소 대기 시간을 계산합니다. |
r | 응답 보류 | 원격 노드에서 수신한 응답 처리 대기 |
y | 더티 | 이 잠금을 해제하기 전에 데이터가 디스크로 플러시해야 합니다. |
플래그 | 이름 | meaning |
---|---|---|
a | async | glock 결과를 기다리지 마십시오 (나중에 결과에 대해 폴링할 수 있음) |
A | Any | 모든 호환 가능 잠금 모드가 허용됩니다. |
c | 캐시 없음 | 잠금 해제 시 DLM이 즉시 잠길 수 있습니다. |
e | 만료 없음 | 후속 잠금 취소 요청 무시 |
E | 정확한 | 정확한 잠금 모드가 있어야 합니다. |
F | 첫 번째 | 이 잠금에 대해 부여해야 할 첫 번째 소유자 설정 |
H | 홀더 | 요청된 잠금이 허용됨을 나타냅니다. |
p | 우선 순위 | 대기열 헤드에 있는 대기열 보유자 |
t | try | "try" 잠금 |
T | 1CB 시도 | 콜백을 전송하는 "try" 잠금 |
W | wait | 완료 요청 대기 중 설정 |
문제를 일으키는 glock을 확인한 다음, 다음 단계는 관련 inode를 찾는 것입니다. glock 번호 (n: 라인)는 이를 나타냅니다. 이는 형식/번호 이며 유형이 2인 경우 glock은 inode glock이고 숫자는 inode 번호입니다. inode를 추적하려면 find -inum 번호를
실행합니다. 여기서 number 는 glocks 파일의 16진수 형식에서 변환된 inode 번호입니다.
잠금 경합이 발생할 때 파일 시스템에서 find
명령을 실행하면 문제가 더 나빠질 수 있습니다. contended inodes를 찾을 때 find
명령을 실행하기 전에 애플리케이션을 중지하는 것이 좋습니다.
다음 표에서는 다른 glock 유형의 의미를 보여줍니다.
유형 번호 | 잠금 유형 | 사용 |
---|---|---|
1 | trans | 트랜잭션 잠금 |
2 | inode | inode 메타데이터 및 데이터 |
3 | Rgrp | 리소스 그룹 메타데이터 |
4 | meta | 수퍼 블록 |
5 | Iopen | inode 마지막 더 가까운 탐지 |
6 | flock |
|
8 | 할당량 | 할당량 작업 |
9 | journal | 비트랜스커뮤니스 |
확인된 glock이 다른 유형인 경우 3:(리소스 그룹) 유형일 가능성이 높습니다. 일반 부하에서 다른 유형의 glock 대기 중인 상당한 프로세스 수가 표시되면 이를 Red Hat 지원에 보고합니다.
리소스 그룹 잠금에 대기 중인 대기 요청이 여러 개 표시되면 이에 대한 여러 가지 이유가 있을 수 있습니다. 하나는 파일 시스템의 리소스 그룹 수와 비교하여 많은 수의 노드가 있다는 것입니다. 또 다른 하나는 파일 시스템이 매우 완전할 수 있다는 것입니다 (중대적으로, 자유 블록을 더 긴 검색 등). 두 경우의 상황은 더 많은 스토리지를 추가하고 gfs2_grow
명령을 사용하여 파일 시스템을 확장하여 개선할 수 있습니다.