LINUX.ORG.RU

Почему дисковая система Linux тормозит?

 , ,


1

5

Здравствуйте, посоны!

Давненько зрел у меня бугурт по поводу 12309 и его родственникам, наконец решился сформулировать вопрос, поделиться болью, а заодно и спросить ЧЯДНТ.

Итак, СКОРОСТЬ РАБОТЫ С ДИСКОМ...

Исходные данные: копирование одного и того же большого файла в пределах одного и того же NVME-накопителя на одном и том же компе с 16-тью гигами DDR4 ОЗУ.

Windows 10 64 bit, ntfs раздел: https://pp.userapi.com/c637331/v637331443/337b4/QeKmlMVeXrw.jpg - 1.26 Гб\с

Linux Arch, Kernel 4.10 (а вообще насрать, на любом ведре так) 64 bit, ext2, Xfce4: https://pp.userapi.com/c637331/v637331443/337aa/rsaPGTZfh64.jpg - начинается со 150 Мб\с, к концу копирования падает до 50 Мб\с. От ФМ не зависит, в терминале и mc скорость та же самая, с blk-mq игрался.

На других девайсах ситуация такая же самая, не зависит от дистра, DE, скорости носителя и тд. Суть: никсы медленнее виндов. Я не фанат винды, но хочу понять...

ШТОЭТА?!!!11


ext2

copying to ntfs

Вут? Настройки какие-то кулхакерсие прописывал куда-нибудь? И для начала скорость блочного устройства проверь через dd bs=1M status=progress. У меня запись даже мелких файлов (исходники хромиума) 750мб/c ext4, 350мб/c udf, 140мб/c на убогом ntfs-3g.

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

ntfs - юзернейм. Сорян, виндовое прошлое :)


[root@brix ntfs]# dd if=chromiumos_image.bin of=chromiumos_image.bin_1 bs=1M status=progress
2561671168 bytes (2.6 GB, 2.4 GiB) copied, 6.00209 s, 427 MB/s
2469+1 records in
2469+1 records out
2589949952 bytes (2.6 GB, 2.4 GiB) copied, 6.10031 s, 425 MB/s
[root@brix ntfs]# 

Файл немного другой, ибо на линуксовом разделе места маловато. Скорость уже чуть повыше, но блин, 425 против 1600...

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

Копирование в пределах одного диска медленнее, он же читает и пишет одновременно. Положи входной chromiumos_image.bin на рамдиск (тупо кинь в /dev/shm).

Чтобы локализовать падение скорости от фс, попробуй писать напрямую на блочное устройство /dev/nvme0n1pX (отрежь отдельный раздел).

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

Да ты прав. В\с рамдиск копирование происходит значительно быстрее. Остается открытым вопрос почему винда в пределах своей ФС копирует на скорости 1.6 гб\с, Арч на ext2 МАКСИМУМ 450 мб\с, и нельзя ли это как-то растюнить?

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

Попробуй (только не записывай при таких настройках ничего на флэшку, будет 12309 xD):

    echo 100 >/proc/sys/vm/dirty_ratio
echo 1048576 >/proc/sys/vm/dirty_background_bytes
tee           /proc/sys/vm/dirty_*_centisecs <<<60000

Ещё ext4 без журнала или f2fs может быть быстрее чем ext2, но не проверял.

anonymous ()

Это всё потомучто микрософт проплатил производителям дисков и теперь linux в пролёте. Там какие-нибудь скрытые функции которые никто никогда не угадает так как этотайна. ext4 всё таки быстрее ext2 процентов на 30%.

LEONARDO ()

Windows показывает усредненное с учетом кэширования. После того, как копирование «закончится» диск еще несколько секунд будет писать.

Nastishka ★★★ ()

Windows 10 64 bit, ntfs раздел: (cut) - 1.26 Гб\с

Замерял поверенной линейкой?

Суть: никсы медленнее виндов.

Ыыы! На лицо неправильно поставленный эксперимент и как слелствие неверные выводы.

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

Наркоманштоле ? Во-первых, файловый менеджер сам это пишет, во-вторых если тебе упорышу надо линейка дабы уловить разницу между тремя секундами и двадцатью - то прими разупорин.

Какой нахрен эксперимент ? Я последовательно загрузился в две системы и копировал один и тот же файл в пределах фс, а теперь хочу понять как пофиксить тормоза в никсах. Распарсил суть задачи, или разупорин с предыдущего абзаца еще не подействовал ?

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

Windows показывает усредненное с учетом кэширования. После того, как копирование «закончится» диск еще несколько секунд будет писать.

Понял. Спс. Хотя всегда думал что никсы тоже, по крайней мере после копирования чего-то большого, иногда приходится вручную запускать sync

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

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

Та не, общее время копирования с виндами все же поменьше будет, осталось понять кто виноват, фс, нвм, или еще шото.

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

Наркоманштоле ?

Ты сравниваешь тёплое с длинным при этом ещё и разными средствами измерения.

файловый менеджер сам это пишет

