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



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

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
()
Ответ на: комментарий от vblats

Повторюсь, ntfs-3g сосёт капитально. Если входной файл на ntfs, то он может просто читаться настолько медленно.

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
()
Ответ на: комментарий от vblats

Проверь на reiserfs. Говорят это самая скоростная файловая система на linux.

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
() автор топика
Ответ на: комментарий от anonymous

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

Скорость с рамдиска на ext2 - 610 Mb\s. Уже ближе.

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

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

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

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

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

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

init_6 ★★★★★
()

Вероятно у тебя интеловский контроллер NVMe, для которого не существует нормальных дров под линукс ...

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

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

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

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

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

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

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

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

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

Я намекал на Intel Rapid Storage Technology. Если честно - я не помню в какое место они ее засунули, но жизнь портит.

ЗЫ: У меня самсунговский NVMe.

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

Аналогично, Самсунг 950.

Засрется мой Рач, попробую вернуться на F2FS, задалбывает создавать доп. раздел под /boot, ибо EFI не может в ф2фс :(

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
() автор топика
Ответ на: комментарий от vblats

А… Значит мопед не твой а ты вообще только объявление разместил. Ну ок.

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

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

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

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

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

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

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

Да. И Noop, и CFQ, и BFQ. Планировщик вроде на скорость непосредственно копирования не влияет.

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

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

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

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

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

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

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

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

Не. Спасибо за подсказку. Рач еще немного засрется, придет время переустановить Рач, и поэкспериментирую с ФС. Спасибо :)

vblats
() автор топика

Потому что надо использовать нормальную ОС например фряху или десяточку ультима

anonymous
()
Ответ на: комментарий от Deleted
[root@brix work]# hdparm -Tt --direct /dev/nvme0n1

/dev/nvme0n1:
 Timing O_DIRECT cached reads:   2636 MB in  2.00 seconds = 1317.78 MB/sec
 Timing O_DIRECT disk reads: 4952 MB in  3.00 seconds = 1649.99 MB/sec
vblats
() автор топика

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

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

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

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

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

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

ntfs драйвер сильно грузит проц, чтоб ты знал.

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

привод лазерных дисков

2017

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

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

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

vblats
() автор топика

Вариантов куча может быть.

Discard включил? - выключи

fornlr ★★★★★
()
Последнее исправление: fornlr (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.