현재 복제 모드에서 Gluster 3.5가 설치된 2 노드 클러스터를 사용 중입니다. 이것은 서버 하드웨어에 실제 3- 노드 클러스터를 구현하기 전에 시스템에서 통찰력을 얻기위한 것입니다.GlusterFS는 복제 된 설정에서 디렉토리 성능을 읽습니다. 무엇이 잘못 되었습니까? 최적화하는 방법?
테스트 하드웨어는 최고급 제품이 아닙니다. Intel Atom D2550과 Intel i5가 Gbit 포트의 이더넷 교차 케이블을 통해 함께 연결되었습니다.
Gluster 파일 시스템에는 나중에 (다른 하드웨어에서) 처리해야하는 실제 사용법과 비슷한 약 20,000 개의 대부분 작은 파일 (기본적으로 데비안 설치)이 있습니다.
일부 오래된 소프트웨어는 벽돌에서 실행되므로 불행히도 이러한 파일 대부분을 주기적으로 폴링해야합니다. 폴링 파일 통계가 대기 시간 일 때 요인이됩니다. 글루 스터 FS (GlusterFS) 각 stat의 다른 노드를 폴링하기 때문에이 어쩌면 너무 느린
# time find | wc -l
22174
real 0m18.542s
user 0m0.224s
sys 0m0.789s
:
나는 간단한 테스트 (글루 스터 FS (GlusterFS)는 Gluster 노드 자체에 장착)했다.벽돌 저장 디렉토리에서 직접 폴링 할 때 두 번째 시험에서부터 0.16 초 범위의 타이밍을 얻습니다 (예상대로 모든 것이 캐시에서 읽혀질 가능성이 높습니다).
# time find | wc -l 22174 real 0m16.445s user 0m0.213s sys 0m0.702s 그러나, 나는 꽤 비슷한 결과를 얻을, 하나 개의 노드 만 왼쪽 있다? 이 경우 Gluster의 속도가 느려 집니까?
일반적으로 GlusterFS 중복 설정에서 읽기 대기 시간을 최소화하려면 어떻게해야합니까? dirlist 성능을 향상시킬 수 있다면, 파일 시스템 dirlist를 폴링하는 것이 충돌 후 복구 중에 일시적으로 실제 상황에 뒤쳐지면 문제가되지 않습니다.