LINUX.ORG.RU

Скорость накопителя на другой конфигурации

 ,


0

1

Был у меня i5 4570 и накопитель wd black 1tb. Скорость копирования 100mb/s. Пересобрал я системный блок на am5 и тот же накопитель. ram на старой системе был 32gb, на новой - 64gb. Процессор предтоп на 12 ядер. Настройки системы те же. Но скорость копирования 60mb/s. Из настроек:

vm.swappiness=60
sysctl -w vm.dirty_ratio=25                                              
sysctl -w vm.dirty_background_ratio=20                               
sysctl -w vm.dirty_writeback_centisecs=60000
sysctl -w vm.dirty_expire_centisecs=30000
sysctl -w kernel.hung_task_timeout_secs=300

# эти два значения вычисляются по формуле
sysctl -w vm.dirty_bytes=38979060
sysctl -w vm.dirty_background_bytes=38979060

Опции монтирования были:

/home ext4 defaults,noatime,commit=600,data=writeback,barrier=0 0 2

Попробовал верхний блок закоментить и поставил такие опции монтирования:

/home ext4 rw,relatime,journal_checksum,journal_async_commit,data=writeback,commit=5 0 2

Начинаю копировать - скорость 60mb/s. Потом io на hdd начинает забиваться, hdd начинает шумно работать головками, такое ощущение, что происходит сброс кэша параллельно копированию. Скорость падает до 32mb/s. Через 15-20сек hdd перестает излишне шуметь и продолжает копировать данные. Скорость повышается до 60mb/s. 3.5Гб копируется чуть ли не 3мин

Сижу и думаю, что собственно не так во всём этом?

UPD: по-идее новые опции монтирования должны были ускорить работу hdd и не они являются причиной такого поведения. Или нет?

★★★★

Последнее исправление: bryak (всего исправлений: 1)

Ну, как вариант, можно сделать гибридное зеркало ssd + hdd (writemostly), с «растянутой» синхронизацией с ssd на hdd. Плюсы и минусы здесь:

https://www.tansi.org/hybrid/
https://linuxwiki.de/SSD
https://www.bibinsa.net/post/2015/02/16/Hybrid-RAID-SSD-HDD-avec-Linux

Пользуюсь такой схемой много лет. Несколько раз ненапряжно переезжал на разные ssd и hdd простой синхронизацией зеркала. FS рабочим порядком перебирал разные, остановился на ext4 с дефолтными настройками.

anonymous
()
Ответ на: комментарий от anonymous

Хорошая штука, но тут всё упирается в то, что ты просто выигрываешь на разнице в цене второго sdd

А вообще мне бы решить вопрос со скоростью hdd. А конфигурация у меня: первый - m2 система, второй - m2 cache под контейнеры и 3 - hdd(media + репы)

bryak ★★★★
() автор топика

Скорость копирования

Зависит от большого числа факторов. Для тестов скорости диска лучше использовать dd if=/dev/sdX of=/dev/null status=progress. Как минимум не будет сказываться фрагментация фс, размер и расположение файлов на поверхности.

u5er ★★★
()
Ответ на: комментарий от u5er

Так можно промерять только чтение недеструктивно. Нужно мерять и запись тоже. Ну и fio, например, больше статы отдаст и больше режимов тестирования даст

cobold ★★★★★
()
Ответ на: комментарий от cobold

Копирование это с одного и того же диска и читается и на него же пишется? Тогда не вижу проблемы

Так на другой системе было 100mb/s. С одного и того же винта. Да, может быть были разные блины. Но(!) всегда, когда я копировал что-то в течение 5 лет - всегда было или 100 или 90+. А тут 60. Притом, что там была старая архитектура и ddr3, а тут ddr5 и всё остальное на порядок быстрей. И настройки не менялись

bryak ★★★★
() автор топика
Ответ на: комментарий от Dimez

sudo dmesg |grep -i ncq

[    1.185883] ahci 0000:12:00.0: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part sxs deso sadm sds apst
[    1.186887] ahci 0000:14:00.0: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part sxs deso sadm sds apst
[    3.226911] ata9.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA

Планировщик none

Что еще нужно? Мать x670e

bryak ★★★★
() автор топика
Последнее исправление: bryak (всего исправлений: 1)
Ответ на: комментарий от bryak

Фрагментация исходного файла? Фрагментация свободного пространства? Деградация самого диска? Попробуй вернуть диск в старую систему и провести эксперимент один в один как на новой

