Сильное падение производительности в Linux

как с этим бороться?

Повторять мантру «а в шиндошс еще хуже».

Неужели это пресловутый 12309?

Ну что ты, это же фантастика.

12309

Да, это наш старый друг, bug12309. Первый совет: забить на NTFS, вынести из неё всё, что не касается венды, т.к. FUSE то ещё говно из-за постоянных прыжков между ring0 и ring3. Ну или поставить Poragon NTFS, он вроде быстрее, но придётся ядро постарше ставить. Он работает максимум на 3.15.

Например, перегрев проца из-за турбобуста. Показывай dmesg, а ещё смотри что в perf top наверху во время тормозов.

отпадает сразу. тротлинга точно нет. проверял. на шиндоус тоже не наблюдается тротлинга. и это самый тротлинг не может вот таким уж точно.

так речь о том, что этот баг даже наблюдается, когда работаешь ТОЛЬКО с ext4,когда даже пальцем не трогаешь эту ntfs. На такой случай есть рецепты?

Это всё конечно хорошо, но всё равно покажи dmesg, и perf top во время тормозов.

Но ты должен согласится, что с NTFS такое происходит чаще, не так ли?
А так, попробуй ядро поновее. И да, давай логи.

при сильной загрузке ЦП(а точнее, при полной загрузке одного ядра), часто бывает

а часто не бывает.. какой именно фактор влияет на появление данной проблемы? Какая-то специфическая нагрузка?

Оператива не заканчивается, в своп не сваливается.

Из чего сделан такой вывод?

Ведро тьюнь. Там где-то был конфиг приоритетов и частоты какого-то софт-таймера, который задавал как распределяются ресурсы

А вообще странное что-то. Опять же - попробуй даун/апгрейднуть ведро

Да, с NTFS такое происходит заметно чаще,Вы абсолютно правы

нет, нагрузка не специфическая. я уже описал. Достаточно в большинстве случаев просто того, что одно ядро ПОЛНОСТЬЮ загружено. А если при этом ещё и активная работа с диском - шанс повышается. Но это так, выводы на глазок.

Насчёт свопа - он просто напросто отключен. Не может же система сваливаться в отключенный своп, правда? Или всё-таки как-то может? просто по логике если рамы не хватит, и нет свопа, то надо процессы будет убивать и крешится, а не продолжать работать

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

dmesg: http://pastebin.com/5eBCWppv

Я вот тут подумал, может это я уже ССЗБ, но вот получился тесткейс, при котором тормозит люто. Постоянная запись на HDD в несколько процессов(запись ведётся на раздел NTFS), сама кубунта на SSD. ЗАпускается виртуалка windows 10 в virtualbox.По показаниям ksysguard ещё остаётся 1.2 гб рамы. На SSD как в корне, так и в хомяке места достаточно. swap отключён.

Фризится при таком раскладе каждый раз. Причём именно во время загрузки вирт. машины(которая сама находится на HDD на ext4) идут фризы. Но во время загрузки VM на команду sudo perf top он мне выдаёт следующее:

Not enough memory for annotating 'exit_dns_resolver' symbol!

когда же он всё-таки покажет данные, то первая строка такова: 30,35% libQtCore.so.4.8.6 [.] _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP

но обычно вместо 30% держится в районе 45-50%

Неужели действительно рама заканчивается? Как мне это правильно протестить, ибо знаю, что всякие ksysguard не показатель

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

ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20140424/hwxface-580)

ACPI Warning: SystemIO range 0x0000000000000500-0x000000000000052F conflicts with OpRegion 0x0000000000000500-0x0000000000000563 (\GP01) (20140424/utaddress-254)

ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95)

i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment
pci 0000:01:00.0: Max Payload Size 16384, but upstream 0000:00:01.0 set to 128; if necessary, use «pci=pcie_bus_safe» and report a bug

psmouse serio4: Touchpad at isa0060/serio4/input0 lost sync at byte 6
psmouse serio4: issuing reconnect request

Uhhuh. NMI received for unknown reason 31 on CPU 2.

Без свопа начинаются тормоза, а только потом всё начинает падать, потому своп отключать смысла нет.

Ядро 3.16.0-51-generic.i73630qm

предлагаю начать с себя

отпадает сразу. тротлинга точно нет. проверял. на шиндоус тоже не наблюдается тротлинга. и это самый тротлинг не может вот таким уж точно.
а вот почему страдать должен один цпу и все всегда забывают о нагреве южника и северника?

Да, члучше всего накатить ядро 4.2 и посмотреть, как на нём.

