내 NVMe가 SSD보다 느린 이유는 무엇입니까?

이 기사에서는 I/O 하위 시스템의 몇 가지 미묘한 차이와 이것이 성능에 미치는 영향을 살펴보겠습니다.

몇 주 전에 한 서버의 NVMe가 다른 서버의 SATA보다 느린 이유에 대한 질문을 받았습니다. 서버의 특성을 살펴보니 NVMe는 사용자 부문에서, SSD는 서버 부문에서 횡설수설한 질문이라는 것을 깨달았습니다.

분명히, 서로 다른 환경에서 서로 다른 부문의 제품을 비교하는 것은 옳지 않습니다. 그러나 이것이 완전한 기술적 답변은 아닙니다. 우리는 기초를 연구하고, 실험을 수행하고, 제기된 질문에 답할 것입니다.

fsync 란 무엇이며 어디에 사용됩니까?

드라이브 작업 속도를 높이기 위해 데이터는 버퍼링됩니다. 즉, 버퍼 내용을 드라이브에 저장할 수 있는 편리한 기회가 나타날 때까지 휘발성 메모리에 저장됩니다. 기회 기준은 운영 체제 및 드라이브 특성에 따라 결정됩니다. 정전이 발생하면 버퍼에 있는 모든 데이터가 손실됩니다.

파일의 변경 사항이 드라이브에 기록되고 중간 버퍼에 있지 않은지 확인해야 하는 여러 작업이 있습니다. 이 보증은 POSIX 호환 fsync 시스템 호출을 사용하여 얻을 수 있습니다. fsync 호출은 버퍼에서 드라이브로 강제로 쓰기를 수행합니다.

짧은 C 프로그램 형태의 인위적인 예제를 통해 버퍼의 효과를 보여드리겠습니다.

#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void) {
    /* Открываем файл answer.txt на запись, если его нет -- создаём */
    int fd = open("answer.txt", O_WRONLY | O_CREAT);
    /* Записываем первый набор данных */
    write(fd, "Answer to the Ultimate Question of Life, The Universe, and Everything: ", 71);
    /* Делаем вид, что проводим вычисления в течение 10 секунд */
    sleep(10);
    /* Записываем результат вычислений */
    write(fd, "42n", 3); 

    return 0;
}

주석은 프로그램의 동작 순서를 잘 설명합니다. "인생, 우주 및 그 모든 것에 대한 주요 질문에 대한 답변"이라는 텍스트는 운영 체제에 의해 버퍼링되며 "계산" 중에 재설정 버튼을 눌러 서버를 다시 시작하면 파일이 비어 있게 됩니다. 이 예에서는 텍스트 손실이 문제가 되지 않으므로 fsync가 필요하지 않습니다. 데이터베이스는 이러한 낙관론을 공유하지 않습니다.

데이터베이스는 동시에 많은 파일을 작업하는 복잡한 프로그램이므로, 데이터베이스 내 데이터의 일관성이 이에 달려 있기 때문에 작성한 데이터가 드라이브에 저장되기를 원합니다. 데이터베이스는 완료된 모든 트랜잭션을 기록하고 언제든지 정전에 대비하도록 설계되었습니다. 이 동작으로 인해 fsync를 지속적으로 대량으로 사용해야 합니다.

fsync의 빈번한 사용에 영향을 미치는 것

일반 I/O에서는 외부 드라이브가 메모리 계층 구조에서 가장 느리기 때문에 운영 체제는 디스크 통신을 최적화하려고 시도합니다. 따라서 운영 체제는 드라이브에 대한 한 번의 액세스로 가능한 많은 데이터를 쓰려고 합니다.

구체적인 예를 들어 fsync 사용이 미치는 영향을 살펴보겠습니다. 테스트 대상으로 다음과 같은 SSD가 있습니다.

• Intel® DC SSD S4500 480GB, SATA 3.2를 통해 연결, 6Gb/s;
• Samsung 970 EVO Plus 500GB, PCIe 3.0 x4, ~31Gbps를 통해 연결됨.

테스트는 Ubuntu 2255를 실행하는 Intel® Xeon® W-20.04에서 수행되었습니다. 디스크를 테스트하려면 sysbench 1.0.18이 사용됩니다. 디스크에는 ext4로 포맷된 단일 파티션이 있습니다. 테스트 준비는 100GB 파일을 만드는 것입니다.

sysbench --test=fileio --file-total-size=100G prepare

테스트 실행:

# Без fsync
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=0 run

# С fsync после каждой записи
sysbench --num-threads=16 --test=fileio --file-test-mode=rndrw --file-fsync-freq=1 run

테스트 결과는 표에 나와 있습니다.

테스트
인텔® S4500
삼성 970 EVO+

fsync 없이 읽기, MiB/s
5734.89
9028.86

fsync 없이 쓰기, MiB/s
3823.26
6019.24

fsync로 읽기, MiB/s
37.76
3.27

fsync, MiB/s로 녹음
25.17
2.18