cobold ★★★★★
()
Ответ на: комментарий от cobold

Фрагментация исходного файла? Фрагментация свободного пространства? Деградация самого диска? Попробуй вернуть диск в старую систему и провести эксперимент один в один как на новой

Вчера делал дефраг всех разделов. Был в районе 1%, после так же.

smart

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   200   200   051    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   181   175   021    Pre-fail  Always       -       3950
  4 Start_Stop_Count        0x0032   095   095   000    Old_age   Always       -       5674
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   070   070   000    Old_age   Always       -       21967
 10 Spin_Retry_Count        0x0032   100   100   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   100   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   095   095   000    Old_age   Always       -       5371
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       629
193 Load_Cycle_Count        0x0032   199   199   000    Old_age   Always       -       5044
194 Temperature_Celsius     0x0022   108   095   000    Old_age   Always       -       39
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   200   200   000    Old_age   Offline      -       12

Мультизон иногда вылазит то 2, то 4 и так же пропадает. Сейчас 12. Скорей всего вылазил, потому что есть раздел с нтфс и syncthing несколько объемных директорий с множеством файлов и там была фрагментация 37%. Тоже дефраг сделал. При рескане синкин была жудкая возня головками - скорей всего из-за этого

bryak ★★★★
() автор топика

sudo dmesg |grep -i ahci

[    1.197498] ahci 0000:12:00.0: version 3.0
[    1.197580] ahci 0000:12:00.0: SSS flag set, parallel bus scan disabled
[    1.197615] ahci 0000:12:00.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0xf impl SATA mode
[    1.197617] ahci 0000:12:00.0: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part sxs deso sadm sds apst
[    1.197975] scsi host0: ahci
[    1.198076] scsi host1: ahci
[    1.198162] scsi host2: ahci
[    1.198227] scsi host3: ahci
[    1.198308] scsi host4: ahci
[    1.198384] scsi host5: ahci
[    1.198497] ahci 0000:14:00.0: SSS flag set, parallel bus scan disabled
[    1.198520] ahci 0000:14:00.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0xf impl SATA mode
[    1.198521] ahci 0000:14:00.0: flags: 64bit ncq sntf stag pm led clo only pmp pio slum part sxs deso sadm sds apst
[    1.198838] scsi host6: ahci
[    1.198899] scsi host7: ahci
[    1.198971] scsi host8: ahci
[    1.199034] scsi host9: ahci
[    1.199096] scsi host10: ahci
[    1.199156] scsi host11: ahci
bryak ★★★★
() автор топика

Померь скорость через dd if=/dev/sdXXX of=/dev/null bs=1m status=progress

Что-то я сомневаюсь что там 200мбайт/с будет (а чтобы читать + писать 100, нужно всего 200).

firkax ★★★★★
()
Ответ на: комментарий от anonymous