Очень ценная информация. Только ты опираешься на показания разных файловых манагаров (ОЙ) с разными файловыми системами (ОЙ) в совсем разных ОСях (ОЙ) с непонятно какими настройками (ОЙ).

Уж кто бы заикался о наркомании... В науке твой подход именуют «неправильно поставленный эксперимент». А результаты таких экспериментов не говорят ни о чем.

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

Чувак, я не ставил эксперимент. Я обнаружил что мой Linux не работает на той скорости, которую мне обещал производитель моего SSD-накопителя.

Чтобы не слать его на гарантию с претензиями на несоответствие характеристикам, я перепроверил свои претензии на другой ОС. Претензии не подтвердились, вторая ОС работает на обещанной производителем скорости. Теперь я пытаюсь понять, что мне сделать с первой ОС дабы она работала на той же скорости.

И естественно я опираюсь на реальную работу реальных программ, в число которых входит и ФМ тоже. И я там выше написал, что дело не в ФМ, ибо mc в терминале копирует с такими же самыми тормозами. dd и hdparm -t это конечно хорошо, но мне надо работать.

Так что никаких экспериментов.

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

Не. NVMe - эт всего лишь протокол, типа нашего древнего AHCI. Поддержка в ведре есть очень давно, я видел эти опции еще при сборке 3.4.

Сам носитель подключается по шине PCI-E, дрова вроде стандартные.

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

Я обнаружил что мой Linux не работает на той скорости, которую мне обещал производитель моего SSD-накопителя.

Любое железо {неподдерживаемое}/{неполностью поддерживаемое} LInux-ом ВНЕЗАПНО не будет показывать свои номинальные характеристики заявленные производителем и файловая любая подсистема ядра Linux здесь абсолютно не при чём.

А прежде чем ныть на «не работает на той скорости, которую мне обещал» сперва хотя-бы grep-ают в /usr/src/linux/Documentation/ на предмет конкретной железки.

Всегда твой. С любовью. Капитан.

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

Ты сабж-то читал ?

При чем здесь поддерживаемое железо ?

Если ты железом называешь шину PCI-E, то оно полностью поддерживается Linux.

Если ты железом называешь NVM-протокол, то он тоже полностью поддерживается Linux.

Да системе вообще насрать какое там железо стоит на том конце PCI-шины, хоть SSD, хоть набор планок памяти ОЗУ, хоть массив microSD-карточек. Задача этого железа - отвечать по NVM.

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

Это всё потомучто микрософт проплатил производителям дисков

Несколько лет назад Самсунг был пойман за руку на этом деле. Они делали на своих ССД что-то специфическое, если файловая система - НТФС.

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

Нет, ну по сути в оптимизации железа под софт нет ничего плохого. Я не спец в устройствах ФС, но мне кажется что например если средства этой ФМ позволяют сбрасывать очередь буферов раз в пять минут не трогая проц - то это можно использовать. Я например говорю. Если ФС использует блоки с длиной прибитой гвоздями, например по 64 кб, то вполне логично надрачивать железку на использование именно 64 кб блоков априори, а не каждый раз пересчитывать длину пришедшего блока (подобно как в MySQL поле TEXT vs VARCHAR). Чем меньше скорость, тем эти задержки незаметнее: 10% просадка скорости когда максимальная 550 Мб\с - не так заметно, как когда максимальная - 2500 Мб\с :)

И вполне логично что такая оптимизация будет сделана под одну ФС, которая кстати самая популярная на рынке, вместо зоопарка ФС которые даже в сумме не смогут конкурировать по популярности со спермоФС.

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

Да. Не вижу в этом ничего плохого. И уж тем более не вижу преимуществ перед ext4 кроме журналирования. А по поводу 2017 года - глянь ради интереса в какой ФС форматируются разделы для EFI :)

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

не вижу преимуществ перед ext4 кроме журналирования

У ext4 куча преимуществ на уровне алгоритмов и фич типа экстентов, блочного выделения и записи, но вы можете дальше использовать на ssd архаичную ФС и удивляться, почему всё так медленно))

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

Не. Это чит. Работать он может и будет, но не везде. Я ж в целом хочу повысить отзывчивость системы, а не только в копировании. Например в grep -r «test» /* и так далее. Но спасибо.

vblats ()

В общем таки дело было в... а хз в чем. ОС переустановил. Поставил на f2fs, /boot на fat32, пересобрал ведро 4.10 с вкусными патчами, поотключал нафик энергосбережение, выбросил инитрд.

С момента нажатия на энтер в grub меню, до полной загрузки рабочего стола xfce - 3 секунды.

Скорость копирования с нтфс'я на ф2фс - 850 мб\с. Больше - не позволит обрезанная шина на Бриксе.

Десяточка снова начала аццасывать. Сказка.

Всем спасибо!

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

А теперь попробуй вставить в привод лазерных дисков царапанный и открыть его из проводника.

))) Чувак, у меня весь комп габаритами как половина привода, куда я его вставлю?)

vblats ()