При дисковых операциях тормозят иксы
Собственно сабж, ubuntu 9.10, ext4, 512ram
Поменяй планировщик io.
можно и cfq оттюнить децл.
Это называется «стройная архитектура ОС Линукс в действии».
это называется — x86 — гавно!
памяти добавь. 512 метров для современных дистрибутивов с иксами и DE очень мало. система сидит в свопе — отсюда и тормоза.
Половина свободна, чего еще нехватает
ха — агрессивность свопа настрой!
Попробуй легковесный WM
15 будет лучше — своп или почти или чистый будет — меньше обращений к винту.
Печально известный 12309. У меня на двух машинах проявляется, с десктопным 965 и ноутбучным 945 в качестве системной логики.
А в каком ядре это впервые появилось?
lspci -k
покажите , можно не весь, а только касательно чипсета и контроллера IDE/SATA
В каком-то ископаемом, версий 15 назад, погугли, точно не помню
С 2.6.18.x вроде. Так вот почему RHEL на 2.6.18 сидит!
У меня тормоза на nForce570 и на AMD770. zen-ядро картину не меняет совершенно. Стоит коснуться свопа и всё — курсор мыши встаёт, по минуте можно ждать отклика.
а система 32 или 64 бит?
Свопа лучше не касаться, желательно вообще не использовать его.
4-6 гб памяти, и можно летать, без затормаживающих производительность действий
Память > Swap
Swap > Память
Память > Swap
Swap > Память
Память > Swap
Swap > Память
Память > Swap
Swap > Память
Память > Swap
Swap > Память
Память > Swap
Swap > Память
Память > Swap
Swap > Память
Угу. с 12309 полетаешь.
>Свопа лучше не касаться, желательно вообще не использовать его.
4-6 гб памяти, и можно летать, без затормаживающих производительность действий
А-то я не знал?
Дело в том, что до 18-го ядра всё было нормально. Ну трещал винт свопом, но работать можно было продолжать. По крайней мере сохраниться и продолжить позже.
Дело в том, что в моих задачах тяжело говорить заранее сколько памяти будет занято, и 4 гига заполняются очень легко.
Linux host 2.6.33-020633-generic #020633 SMP Thu Feb 25 10:59:18 UTC 2010 i686 GNU/Linux
В багзилле ядра написано что эту проблему пофиксили в ядрах версий 2.6.32, но потом версиях от 2.6.32.8 снова испортили https://bugzilla.kernel.org/show_bug.cgi?id=12309
понятно, с NCQ непошаманить, только cfq понастраивать если
echo 4096 > /sys/block/sda/queue/nr_requests
for i in `pidof kjournald` ; do ionice -c1 -p $i ; done
А как можно с NCQ пошаманить? Его можно вообще выборочно отключить, только на одном из дисков или только глобально?
Источник
Тормоза при дисковых операциях
Так было всегда, просто достало. При копировании, сохранении, и т.п. дисковые операции виснет все. Туго открываются новые окна, например. Все нормализуется по окончанию этого копирования.
Как-то наверно можно ситуацию улучшить. Конфигом ядра?
Может просто система засралась (устанавливал в 2012)
Сюда пишу, так как не могу грамотно это сформулировать в поисковике.
пересобери систему и мир начисто
scsi_mod.use_blk_mq=1 в опции ядра
Ставлю два имеющихся процессора, что это ничего не изменит.
Попробуй другой планировщик I/O в ядре поменять.
Это как греться у костра и смотреть на огонь.
Если у тебя ядро версии 3.x (не помню в какой именно исправили 12309), то рекомендую обновить ядро.
Если уже 4.x, то рекомендую переконфигурить ядро снуля. Ну, то есть начиная с make defconfig .
Это как греться у костра и смотреть на огонь.
Ну так вечно можно смотреть на 3 вещи: на воду, на огонь, и как компилируется Гента. Проверено.
Проверь текущий IO планировщик. Поставь CFQ. Или пропатчи ядро и поставь BFQ.
Угу, на паре моих тестовых серверов I/O просел после этого в 4 раза, спасибо. Ты бы хоть объяснял сначала человеку что делает эта опция и чем это может грозить 🙂
У меня ничего никуда не просело. Человеку нужна отзывчивость системного gui, серверные критерии тут как бы не в тему.
Разъясняю, если тебе лень гуглить — если у него старый контроллер SATA(не AHCI) и там нет NCQ, то при попытке многопоточного вывода в однопоточную очередь команд будет просадка и по throughtput и по latency. Из-за последнего — станет ЕЩЕ ХУЖЕ!
старый контроллер SATA(не AHCI) и там нет NCQ
Ну, о такой жести я не подумал, каюсь.
Да нет проблем, я тоже повёлся на эту опцию и удивлялся, почему это по дефолту не включили, клёво же. А потом наступил на грабли(хорошо хоть хватило ума делать это на тестовом сервере) и погуглил.
Тогда пересобрать два раза.
Все тормозит это очень абстрактно, нужны какието численные данные для понимания сути проблемы.
Что с RAM/SWAP ? (сколько, сколько занято, свободно, используется)
pf-kernel с BFQ вместо планировщика хорошо исполняет роль плацебо, мне помогло.
Выложи выхлоп dmesg на какой-нибуть pastebin.
для большей ясности:
Что на зеркало пенять, коли рожа крива. Это я про то, что не в ядре дело, а в файловой системе ext, которая по себе глючное *овно.
удаление не самое то что луче мерить
Нужно другое ядро.
Чтобы тормозило не только io, а вообще всё
Нет софта/драйверов — нет тормозов))
Что у вас тормозит на FreeBSD? Лично я ощущаю нехватку процессорной мощности двухъядерного AMD Athlon X2 3800+ для компиляции современного ПО и 3,7 ГБ RAM ОЗУ тоже не так уж и много (диск с ZFS).
всем спасибо за бурную дискуссию!
— собрал новое ядро 4.9.4-gentoo с BFQ планировщиком
— обновил мир, который и так был не очень старый
визуально немного стало получше, но тормоза еще есть.
например включаю комп, открываю хром в котором
40 вкладок, сразу же открываю проводник dolphin и вижу только рамку, через 20 секунд появляется его содержимое
раньше такого не было
это ведь тоже диск? кэш там. и пр.
если не сложно, прогоните этот тест http://blenchmark.com/
и выложите на тот же сайт
это аддон теста для блендера
Это вообще не дело. Вы опцию blk-mq пробовали?
если не сложно, прогоните этот тест
А смысл? Чем будем меряться?
Судя по всему у вас нехватка RAM что приводит к свопу, а по скольку в конфиге ядра выключены опции:
Но это все догадки, нужно смотреть числа
что это? подробнее
это все при простое
когда это лучше снять? в момент 20сек тормоза я могу не успеть? что первее снять?
Хмм, как видно со свопом проблем нету — памяти много и своп вообще не используется. Перегрузки по IO тоже нету (WA в пределах 0-1) и вобщем система не загружена, все должно «летать» при таких показателях.
Возможно проблема гдето в другом месте (не в производительности, а гдето чтото лочит процессы — например какойнибудь левый бекрезолв при логировании или еще чего). Я бы попробовал найти какуюто програмку попроще которая «тормозит» и протрекал бы ее системные вызовы и где она зависает (через strace) — возможно у вас просто тормозит X11 сервер (например глючит видео карта/драйвер или закончилась VRAM в результате чего очень медленно выделяются ресурсы композитором для новых окон).
тормоза остались
это всегда проявляется при emerge —sync , тогда тормозит, например, браузер, и не грузит ничего, не прокручивает страницы, но вкладки перещелкивает.
как это победить?
системный диск и home у меня — ssd
Kroz Pinkbyte Lifun
Источник
при дисковых операциях все тормозит
Когда что-нибудь активно читаешь/копируешь на жесткий диск — начинаются нереальные тормоза в приложениях. Слайдшоу. Особенно плохо становится на торрентах и SDC. Как можно это поправить?
(Arch, i686 PAE, ext4, Intel C2D E7300, SATA. Сменить дистрибутив, архитектуру, процессор, жесткий диск, файловую систему, голову, руки и ноги — не предлагать).
kernel bug #12309
попробуйте сменить планировщик
BFQ например поставить, или если диском поддерживается NCQ — noop
от тормозов еще помогает BFS за счет более эффективного распределения времени процессора
> kernel bug #12309
и, если коротко, что теперь с этим делать? прочитать всю дискуссию в багзилле ниасилил, там 100500 🙁
> BFQ например поставить, или если диском поддерживается NCQ — noop
от тормозов еще помогает BFS за счет более эффективного распределения времени процессора
посмотрел репозиторий, упал духом. Нету там BFQ + BFS + PAE. Руками собирать. Несколько дней читать прклятые маны по ручной сборке ядра. НЕЕЕЕЕТ!
Добрые люди, у кого ArchLinux + BFS/BFQ + PAE, выложите скрипт для компилирования, пожалуйста 🙁
Источник
Почему дисковая система Linux тормозит?
Давненько зрел у меня бугурт по поводу 12309 и его родственникам, наконец решился сформулировать вопрос, поделиться болью, а заодно и спросить ЧЯДНТ.
Итак, СКОРОСТЬ РАБОТЫ С ДИСКОМ.
Исходные данные: копирование одного и того же большого файла в пределах одного и того же NVME-накопителя на одном и том же компе с 16-тью гигами DDR4 ОЗУ.
Linux Arch, Kernel 4.10 (а вообще насрать, на любом ведре так) 64 bit, ext2, Xfce4: https://pp.userapi.com/c637331/v637331443/337aa/rsaPGTZfh64.jpg — начинается со 150 Мб\с, к концу копирования падает до 50 Мб\с. От ФМ не зависит, в терминале и mc скорость та же самая, с blk-mq игрался.
На других девайсах ситуация такая же самая, не зависит от дистра, DE, скорости носителя и тд. Суть: никсы медленнее виндов. Я не фанат винды, но хочу понять.
Вут? Настройки какие-то кулхакерсие прописывал куда-нибудь? И для начала скорость блочного устройства проверь через dd bs=1M status=progress. У меня запись даже мелких файлов (исходники хромиума) 750мб/c ext4, 350мб/c udf, 140мб/c на убогом ntfs-3g.
ntfs — юзернейм. Сорян, виндовое прошлое 🙂
Файл немного другой, ибо на линуксовом разделе места маловато. Скорость уже чуть повыше, но блин, 425 против 1600.
Копирование в пределах одного диска медленнее, он же читает и пишет одновременно. Положи входной chromiumos_image.bin на рамдиск (тупо кинь в /dev/shm).
Чтобы локализовать падение скорости от фс, попробуй писать напрямую на блочное устройство /dev/nvme0n1pX (отрежь отдельный раздел).
Повторюсь, ntfs-3g сосёт капитально. Если входной файл на ntfs, то он может просто читаться настолько медленно.
Да ты прав. В\с рамдиск копирование происходит значительно быстрее. Остается открытым вопрос почему винда в пределах своей ФС копирует на скорости 1.6 гб\с, Арч на ext2 МАКСИМУМ 450 мб\с, и нельзя ли это как-то растюнить?
Попробуй (только не записывай при таких настройках ничего на флэшку, будет 12309 xD):
Ещё ext4 без журнала или f2fs может быть быстрее чем ext2, но не проверял.
Это всё потомучто микрософт проплатил производителям дисков и теперь linux в пролёте. Там какие-нибудь скрытые функции которые никто никогда не угадает так как этотайна. ext4 всё таки быстрее ext2 процентов на 30%.
Проверь на reiserfs. Говорят это самая скоростная файловая система на linux.
Ты шкальникам винды особенно не верь, они обычно при копировании врут.
Windows показывает усредненное с учетом кэширования. После того, как копирование «закончится» диск еще несколько секунд будет писать.
Windows 10 64 bit, ntfs раздел: (cut) — 1.26 Гб\с
Замерял поверенной линейкой?
Ыыы! На лицо неправильно поставленный эксперимент и как слелствие неверные выводы.
Наркоманштоле ? Во-первых, файловый менеджер сам это пишет, во-вторых если тебе упорышу надо линейка дабы уловить разницу между тремя секундами и двадцатью — то прими разупорин.
Какой нахрен эксперимент ? Я последовательно загрузился в две системы и копировал один и тот же файл в пределах фс, а теперь хочу понять как пофиксить тормоза в никсах. Распарсил суть задачи, или разупорин с предыдущего абзаца еще не подействовал ?
Windows показывает усредненное с учетом кэширования. После того, как копирование «закончится» диск еще несколько секунд будет писать.
Понял. Спс. Хотя всегда думал что никсы тоже, по крайней мере после копирования чего-то большого, иногда приходится вручную запускать sync
Ты шкальникам винды особенно не верь, они обычно при копировании врут.
Та не, общее время копирования с виндами все же поменьше будет, осталось понять кто виноват, фс, нвм, или еще шото.
echo 100 >/proc/sys/vm/dirty_ratio echo 1048576 >/proc/sys/vm/dirty_background_bytes tee /proc/sys/vm/dirty_*_centisecs ★ ( 01.03.17 12:50:58 )
Ты сравниваешь тёплое с длинным при этом ещё и разными средствами измерения.
Очень ценная информация. Только ты опираешься на показания разных файловых манагаров (ОЙ) с разными файловыми системами (ОЙ) в совсем разных ОСях (ОЙ) с непонятно какими настройками (ОЙ).
Уж кто бы заикался о наркомании. В науке твой подход именуют «неправильно поставленный эксперимент». А результаты таких экспериментов не говорят ни о чем.
Вероятно у тебя интеловский контроллер NVMe, для которого не существует нормальных дров под линукс .
Чувак, я не ставил эксперимент. Я обнаружил что мой Linux не работает на той скорости, которую мне обещал производитель моего SSD-накопителя.
Чтобы не слать его на гарантию с претензиями на несоответствие характеристикам, я перепроверил свои претензии на другой ОС. Претензии не подтвердились, вторая ОС работает на обещанной производителем скорости. Теперь я пытаюсь понять, что мне сделать с первой ОС дабы она работала на той же скорости.
И естественно я опираюсь на реальную работу реальных программ, в число которых входит и ФМ тоже. И я там выше написал, что дело не в ФМ, ибо mc в терминале копирует с такими же самыми тормозами. dd и hdparm -t это конечно хорошо, но мне надо работать.
Так что никаких экспериментов.
Не. NVMe — эт всего лишь протокол, типа нашего древнего AHCI. Поддержка в ведре есть очень давно, я видел эти опции еще при сборке 3.4.
Сам носитель подключается по шине PCI-E, дрова вроде стандартные.
Я намекал на Intel Rapid Storage Technology. Если честно — я не помню в какое место они ее засунули, но жизнь портит.
ЗЫ: У меня самсунговский NVMe.
Аналогично, Самсунг 950.
Засрется мой Рач, попробую вернуться на F2FS, задалбывает создавать доп. раздел под /boot, ибо EFI не может в ф2фс 🙁
Я обнаружил что мой Linux не работает на той скорости, которую мне обещал производитель моего SSD-накопителя.
Любое железо <неподдерживаемое>/ <неполностью поддерживаемое>LInux-ом ВНЕЗАПНО не будет показывать свои номинальные характеристики заявленные производителем и файловая любая подсистема ядра Linux здесь абсолютно не при чём.
А прежде чем ныть на «не работает на той скорости, которую мне обещал» сперва хотя-бы grep -ают в / usr/src/linux/Documentation/ на предмет конкретной железки.
Всегда твой. С любовью. Капитан.
Ты сабж-то читал ?
При чем здесь поддерживаемое железо ?
Если ты железом называешь шину PCI-E, то оно полностью поддерживается Linux.
Если ты железом называешь NVM-протокол, то он тоже полностью поддерживается Linux.
Да системе вообще насрать какое там железо стоит на том конце PCI-шины, хоть SSD, хоть набор планок памяти ОЗУ, хоть массив microSD-карточек. Задача этого железа — отвечать по NVM.
А… Значит мопед не твой а ты вообще только объявление разместил. Ну ок.
Это всё потомучто микрософт проплатил производителям дисков
Несколько лет назад Самсунг был пойман за руку на этом деле. Они делали на своих ССД что-то специфическое, если файловая система — НТФС.
Нет, ну по сути в оптимизации железа под софт нет ничего плохого. Я не спец в устройствах ФС, но мне кажется что например если средства этой ФМ позволяют сбрасывать очередь буферов раз в пять минут не трогая проц — то это можно использовать. Я например говорю. Если ФС использует блоки с длиной прибитой гвоздями, например по 64 кб, то вполне логично надрачивать железку на использование именно 64 кб блоков априори, а не каждый раз пересчитывать длину пришедшего блока (подобно как в MySQL поле TEXT vs VARCHAR). Чем меньше скорость, тем эти задержки незаметнее: 10% просадка скорости когда максимальная 550 Мб\с — не так заметно, как когда максимальная — 2500 Мб\с 🙂
И вполне логично что такая оптимизация будет сделана под одну ФС, которая кстати самая популярная на рынке, вместо зоопарка ФС которые даже в сумме не смогут конкурировать по популярности со спермоФС.
Источник
