6.4. GFS2로 성능 튜닝

일반적으로 어려운 애플리케이션이 상당한 성능 이점을 얻기 위해 데이터를 저장하는 방법을 변경할 수 있습니다.

어려운 애플리케이션의 일반적인 예는 이메일 서버입니다. 각 사용자(mbox ) 또는 각 사용자에 대한 파일이 포함된 spool 디렉터리에 각 메시지에 대한 파일이 포함된 디렉터리(maildir)와 함께 배치되는 경우가 많습니다. commands를 통해 요청이 도착하면 각 사용자에게 특정 노드에 선호도를 부여하기 위한 최적의 배열이 있습니다. 이렇게 하면 이메일 메시지를 보고 삭제하라는 요청이 하나의 노드의 캐시에서 제공되는 경향이 있습니다. 해당 노드가 실패하면 다른 노드에서 세션을 다시 시작할 수 있습니다.

메일이 SMTP를 통해 도착하면 기본적으로 특정 사용자의 이메일을 특정 노드에 전달할 수 있도록 개별 노드를 다시 설정할 수 있습니다. 기본 노드가 작동하지 않으면 수신 노드에서 사용자의 메일 스풀에 메시지를 직접 저장할 수 있습니다. 이 설계는 일반적인 사례에서 하나의 노드에 캐시된 특정 파일 집합을 유지하기 위한 것으로, 노드 장애 발생 시 직접 액세스가 허용됩니다.

이 설정을 사용하면 GFS2의 페이지 캐시를 최대한 활용할 수 있으며 redfish 또는 ProfileBundle 에도 관계없이 애플리케이션에 대한 실패를 투명하게 수 행할 수 있습니다.

백업은 종종 또 다른 어려운 영역입니다. 다시 말해, 가능한 경우 특정 inode 집합을 캐싱하는 노드에서 직접 각 노드의 작업 세트를 백업하는 것이 좋습니다. 일반 시점에 실행되는 백업 스크립트가 있고, 이 경우 GFS2에서 실행되는 애플리케이션의 응답 시간에 급증하는 것처럼 보이는 백업 스크립트가 있는 경우 클러스터가 페이지 캐시를 가장 효율적으로 사용하지 못할 가능성이 높습니다.

분명히 백업을 수행하기 위해 응용 프로그램을 중지 할 수있는 위치에있는 경우 이것은 문제가되지 않습니다. 반면 백업이 한 노드에서만 실행되는 경우 파일 시스템의 많은 부분을 완료한 후 다른 노드의 후속 액세스로 성능 저하가 발생합니다. 다음 명령을 사용하여 백업이 완료된 후 백업 노드에서 vGPU 페이지 캐시를 삭제하여 일정 범위까지 완화할 수 있습니다.

echo -n 3 >/proc/sys/vm/drop_caches

그러나 이 방법은 각 노드에서 작업 집합이 주로 클러스터 전체에서 읽기 전용인지 또는 단일 노드에서 대부분 액세스할 수 있도록 주의를 기울이는 것이 좋지 않습니다.