Qumulo에서 사용하는 fio, 인기 있는 오픈 소스 IO 벤치마킹 도구로 파일 시스템의 성능을 측정하고 회귀를 감지합니다. 다양한 IO 모드와 패턴을 지원하는 일종의 스위스 군용 칼입니다. 편리한 기능 중 하나는 클라이언트/서버 모드로, 여러 시스템에서 동시에 스토리지 클러스터로 트래픽을 보낼 수 있습니다. 이는 하나의 스토리지 클러스터에 모두 쓰는 렌더 노드 팜과 같은 많은 실제 스토리지 워크로드를 시뮬레이션하는 데 유용합니다. 이를 통해 클러스터 중 하나가 유지할 수 있는 처리량을 특성화할 수 있습니다.
회귀를 안정적으로 감지하려면 일관된 측정이 중요합니다. 소프트웨어 변경으로 인해 속도가 빨라지거나 느려지지 않는 한 좋은 벤치마크는 매번 거의 동일한 결과를 산출해야 합니다. 다음은 중요한 편차를 훨씬 쉽게 찾아낼 수 있도록 매끄럽고 일관된 결과를 제공하는 데 도움이 되는 세 가지 모범 사례입니다.
1. 를 사용 fio 시간 기반 모드
첫 번째는 매우 간단합니다. fio 각 작업이 수행하는 작업의 양을 제어하는 두 가지 기본 방법인 크기 기반 및 시간 기반이 있습니다. 크기 기반 모드에서 각 스레드는 고정된 양의 데이터를 쓰거나 읽은 다음 중지합니다. 모든 작업에서 전송한 총 데이터 양을 마지막 작업이 완료되는 데 걸린 시간으로 나눈 값이 측정된 처리량입니다.
이 접근 방식에는 문제가 있습니다. 모든 작업이 동시에 작업을 완료하는 것은 아닙니다. 프로세스 일정의 일반적인 변동은 한 작업이 다른 작업보다 클러스터 처리량에서 약간 더 큰 부분을 얻거나 네트워크 대역폭의 공정한 부분보다 더 많이 차지함을 의미할 수 있습니다. 이 다이어그램은 각각 10기가바이트의 데이터를 전송하는 XNUMX개의 작업을 보여줍니다.
한 작업을 완료하는 데 다른 작업보다 시간이 조금 더 오래 걸리기 때문에 측정 간격에는 하나의 작업만 실행되는 작지만 예측할 수 없는 기간이 포함됩니다. 결과에 노이즈가 발생합니다.
이 문제에 대한 해결책은 fio 작업 매개변수입니다. 시간 기반 과 런타임. 예를 들어, 시간 기반=1 과 런타임=60초 모든 작업이 XNUMX초 동안 실행된 다음 중지됩니다. 이렇게 하면 측정 간격에서 클러스터가 항상 최대 부하에서 작동하도록 하여 보다 일관된 측정을 수행할 수 있습니다.
2. exec_prerun으로 장벽 도입
작업을 일찍 또는 늦게 끝내는 것이 측정 지터의 유일한 원인은 아닙니다! 또 다른 미묘한 문제가 있습니다. 각 fio 작업은 즉시 작업을 시작하지 않습니다. 먼저 일부 설정 및 하우스키핑을 수행하고 작업할 파일에 대한 정보를 수집하고 많은 스탯 및 기타 메타데이터 요청. 이것은 특히 작업에 많은 파일이 있는 경우 약간의 시간이 걸릴 수 있으며 각 작업이 준비하는 데 걸리는 시간은 위에서 언급한 것과 같은 이유로 다를 수 있습니다. 고정된 시간 동안 각 작업을 실행하는 것은 좋지만 그렇지 않으면 작업이 동시에 완료되지 않습니다. 스타트 동시에!
fio 자체에는 작업 시작 시간을 조정하는 메커니즘이 없기 때문에 이 문제에 대한 솔루션은 조금 더 복잡합니다. 운 좋게도 여기에서 "유연한 I/O 테스터"라는 이름에 걸맞게 우리가 필요로 하는 정확히 스위스 군용 칼 부착물을 제공합니다. exec_prerun, 작업이 작업을 시작하기 직전에 실행할 명령을 제공할 수 있는 작업 매개변수.
로 알려진 기본 다중 처리 기술에 익숙할 수 있습니다. 장벽: 여러 프로세스가 장벽에서 대기할 수 있습니다. 장벽은 예상되는 참가자의 수를 알고 있으며 모든 참가자가 대기할 때까지 프로세스가 계속되도록 허용하지 않습니다.
여러 시스템 간의 조정을 위해 Python에서 간단한 TCP 장벽 구현을 만들었습니다. 별로 할 것이 없습니다. N개의 연결을 기다리는 서버가 있습니다.
def 서버(엔드포인트, N):
s = 소켓.소켓(AF_INET, 소켓.SOCK_STREAM)
s.bind(종료점)
s.듣기(N)
연결 = []
for _ in 범위(N):
connection.append(s.accept())
# 일단 우리가 여기에 있으면 우리는 모두가 파티에 있다는 것을 압니다!
for 콘, _ in 사이:
conn.sendall(가자!')
그리고 서버에 연결하고 갈 수 있다는 말을 기다리는 클라이언트:
def 클라이언트(엔드포인트):
s = 소켓.소켓(AF_INET, 소켓.SOCK_STREAM)
s.connect(종료점)
# 서버가 응답할 때까지 차단됩니다.
s.recv(3)
위의 코드는 명확성을 위해 단순화되었습니다. 실제로는 더 많은 오류 처리가 있습니다. 그런 다음 작업 파일에 다음과 같이 입력하기만 하면 됩니다.
exec_prerun=./barrier_client.py
...이제 우리의 작업은 동일한 시간 동안 실행될 뿐만 아니라 스타트 동시에 실행 중입니다. 하지만 물론 더 있습니다!
3. 클라이언트 버퍼를 cap으로 제한 fsync() 파멸의 길
마지막으로, 다음과 같은 직업에 특정한 변동성의 원인이 있습니다. 쓰기 데이터. 기본적으로 대부분의 운영 체제(및 fio), 파일에 쓰여진 데이터는 완충 된; 그것은 쓰다() syscall은 데이터를 시스템 버퍼에 넣은 다음 즉시 반환합니다. 그런 다음 운영 체제는 로컬 디스크이든 네트워크를 통한 원격 저장소이든 관계없이 이 데이터를 저장소에 비동기식으로 플러시합니다.
이것이 왜 중요한가? 음, 벤치마크에서 부주의한 버퍼링은 부정 행위입니다! 만약에 fio 는 300초 동안 60GB의 데이터를 작성했다고 생각하지만 클라이언트 시스템에 많은 RAM이 있기 때문에 해당 데이터의 50GB가 여전히 로컬로 버퍼링되고 테스트 대상 스토리지가 달성한 처리량을 과대평가할 것입니다. 이를 방지하기 위해 우리는 end_fsync 모든 작업이 쓰기가 완료된 후 버퍼를 플러시하도록 하는 작업 매개변수.
불행히도 이것은 또 다른 부작용이 있습니다. fsync() 대상이 아닙니다 fio의 작업 타이머 – 변동성의 또 다른 원인! 설상가상으로 Linux는 기본적으로 시스템 사용 가능한 메모리의 백분율을 사용하여 언제 백그라운드 플러시를 시작할지 결정합니다... 그리고 우리 랩 클라이언트 풀의 모든 컴퓨터에 동일한 양의 메모리가 있는 것은 아닙니다!
이 문제를 해결하는 것은 충분히 쉽습니다. 사용할 버퍼의 양을 Linux에 정확히 알릴 수 있습니다.
sysctl -w vm.dirty_bytes=2000000000
sysctl -w vm.dirty_Background_bytes=1000000000
이 경우 전체 버퍼가 1GB로 증가할 때 백그라운드 플러시가 시작되어야 하고 2GB에서 차단을 시작해야 한다고 지정했습니다. 쓰다() 전화. 여기서 정확한 값은 중요하지 않습니다. 1) 모든 클라이언트에서 동일하고, 2) 과도하게 많은 시간을 할애할 수 없을 만큼 작아야 합니다. fsync(), 3) 성능 병목 현상이 발생하지 않을 만큼 충분히 큽니다. 이 값은 우리가 실행하는 테스트에서 잘 작동합니다. 클라이언트는 여전히 최대 속도로 부하를 구동하지만 마지막에 플러시하는 데 걸리는 시간은 훨씬 더 일관되어 테스트 신호 대 잡음비가 향상됩니다.
(주의사항: 물론 직접/버퍼되지 않은 IO를 사용할 수 있습니다. fio, 이것은 이 문제를 피하는 또 다른 방법입니다. 그러나 이것은 다른 방식으로 작업 부하 특성을 변경하고 대부분의 응용 프로그램은 버퍼링된 IO를 사용하므로 일반적인 경우를 시뮬레이션하는 테스트가 필요합니다.)
결론
그래서 이것이 우리가 우리의 fio- 기반 성능 테스트는 부드럽고 일관된 결과를 제공합니다. 신호 대 잡음비가 양호하면 성능 회귀를 훨씬 더 쉽게 포착하고 수정할 수 있습니다. 물론 파일 시스템 속도를 계속 높일 때 성능 향상을 추적하는 데도 도움이 됩니다.
피오에 대해 자세히 알아보세요.
문의하기
데모 또는 무료 평가판 요청 Qumulo의 파일 데이터 플랫폼을 사용하여 페타바이트 규모에서 근본적으로 간단한 파일 데이터 관리를 볼 수 있습니다.
Qumulo 블로그 구독 고객 사례, 기술 통찰력, 제품 뉴스 및 모범 사례