Проверить температуру северного и южного мостов как? И опять же, сколько я помню показания аиды на шиндоус, то мосты не перегревались никогда.

Всё же предлагаете попробовать свежее ядро?

Да, свежее ядро. Тут нечего обсуждать. В каждом выпуске - фиксы. Твоя версия ядра значительно отстала и не содержит ряд нововведений и фиксов.

Видеокарта nvidia gt635m. Драйвер стоит блоб. Но внешняя отключена, всё работает на встроенной интеловской. Какие там на ней дрова - понятия не имею.

А установка нового ядра такого не поломает всю систему? А то машина рабочая. Бекапы есть конечно же, но всё же. Ни разу таким не занимался.

Проверить температуру северного и южного мостов как?
пальцем? сенсорами?

пирометром

Сенсорами конечно же) при их наличии, конечно. Пальцем не надо. Может какой lm-sensors это умеет?

у гигабайта были какие-то, кроме цпу, у остальных хз.

Если старое ядро удалять не будешь, то не поломает.

Постоянная запись на HDD в несколько процессов(запись ведётся на раздел NTFS), сама кубунта на SSD. ЗАпускается виртуалка windows 10 в virtualbox.По показаниям ksysguard ещё остаётся 1.2 гб рамы. На SSD как в корне, так и в хомяке места достаточно. swap отключён.

Фризится при таком раскладе каждый раз. Причём именно во время загрузки вирт. машины(которая сама находится на HDD на ext4)

Добро пожаловать в клуб! теперь ты открыл тёмную сторону linux и знаешь о неисправимом баге 12309, который ребята никак не могут пофиксить. Вместо этого они предлагают купить суперкомпьютер, для которых linux предназначен.

iostat что говорит?

смена ядра на 4.2.0 не помогло. Проблема осталась

вот ещё выхлоп dmesg после установки 4.2.0 во время лагов очередных: http://pastebin.com/KTsDhKsM

Ещё ставь intel microcode patch и генеруй нормальный dsdt, гугли это слово, хакинтошники уже проделали большую работу. А как подсунуть его онтопик-ядру читай на арчевики.

Ну и гугление одного из варнингов вывело меня на ошибку: https://bugzilla.kernel.org/show_bug.cgi?id=86561
Ну и классика, которой ещё не было ITT: фирмварь матери обновил?

меняй ядро

но придётся ядро постарше ставить.

может всё-таки помоложе?

Если это твой десктоп, до добавляй ppa kernel ubuntu team. Как-то оно так называется, найдёшь. Я поставил на паре машин ядро 4.2 оттуда, всё хорошо.

оттуда ядро и ставил. результата нет

Итак, что я сделал на данный момент. В хронологическом порядке: 1) Поставил ядро 4.2. Не помогло, проблема осталась 2) Обновил intel microcode. Перезагрузился. ОБновления применились. Не помогло 3) Биос стоит самый последний для моего ноута, так что тут менять нечего. 4) Насчёт dsdt. Есть прога acpidump, которая должна его выдавать. Но у неё на выхлопе у меня только пустой файл 0 байт. Дальше этого я не продвинулся.

Запускал acpidump вот такой командой:

sudo acpidump -b DSDT > /home/zamazan4ik/DSDT.aml

Что дальше? Или я где-то допустил ошибку?

И это нормально, когда файловый вывод на NTFS (а конкретно процесс kio_file) жрёт проц так неслабо? (бывает, что под 10% от моего i7)

так, дамп то я сделал dsdt. Но есть где-нибудь нормальный гайд, как его пропатчить? а то там проги-автопатчеры онли на макось

и меня гложат смутные сомненья, что дело тут вовсе не в кривом dsdt...

Есть и на Java, нужно только подсунуть бинарь iasl поновее Вот тема: http://www.insanelymac.com/forum/topic/223205-dsdt-editor-and-patcher/page-1
Файл я перезалил, т.к. без регистрации не скачаешь: https://yadi.sk/d/ZK0bOoKgjuc7q
По поводу сомнений: было ли это раньше?
Ну и свой исходный dsdt залей куда-нибудь.

На FreeBSD-шное.

Уж лучше на XNU.

файловый вывод на NTFS (а конкретно процесс kio_file

Это не какой-то там «файловый вывод», а процесс kde, который емнип соответствует копированию файлов.

Заводи баг на багзилле ядра, у тебя очень много косяков в dmesg.

Там все еще печальнее, особенно с ФС.

Своп включи - во первых, во вторых - vm.swappiness

при сильной загрузке ЦП(а точнее, при полной загрузке одного ядра)

Может быть, дело в прерываниях, которые доставляются неизменно на первый CPU?