cat /sys/block/*/queue/scheduler [none] mq-deadline [none] mq-deadline [none] mq-deadline [none] mq-deadline [none] mq-deadline [none] mq-deadline [none] mq-deadline [none] mq-deadline [none] mq-deadline [none] mq-deadline none

Диск и читает и пишет с одной скоростью http://0x0.st/8JXg.png

anonymous
()
Ответ на: удаленный комментарий

ncq

Аппаратный слишком ограничен. Тебе вроде надо пересобрать ядро с CONFIG_IOSCHED_BFQ=y, не видно планировщика. У меня включение bfq заметно ускоряет псевдорандомное мелкоблочное чтение и запись.

anonymous
()
Ответ на: комментарий от anonymous

Он не ускоряет. ncq самый быстрый т.к аппаратный. Если сверху накрутить bfq, то он чуть медленней. Проверял скриптами

cat config-6.1.0-31-amd64 |grep -i CONFIG_IOSCHED_BFQ

CONFIG_IOSCHED_BFQ=m

Проверял скриптом. Попробуй у себя. Можешь выложить результаты

#!/bin/bash


DISC="sda"

if [[ -f ./largefile ]];then
    rm -rf ./largefile
fi

echo 3 > /proc/sys/vm/drop_caches;sync
# cat /sys/block/$DISC/queue/scheduler; \
for T in mq-deadline none bfq kyber; do
    echo $T > /sys/block/"${DISC}"/queue/scheduler
    cat /sys/block/"${DISC}"/queue/scheduler

    # hdparm -tT /dev/"${DISC}"

    echo "write speed----------------------------"
    echo 3 > /proc/sys/vm/drop_caches;sync
    time dd if=/dev/zero of=./largefile bs=1M count=1024

    echo "read speed-----------------------------"
    echo 3 > /proc/sys/vm/drop_caches;sync
    time dd if=./largefile of=/dev/null bs=4k

    rm -rf ./largefile
    echo 3 > /proc/sys/vm/drop_caches;sync
    echo -e "---------------------------------------------------------\n"
    sleep 5
 done

Пипец у вас тут атмосфера. 4 года не было, решил написать свою проблему и заморозили. Вечно у вас какая-то драма (:

anonymous
()
Ответ на: комментарий от bryak

А ты знаешь, что у HDD скорость в начале и в конце диапазона LBA - разная? Так что даже при полном отсутствии фрагментации у разных файлов покажется разная скорость.

Существует на удивление толковая гномовская утилита gnome-disks, рекомендую. Она умеет проводить тестирование скорости, строя график от начала к концу диска. Ясно видно, что у НЖМД этот график ниспадающий, а у SSD, разумеется, полочка.

legolegs ★★★★★
()

# эти два значения вычисляются по формуле

по какой?

relatime

лучше noatime

journal_checksum

зачем? если всё-равно используешь небезопасные journal_async_commit,data=writeback

teod0r ★★★★★
()
Ответ на: комментарий от bryak

всегда было или 100 или 90+. А тут 60

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

vbcnthfkmnth123 ★★★★★
()
Последнее исправление: vbcnthfkmnth123 (всего исправлений: 1)

имхо: У разных версий sata кроме разной скорости ещё и разный функционал, на старой mb например ncq в ahci не умел диски с черепицами, писал так что забивался кэш, плохо вычислял скорость, завышая её, не учитывая задержки, но время доступа могло падать, пользователь мог этого не видеть, а в новой версии ahci улучшенный алгоритм с лучшим откликом, но пожертвовав скоростью, и лучшим алгоритмом отображения скорости.

bcon
()

Ещё одна мысль - а диск работает в одинаковом положении и с нормальным охлаждением? Может он уже поношенный, а ты его боком поставил или перегрел, вот он и калибруется непереставая?

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

ехт4 на хардах удивительно малочувствительна к фрагментации и прочему, да и разница в диаметрах сказывается почти никогда и в пределах 10-20%

Глянул первый попавшийся обзор на современный HDD там разница в зависимости от диаметра от 200 MB/s до 100 MB/s.

V1KT0P ★★
()

pv /dev/sds > /dev/null

Если скорость последовательного блочного чтения ниже прежней, то проблема в ядре, контроллере, физике с кабелем.

Если сопоставима — ФС, фрагментация, параллельная нагрузка.

anonymous
()
Ответ на: комментарий от V1KT0P

Ну, современных у меня нет, а вот 15 лет назад разница была то ли 140 против 120Мб/с, то ли 120 против 100.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Ну, современных у меня нет, а вот 15 лет назад разница была то ли 140 против 120Мб/с, то ли 120 против 100.

Открыл обзор лучших HDD 2010 года и вижу что там скорости от 60 MB/s до 140 MB/s, снова разница примерно в два раза.

V1KT0P ★★
()
Ответ на: комментарий от V1KT0P

Я специально тестировал линейные скорости dd чтобы выбрать действительно ли важно ставить своп в начало. Не впечатлился. Вероятно упор шёл в контроллер или шину или ещё что - у меня были нетбуки.

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

dd status=progress

dd, похоже, буфферизует. Потому что одни и те же данные через пайп в pv идут быстрее, чем через dd:

$ time sudo tar cf - /usr 2> /dev/null | pv > /dev/null
...
pv > /dev/null  0,19s user 1,39s system 8% cpu 18,692 total

$ time sudo tar cf - /usr 2> /dev/null | dd of=/dev/null status=progress
...
dd of=/dev/null status=progress  1,62s user 6,00s system 33% cpu 22,778 total
anonymous
()
9 июня 2025 г.

Да, признаю, что ошибся. Скорость накопителя при заканчивающемся пространстве падает на ~1/3. Т.е так она 100мб/с, а потом падает до 70мб/с. Меня ввело в заблуждение то, что при копировании на ntfs скорость в перманенте 100мб/с, но при завершении копирования, если сделать sync, то sync еще будет до 3-х минут синхронизировать буферы из памяти. Всем спасибо!

bryak ★★★★
() автор топика