운영 체제 자체가 디스크 작업 방법을 결정할 때 클라이언트 세그먼트의 NVMe가 자신있게 앞서고 fsync를 사용할 때 패배한다는 것을 쉽게 알 수 있습니다. 이는 두 가지 질문을 제기합니다.

1. fsync를 사용하지 않은 테스트에서 읽기 속도가 링크의 물리적 대역폭을 초과하는 이유는 무엇입니까?
2. 서버 세그먼트 SSD가 다수의 fsync 요청을 처리하는 데 더 나은 이유는 무엇입니까?

첫 번째 질문에 대한 대답은 간단합니다. sysbench는 100으로 채워진 파일을 생성합니다. 따라서 테스트는 XNUMXGB 이상의 제로를 수행했습니다. 데이터가 매우 균일하고 예측 가능하기 때문에 다양한 OS 최적화가 적용되어 실행 속도가 크게 향상됩니다.

sysbench의 모든 결과에 의문이 있는 경우 fio를 사용할 수 있습니다.

# Без fsync
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=0 --filename=/dev/sdb

# С fsync после каждой записи
fio --name=test1 --blocksize=16k --rw=randrw --iodepth=16 --runtime=60 --rwmixread=60 --fsync=1 --filename=/dev/sdb

테스트
인텔® S4500
삼성 970 EVO+

fsync 없이 읽기, MiB/s
45.5
178

fsync 없이 쓰기, MiB/s
30.4
119

fsync로 읽기, MiB/s
32.6
20.9

fsync, MiB/s로 녹음
21.7
13.9

fsync를 사용할 때 NVMe의 성능 저하 추세가 명확하게 보입니다. 두 번째 질문으로 넘어갈 수 있습니다.

최적화 또는 허세

앞서 우리는 데이터가 버퍼에 저장된다고 말했지만 중요하지 않기 때문에 어느 버퍼에 저장되는지 지정하지 않았습니다. 지금도 우리는 운영 체제의 복잡성을 탐구하지 않고 두 가지 일반적인 유형의 버퍼를 선택하지 않을 것입니다.

• 프로그램;
• 하드웨어.

소프트웨어 버퍼는 운영체제에 존재하는 버퍼를 말하고, 하드웨어 버퍼는 디스크 컨트롤러의 휘발성 메모리를 말한다. fsync 시스템 호출은 버퍼의 데이터를 기본 스토리지에 기록하기 위해 드라이브에 명령을 보내지만 명령의 올바른 실행을 제어할 수 있는 방법은 없습니다.

SSD의 성능이 더 좋기 때문에 두 가지 가정을 할 수 있습니다.

• 디스크는 유사한 계획의 로드를 위해 설계되었습니다.
• 디스크는 "허세를 부리고" 명령을 무시합니다.

정전된 상태에서 테스트를 수행하면 드라이브의 부정직한 동작을 알 수 있습니다. 이를 스크립트로 확인할 수 있습니다. diskchecker.pl, 그건 만든 사람 : 2005 년 인치

이 스크립트에는 "서버"와 "클라이언트"라는 두 개의 물리적 시스템이 필요합니다. 클라이언트는 테스트 중인 드라이브에 소량의 데이터를 쓰고, fsync를 호출하고, 기록된 내용에 대한 정보를 서버에 보냅니다.

# Запускается на сервере
./diskchecker.pl -l [port]

# Запускается на клиенте
./diskchecker.pl -s <server[:port]> create <file> <size_in_MB>

스크립트를 실행한 후에는 "클라이언트"의 전원을 차단하고 몇 분 동안 전원을 다시 공급하지 않아야 합니다. 강제 종료만 수행하는 것이 아니라 테스트 대상을 전기에서 분리하는 것이 중요합니다. 잠시 후 서버가 연결되어 OS에 로드될 수 있습니다. OS를 부팅한 후 다시 시작해야 합니다. diskchecker.pl, 그러나 인수가 있음 확인.

./diskchecker.pl -s <server[:port]> verify <file>

검사가 끝나면 오류 수가 표시됩니다. 0이면 디스크가 테스트를 통과한 것입니다. 디스크에 성공한 상황의 조합을 제외하기 위해 실험을 여러 번 반복할 수 있습니다.

S4500에는 전력 손실 오류가 표시되지 않았습니다. 이는 fsync 호출이 많은 로드에 준비가 되었음을 의미합니다.

결론

디스크 또는 기성 구성 전체를 선택할 때 해결해야 할 작업의 세부 사항을 염두에 두어야 합니다. 얼핏 보면 NVMe, 즉 PCIe 인터페이스를 탑재한 SSD가 '클래식' SATA SSD보다 빠른 것이 분명해 보입니다. 그러나 오늘 우리가 이해한 것처럼 특정 조건과 특정 작업에서는 그렇지 않을 수도 있습니다.

IaaS 공급자로부터 임대할 때 서버 구성 요소를 어떻게 테스트합니까?
댓글에서 여러분을 기다리고 있습니다.

출처 : habr.com