SSD 읽기/쓰기 성능을 측정하고 싶었고 dd 및 gnome-disks를 사용하여 몇 가지 제안 사항을 찾았습니다. (제가 이해한 바로는 hdpart는 디스크 자체를 사용하지 않고 캐시된 데이터만 사용하므로 관련이 없습니다.)
문제는 이러한 도구를 사용하여 다른 결과를 얻고 있다는 것이며 왜 이런 일이 발생하는지 알고 싶습니다.
rootfs는 로컬 내부 eMMC에서 마운트되고 SSD에는 ext4 파일 시스템이 마운트됩니다.
감사해요
답변1
긴 이야기 짧게
둘 다부적절한스토리지 성능을 테스트하는 방법. 둘 다 시스템 스토리지 성능에 대해 아무 말도 하지 않으며 dd는 SSD 성능에 대해 거의 아무 말도 하지 않습니다(그러나 저는 dd보다 gnome의 벤치마크를 선호하는데 이는 스토리지를 측정하는 완전히 잘못된 방법입니다).
이는 fio스토리지 성능을 테스트하는 올바른 방법으로 널리 알려져 있습니다.
설명하다
스토리지 하위 시스템 등에 대한 다양한 최적화 옵션이 있습니다.
dsync사용을 선택하세요동기식 입력/출력, 이는 루프와 유사함을 의미합니다. 요청을 보내고, 완료될 때까지 대기(폴링)하고, 다음 요청을 보내는 식입니다. 적절한 비동기 시나리오에서는 이전 요청이 계속 실행되는 동안 다음 요청을 대기열에 넣어 CPU 주기를 낭비하게 되므로 속도가 느려집니다. 또한 최신 SSD가 제공하는 병렬성을 최대한 활용할 수 없습니다.
게다가 처리량은 스토리지에 대한 유일한 측정 기준이 아니며 확실히 가장 중요한 측정 기준도 아닙니다. 그건 그렇고, 백업 및 파일 서비스에만 중요합니다. 자주숨어있는가장 큰 관심사이며 언급된 평행성은 높이 평가되어야 합니다. 예를 들어 스토리지 대기 시간은 ACID 원칙에 따라 OLTP 데이터베이스의 성능을 정의합니다.
또한 대기 시간과 병렬 처리는 함께 스토리지를 비교하는 데 자주 사용되는 "초당 I/O 작업" 지표를 정의하지만 IOPS에 따라 어떤 작업이 수행될지 예측하기 어렵기 때문에 이 지표도 모호합니다.
그럼에도 불구하고 이는 SSD가 실제로 Rust 기반 회전 솔루션보다 뛰어난 성능을 보이는 지표입니다. 10GiB/s 처리량과 100방향 병렬 처리를 갖춘 100개의 HDD로 RAID 어레이를 구축할 수 있으며 여전히 일반 HDD의 대기 시간을 보여줄 수 있습니다. 그런 관점에서 볼 때 특정 데이터베이스 로드에서는 성능이 600MiB/s보다 낮습니다. SSD.
귀하의 도구 중 어느 것도 병렬성에 대해 언급하지 않고 gnome의 도구만 대기 시간("액세스 시간"이라고 함)을 언급합니다.
fio반면에 각 요청에 대한 대기 시간 분포(기본적으로 0.1밀리초 내에 처리된 요청 수, 0.1~0.2 사이의 요청 수 등을 나타내는 히스토그램)를 표시하므로 애플리케이션을 구축할 수 있습니다. 실제 기대치는 다음과 같습니다. 해당 스토리지에서 배포가 수행됩니다. 이를 통해 병렬성을 탐색할 수 있습니다. 설정된 목표 대기 시간을 보장하기 위해 대기열 및 병렬 처리 매개변수를 찾는 모드도 있습니다. 이는 "내 서버가 속도 저하 없이 유지할 수 있는 사용자/동시 요청 수는 얼마나 됩니까?"와 같은 질문에 답해야 할 때 유용합니다.