Назад | Перейти на главную страницу

противоречивые результаты dd и iostat, ext4 и xfs на томах EBS

Когда я смотрю на производительность диска с dd по сравнению с iostat на двух хостах (экземпляры EC2 с диском EBS), я вижу, что мне кажется противоречивым. Хосты идентичны, за исключением того, что один использует ebs в формате EXT4, а другой - в формате XFS.

Если я посмотрю на iostat, хост EXT4, похоже, превосходит хост XFS. Оба они имеют примерно одинаковую пропускную способность записи (около 25 МБ / с) при примерно 100% использовании, но хост EXT4 в среднем имеет меньше времени ожидания (меньшая задержка диска). Это меньшее ожидание заставляет меня говорить, что EXT4 превосходит XFS:

EXT4:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdf              0.00    11.00    0.00 6331.00     0.00    26.96     8.72    71.00   11.32   0.16  99.60

XFS:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
xvdf              0.00     2.00    0.00 6211.00     0.00    27.38     9.03   144.95   23.24   0.16 100.40

Но, если использовать dd Для измерения производительности явным победителем является XFS, поскольку для выполнения полностью синхронной записи требуется гораздо меньше времени. Команда dd bs=1M count=256 if=/dev/zero of=./test conv=fdatasync:

EXT4:

2.8 MB/s

XFS:

24.0 MB/s

По какой причине EXT4 выглядит намного лучше с iostat но выглядит намного хуже с dd?

ОБНОВЛЕНИЕ 25.05.2018: после запуска хостов в течение пары дней, dd и sync теперь показывают эквивалентное время отклика для ext4 и xfs. Я подозреваю, что это связано с разницей (если таковая есть?) В том, как они обрабатывают что-то вроде разреженных файлов. В первый день работы хостов они оба были заняты установкой кучи новых файлов в файловой системе (это приложение с графитовым углеродным кешем). Сейчас в эти файлы записываются небольшие обновления, но новые файлы больше не создаются, и общий объем используемого дискового пространства больше не увеличивается.

Таким образом, должно быть что-то принципиально иное в том, как XFS выделяет новые дисковые блоки по сравнению с EXT4. Любое понимание того, что это могло быть, было бы приветствоваться.

Поправьте меня, если я ошибаюсь, но я считаю, что вы используете тома EBS.

Попробуйте отформатировать ext4 раздел без lazy initialization, так как это может повлиять на производительность тестирования.

mkfs.ext4 -E lazy_itable_init = 0, lazy_journal_init = 0 / dev / xvdf


Объемы EBS
Производительность тома EBS будет определяться несколькими факторами. Они не совсем интуитивны.

  1. Type of the volume. Предоставленный IOPS io1, Общее назначение gp2, HDD с оптимизированной пропускной способностью st1, Холодный HDD sc1. характеристики.

  2. Size of the volume. Как правило, чем больше громкость, тем лучше производительность. За исключением выделенного EBS IOPS (io1), тома используют пакетную модель [1], и количество операций ввода-вывода может колебаться или значительно снижаться, если all I/O credits are used. Короче говоря, каждый том получает базовый минимум 100 операций ввода-вывода в секунду, и для каждого добавленного +1 ГБ (после ~ 33 ГБ) производительность увеличивается на 3 операций ввода-вывода в секунду. Кроме того, объем может увеличиться до 3000 операций ввода-вывода в секунду, если доступно достаточно средств ввода-вывода.

  1. EC2 Instance type. Чем больше экземпляр, тем выше производительность сети. Также важно, является ли это инстансом, оптимизированным для EBS, или нет.

  2. Если вы восстановили свой том из моментального снимка, вам придется предварительно нагреть том, чтобы получить максимальную производительность.
    Видеть https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html

Больше деталей:
[1] https://aws.amazon.com/ebs/details/

Обновление 1

Трудно сказать, почему вы видите эти результаты, поскольку в вашем сообщении просто недостаточно информации, чтобы я мог это сделать.

Этот шаблон CloudFormation - моя попытка воссоздать ваши результаты.
https://gist.github.com/an2io/c68b2119f18192d83a685651905623e9

EXT4 
wrqm/s  w/s     wMB/s   avgrq-sz    avgqu-sz    await   svctm    %util  
0.00    528.62  66.08   255.84      127.07      217.16  1.61     85.39    
2.69    287.21  35.86   255.71      142.20      504.73  3.52    101.01    
0.00    285.28  35.59   255.49      134.93      462.90  3.52    100.33    
3.02    277.52  34.54   254.89      115.54      460.62  3.51     97.32    
0.00      0.00   0.00     0.00        0.00        0.00  0.00      0.00    
512+0 records in  
512+0 records out  
536870912 bytes (537 MB) copied, 11.9003 s, 45.1 MB/s
XFS 
wrqm/s  w/s     wMB/s   avgrq-sz    avgqu-sz    await   svctm    %util
1.68    542.28  67.44   254.07      176.84      301.59  1.66     90.47
0.00    284.95  35.62   256.00      143.74      508.38  3.52    100.33
0.00    285.28  35.58   255.46      184.36      609.81  3.52    100.33
0.00    265.10  32.95   253.27      162.34      692.59  3.48     92.75
0.00      0.00   0.00     0.00        0.00        0.00  0.00      0.00

512+0 records in  
512+0 records out  
536870912 bytes (537 MB) copied, 11.7641 s, 45.6 MB/s
df 
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.9G   72K  1.9G   1% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
/dev/xvda1      9.8G  1.2G  8.5G  12% /
/dev/xvdb       3.9G  8.1M  3.7G   1% /media/ephemeral0
/dev/xvdf1      3.7G  520M  3.0G  15% /mnt/ext4
/dev/xvdf2      3.9G  545M  3.3G  14% /mnt/xfs
mount 
/dev/xvdf1 on /mnt/ext4 type ext4 (rw,relatime,data=ordered)
/dev/xvdf2 on /mnt/xfs type xfs (rw,relatime,attr2,inode64,noquota)