6.5. GFS2 잠금 덤프를 사용하여 GFS2 성능 문제 해결


GFS2 캐싱을 비효율적으로 사용하기 때문에 클러스터 성능이 저하되는 경우 대규모 I/O 대기 시간이 증가할 수 있습니다. GFS2의 잠금 덤프 정보를 사용하여 문제의 원인을 확인할 수 있습니다.

debugfs/sys/kernel/debug/ 에 마운트되었다고 가정하면 debug2 잠금 덤프 정보를 debugfs 파일에서 수집할 수 있습니다.

/sys/kernel/debug/gfs2/fsname/glocks
Copy to Clipboard

파일의 내용은 일련의 행입니다. 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 홀더 플래그의 의미를 보여줍니다.

표 6.1. 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

더티

이 잠금을 해제하기 전에 데이터가 디스크로 플러시해야 합니다.

표 6.2. Glock holder 플래그
플래그이름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 유형의 의미를 보여줍니다.

표 6.3. Glock 유형
유형 번호잠금 유형사용

1

trans

트랜잭션 잠금

2

inode

inode 메타데이터 및 데이터

3

Rgrp

리소스 그룹 메타데이터

4

meta

수퍼 블록

5

Iopen

inode 마지막 더 가까운 탐지

6

flock

flock(2) syscall

8

할당량

할당량 작업

9

journal

비트랜스커뮤니스

확인된 glock이 다른 유형인 경우 3:(리소스 그룹) 유형일 가능성이 높습니다. 일반 부하에서 다른 유형의 glock 대기 중인 상당한 프로세스 수가 표시되면 이를 Red Hat 지원에 보고합니다.

리소스 그룹 잠금에 대기 중인 대기 요청이 여러 개 표시되면 이에 대한 여러 가지 이유가 있을 수 있습니다. 하나는 파일 시스템의 리소스 그룹 수와 비교하여 많은 수의 노드가 있다는 것입니다. 또 다른 하나는 파일 시스템이 매우 완전할 수 있다는 것입니다 (중대적으로, 자유 블록을 더 긴 검색 등). 두 경우의 상황은 더 많은 스토리지를 추가하고 gfs2_grow 명령을 사용하여 파일 시스템을 확장하여 개선할 수 있습니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat