최근에 새 서버(dd 사용)에서 일부 성능 테스트를 수행했는데 왜 읽기 성능이 쓰기 성능보다 훨씬 나쁜지 궁금합니다. 다른 접근 방식이 있어야 하지 않나요?
두 테스트의 파일 크기는 550GB, 읽기: 초: 3704MB/s: 148
쓰기: 초 단위: 1539 MB/초 단위: 357
쓰기 명령:
time sh -c "dd if=/dev/zero of=/local/postgresql/bigfile
bs=8k count=67108864 && sync"
읽기 명령:
time dd if=/local/postgresql/bigfile of=/dev/null bs=8k
bash 시간 명령 출력:
real: 61m44.335s
user: 0m12.721s
sys: 10m35.884s
Bonnie++ 결과 명령:
bonnie++ -f -D -n 0 -u root -d /local/postgresql/
결과적으로 파일 크기는 RAM 크기의 두 배가 됩니다.
쓰다:
419918K/초
읽다:
~ 187,000K/초
답변1
실제로 캐시가 아닌 디스크에 쓰고 있는지 확인하려면 쓰기 동기화 플래그로 성능을 테스트해야 합니다. conv=fdatasync쓰기가 완료된 후 버퍼를 강제로 동기화하는 데 사용됩니다 . 바라보다여기더 알아보기.
time dd .... conv=fdatasync
읽기 테스트의 경우 테스트하기 전에 캐시를 삭제합니다.
flush
echo 3 | sudo tee /proc/sys/vm/drop_caches
time dd ....
답변2
어떤 명령을 사용하셨나요? dd하다매우성능과 관련된 사항은 옵션에 따라 다릅니다.
하지만 당신이 쓴 내용으로 판단하면,
나는 당신이 대략적으로 요구 사항에 따라 디스크에서 읽을 작은 덩어리로 읽고 있다고 생각합니다.
dd작은 청크를 쓸 수 있으며, 해당 청크는 기록될 때가 아니라 커널이 그렇게 할 시간이 있다고 생각할 때 디스크에 기록됩니다 .
그러면 이미 차이점이 설명될 것입니다. 그렇죠?
답변3
나는 이것으로부터 의미 있는 벤치마크를 얻을 수 있을지 의심스럽습니다 dd. dd다양한 장치 간에 수행되는 대규모 순차 읽기 또는 대규모 순차 비동기 쓰기를 보여줍니다. 워크로드가 주로 이러한 파일 시스템 간의 대용량 파일 복사로 구성되어 있는 한 괜찮습니다. 하지만 그게 당신의 업무량인 것 같아요.
가장 좋은 방법은 디스크 사용량을 분석하고 실제 I/O 벤치마크 제품군(링크 bonnie++등)을 사용하여 다양한 조정 가능 매개변수 변경의 효과를 테스트하는 것입니다. 데이터베이스의 경우 무작위 읽기가 많이 발생할 것으로 예상됩니다. 정기적인 백업을 통해 마스터 데이터 파일에 대한 noatime작업을 설정 하고 수행하는 data=writeback것이 아마도 지금까지 보유한 정보로 할 수 있는 최선의 방법일 것입니다.
더 큰 질문에 대답하려면 비동기 쓰기(예: 에서 수행한 작업 dd)가 메모리에 버퍼링되고 디스크에 커밋될 수 있기 때문입니다. 그들은유형대기열과 버퍼가 가득 찰 수 있는 한 더 많이 쌓기 전에 디스크에 커밋하여 다시 사용할 수 있을 때까지 기다려야 합니다.
반면에 읽기는 정의에 따라 I/O 바인딩되므로 일반적으로 동일한 비동기 작업을 수행하지 않습니다. read_ahead_kb가까운 미래의 워크로드 요구 사항에 맞춰 더 많은 순차 데이터를 메모리로 가져오기 위해 이와 같은 작업을 시도할 수 있습니다 .
그것이 지금 내가 생각할 수 있는 대답이다. 질문이 있으시면 알려주시기 바랍니다.