6.2. GFS2 노드 잠금

GFS2 파일 시스템에서 최상의 성능을 얻으려면 작업의 기본 이론을 이해하는 것이 중요합니다. 단일 노드 파일 시스템은 캐시와 함께 구현되며, 자주 요청된 데이터를 사용할 때 디스크 액세스 대기 시간을 제거할 수 있습니다. Linux에서 페이지 캐시(및 이전에 버퍼 캐시)는 이 캐싱 기능을 제공합니다.

GFS2에서 각 노드에는 디스크의 일부 데이터가 포함될 수 있는 자체 페이지 캐시가 있습니다. GFS2에서는 glocks (pronounced gee-locks)라는 잠금 메커니즘을 사용하여 노드 간 캐시의 무결성을 유지합니다. glock 하위 시스템은 DLM( Distributed Lock Manager )을 기본 통신 계층으로 사용하여 구현된 캐시 관리 기능을 제공합니다.

glocks는 노드별로 캐시 보호를 제공하므로 캐싱 계층을 제어하는 데 사용되는 inode당 하나의 잠금이 있습니다. 공유 모드(DLM 잠금 모드)에서 해당 glock이 부여된 경우: 그런 다음 해당 glock 아래의 데이터는 동시에 하나 이상의 노드에 캐시되므로 모든 노드가 데이터에 대한 로컬 액세스 권한을 가질 수 있습니다.

glock이 전용 모드 (DLM 잠금 모드)로 부여 된 경우: 그런 다음 단일 노드만 해당 glock 아래에 데이터를 캐시할 수 있습니다. 이 모드는 데이터를 수정하는 모든 작업에서 사용합니다(예: 쓰기 시스템 호출).

다른 노드에서 즉시 부여할 수 없는 glock을 요청하면 DLM은 현재 새 요청을 차단하여 잠금을 삭제하도록 요청하는 노드 또는 노드에 메시지를 보냅니다. glock을 삭제하는 것은 (대부분의 파일 시스템 작업의 기준에 따라) 긴 프로세스가 될 수 있습니다. 공유 glock을 삭제하려면 캐시를 무효화해야 하며, 이는 상대적으로 빠르고 캐시된 데이터의 양에 비례합니다.

배타적인 glock을 삭제하려면 로그 플러시가 필요하고 변경된 데이터를 디스크에 다시 작성한 다음 공유 glock에 따라 무효화가 발생합니다.

단일 노드 파일 시스템과 GFS2의 차이점은 단일 노드 파일 시스템에 단일 캐시가 있고 GFS2에는 각 노드에 별도의 캐시가 있다는 것입니다. 두 경우 모두 캐시된 데이터에 액세스하기 위한 대기 시간은 유사한 수준의 크기이지만 캐시되지 않은 데이터에 액세스하기 위한 대기 시간은 다른 노드가 이전에 동일한 데이터를 캐시한 경우 GFS2에서 훨씬 더 큽니다.

읽기(buffered ), stat read dir 과 같은 작업에는 공유 glock만 필요합니다. 쓰기 (buffered), EgressIP ,rmdir, unlink 와 같은 작업에는 배타적 glock이 필요합니다. 직접 I/O 읽기/쓰기 작업에서는 할당이 없는 경우 지연된 glock 또는 쓰기에 할당이 필요한 경우 독점 glock(즉, 파일 확장 또는 누락)이 필요합니다.

이 경우 다음과 같은 두 가지 주요 성능 고려 사항이 있습니다. 첫 번째 읽기 전용 작업은 모든 노드에서 독립적으로 실행될 수 있으므로 클러스터에서 매우 잘 병렬화됩니다. 두 번째, 배타적인 glock을 필요로 하는 작업에서는 동일한 inode에 대한 액세스를 위해 여러 노드가 제한되는 경우 성능을 줄일 수 있습니다. 따라서 각 노드에서 작업 세트를 고려하는 경우, 예를 들어 GFS2 파일 시스템 백업에 설명된 대로 파일 시스템 백업을 수행하는 경우와 같이 GFS2 파일 시스템 성능에 중요한 요소가 있습니다.

이로 인해 가능한 경우 애플리케이션이 이를 허용하는 noatime 또는 nodiratime 마운트 옵션을 최대한 사용하여 noatime 또는 nodiratime 마운트 옵션을 사용하는 것이 좋습니다. 이 경우 atime timestamp를 업데이트하기 위해 배타적 잠금이 필요하지 않습니다.

working set 또는 캐싱 효율성에 대한 우려가 있는 사용자를 위해 GFS2 파일 시스템의 성능을 모니터링할 수 있는 툴을 제공합니다. Performance Co-octets 및 GFS2 추적 지점.

참고

GFS2의 캐싱이 구현되는 방식으로 인해 다음 중 하나를 수행할 때 최상의 성능을 얻을 수 있습니다.

  • inode는 모든 노드에서 읽기 전용 방식으로 사용됩니다.
  • inode는 단일 노드에서만 작성되거나 수정됩니다.

파일 생성 및 삭제 중에 디렉터리에서 항목을 삽입 및 제거하는 것은 디렉터리 inode에 쓰는 것으로 계산됩니다.

이 규칙이 비교적 자주 손상되어 있음을 알리는 규칙이 중단될 수 있습니다. 이 규칙을 너무 자주 무시하면 심각한 성능 저하가 발생합니다.

읽기/쓰기 매핑만 있고 읽기/쓰기 매핑만 있는 GFS2의 파일을 mmap()하는 경우 이 파일은 읽기로만 계산됩니다.

noatime mount 매개변수를 설정하지 않으면 읽기에서도 파일 타임스탬프를 업데이트하기 위한 쓰기가 발생합니다. 특정 요구 사항이 없는 한 모든 GFS2 사용자가 no atime 으로 마운트해야 합니다.