1.4.2. GFS2 잠금 덤프를 사용하여 GFS2 성능 문제 해결
GFS2 캐싱의 비효율적 사용으로 인해 클러스터 성능에 영향을 받고 있는 경우 I/O 대기 시간이 길고 또한 늘어나고 있을 수 있습니다. GFS2의 잠금 덤프를 사용하여 문제의 원인을 확인할 수 있습니다.
GFS2 잠금 덤프 정보는
debugfs
파일에서 수집할 수 있으며 이는 다음과 같은 경로에 있습니다. 여기서 debugfs
는 /sys/kernel/debug/
에 마운트되어 있다고 가정합니다:
/sys/kernel/debug/gfs2/fsname/glocks
/sys/kernel/debug/gfs2/fsname/glocks
파일의 내용은 행 집합으로 구성되어 있습니다. G:로 시작하는 각 행은 하나의 glock을 나타내며 하나의 공백으로된 다음 행은 파일에서 바로 앞에 있는 glock과 관련된 정보의 항목을 나타냅니다.
debugfs
파일을 사용하는 데 있어서 가장 좋은 방법은 cat
명령을 사용하여 응용 프로그램에 문제가 발생하면 파일의 전체 내용의 복사본을 얻어 (대용량 RAM과 캐시된 inode가 많은 경우 시간이 걸릴 수 있음) 나중에 결과 데이터를 살펴보는 것입니다.
참고
debugfs
파일 복사본을 두 개 만들어 두는 것이 유용할 수 있습니다. 하나는 다른 사본 사용 후 몇 초 후 또는 몇 분 후에 사용합니다. 동일한 glock 번호와 관련된 두 개의 추적 홀더 정보를 비교하면, 작업 부하가 진행되고 있는지 (즉 단순한 속도 저하) 또는 걸려있는 상태 (이 경우 버그로 Red Hat 지원팀에 즉시 보고해야 함)인지 가려낼 수 있습니다.
H: (홀더)로 시작하는
debugfs
파일의 행은 부여되거나 부여 대기 중인 잠금 요청을 나타냅니다. 홀더 행 f: 에 있는 플래그 필드는 다음을 나타냅니다. 'W' 플래그는 대기 중인 요청을 나타내고, 'H' 플래그는 부여된 요청을 나타냅니다. 대기 중인 요청이 많은 glocks는 경합이 발생할 가능성이 높습니다.
표 1.2. “Glock 플래그 ”에서는 다른 glock 플래그의 의미를 보여줍니다. 표 1.3. “Glock 홀더 플래그 ”에서는 다른 glock 홀더 플래그의 의미를 보여줍니다.
플래그 | 이름 | 의미 |
---|---|---|
d | 강등 보류 (Pending demote) | 보류된 (원격) 강등 요청 |
D | 강등 (Demote) | 강등 요청 (로컬 또는 원격) |
f | 로그 플러시 (Log flush) | glock을 해제하기 전 로그를 커밋해야 함 |
F | 동결 (Frozen) | 원격 노드에서 회신이 무시됨 - 복구 진행 중. |
i | 비활성화 진행 중 (Invalidate in progress) | glock 하에 있는 페이지 비활성화를 진행 중 |
I | 초기화 (Initial) | DLM 잠금 기능이 glock과 관련된 경우에 설정됨 |
l | 잠금 (Locked) | glock 상태 변경 중 |
p | 강등 진행 중 (Demote in progress) | glock은 강등 요청에 응답하는 중 |
r | 응답 보류 (Reply pending) | 원격 노드에서 받은 응답을 처리 대기 중 |
y | 더티 (Dirty) | glock을 해제하기 전에 데이터를 디스크에 플러시해야 함 |
플래그 | 이름 | 의미 |
---|---|---|
a | 비동기 | glock 결과를 기다리지 않음 (결과를 나중에 poll함) |
A | 모두 | 호환되는 잠금 모드는 모두 사용 가능 |
c | 캐시 없음 | 잠금을 해제하면 즉시 DLM 잠금으로 강등됨 |
e | 만기 없음 | 차후의 잠금 취소 요청을 무시함 |
E | 완전 일치 | 완전 일치하는 잠금 모드로 해야함 |
F | 첫번째 | 홀더에 첫번째로 잠금이 부여된 경우 설정됨 |
H | 홀더 | 요청된 잠금이 부여되었음을 나타냄 |
p | 우선 순위 | 대기열의 선두에 있는 인큐 홀더 |
t | 시도 | "try" 잠금 |
T | 1CB 시도 | 콜백을 보내는 "try" 잠금 |
W | 대기 | 요청이 완료될 때까지 대기 중으로 설정 |
문제의 원인이 되고 있는 glock을 확인한 후, 관련된 inode를 찾습니다. glock 번호 (G: 행의 n:)에 나와 있습니다. type/number의 형식이며, type이 2이면, glock은 inode glock이고 number는 inode 번호가 됩니다. inode를 추적하려면,
find -inum number
를 실행합니다. 여기서 number는 glocks 파일에서 16 진수에서 10 진수로 변환하는 inode 번호입니다.
참고
잠금 경합이 발생할 경우, 파일 시스템에서
find
를 실행하면 상황이 악화될 가능성이 높습니다. 경합하는 inode를 찾을 경우 find
를 실행하기 전 응용 프로그램을 중지하는 것이 좋습니다.
표 1.4. “Glock 유형 ”에서는 다른 glock 유형의 의미를 보여줍니다.
유형 번호 | 잠금 유형 | 사용 |
---|---|---|
1 | Trans | 트랜젝션 잠금 |
2 | Inode | Inode 메타데이터 및 데이터 |
3 | Rgrp | 리소스 그룹 메타데이터 |
4 | Meta | 슈퍼 블록 |
5 | Iopen | 가장 가까운 마지막 Inode 검색 |
6 | Flock | flock (2) syscall |
8 | Quota | Quota 작업 |
9 | Journal | 저널 뮤텍스 |
확인된 glock이 다른 유형이면, 이는 유형 3: (리소스 그룹)일 것입니다. 일반 부하에서 다른 glock 유형을 기다리고 있는 여러 프로세스가 있을 경우 Red Hat 지원팀에 알려주십시오.
리소스 그룹 잠금 대기열에 여러 대기 요청이 나타나는 경우에는 몇 가지 이유가 있습니다. 그 중 하나로 파일 시스템의 리소스 그룹 수에 비해 노드 수가 많은 경우가 그러하며 파일 시스템이 꽉 찬 경우도 그러합니다 (평균적으로 길게 여유 블록 검색 시간을 요청). 두 경우 모두 스토리지를 추가하고
gfs2_grow
명령을 사용하여 파일 시스템을 확장하여 향상될 수 있습니다.