опять про iowait bug
petrun 5 марта, 2010 - 18:24
Предыстория :
Ох и намучался же я с ним.Запись в один поток на диск - терминал открывается 5-10 сек, в несколько потоков - можно идти пить чай.
История :
А вчера решил поставить libre сорцы(с вырезанными блобами, все из себя свободные), просто ради интереса, глянуть заведется ли что-нибудь.
И, о чудо, баг исчез.Нет, при записи в несколько потоков интерактивность системы несколько снижается, но видимо дело только в забитом дисковом кеше.
Сейчас занят изучением diffа, но пока ничего полезного не нашел.Из меня сомнительный программист, так что знающим, и тем кому этот баг просто сильно надоел прошу помочь.
% uname -a Linux petrun-home 2.6.33-libre #3 SMP PREEMPT Fri Mar 5 15:47:34 MSK 2010 x86_64 Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz GenuineIntel GNU/Linux
Ни с gentoo, ни с zen, ни с ванильными сорцами такого нет.
»
- Для комментирования войдите или зарегистрируйтесь
Имхо не обязательно именно
Имхо не обязательно именно libre. Всё дело в верси ядра.
В патчнотах 33-го было указано, что алгоритм работы CFS был оптимизирован для условий высокой нагрузки на i/o подсистему.
Вы попробуйте =sys-kernel/gentoo-sources-2.6.33 , долно быть так-же.
Я,наверное, неправильно
Я,наверное, неправильно выразился.В том-то и дело, что в других доступных *.33 не так же.
вот из личного опыта
не помню где, случайно в сети наткнулся на такую рекомендацию:
echo 10 > /proc/sys/vm/swappiness
echo 1000 > /proc/sys/vm/vfs_cache_pressure
проблем почти ноль. но если не задействуется своп. если начнет юзаться - будет то же самое что с дефолтными значениями (60 и 100 соответственно), на работу можно забить :) конечно это если своп, система и остальная свалка на одном диске. на разных еще не доходило как то проверить.
Ну да, с таким же успехом
Ну да, с таким же успехом можно вообше кеш выключить.Это не решение - маскировка.
А мне кажеться, что настоящее рещение где-то рядом (с)
У меня нет swap и 8 гиг
У меня нет swap и 8 гиг оперативы - и оно тупиииииит. понятно что когда используется swap оно ещё больше тупить будет, но...
iowait
Парни, подскажите, как воспроизвести данный "тупёж" системы?
Сейчас поставил систему на бэкап с помощью rsync - светодиод, индицирующий
работу дисков просто горит, даже и не думает моргать.
При этом я вполне себе комфотрно сижу в иксах, музЫка играет без рывков, консоли и всякая
дребедень открываюстя без тормозов... ЧЯНТД?
ядро: 2.6.32-gentoo-r5
- - -
А разве этот тупняк был не только на nForce чипсетах со сломанным ADMA?
http://bugzilla.kernel.org/show_bug.cgi?id=12309
http://osdir.com/ml/linux-kernel/2009-04/msg02590.html
Или речь о другом тупняке?
Дык скока времени прошло уже...
Я думаю, что в их случае сильно эксплуатируется "южный мост", при чём не только
дисковой подсистемой, а - сетевыми гигабитными карточками, например или встроенным
звуковым кодеком. Вся эта свора процессов, требующая активного доступа к PCI шине
терзает "южанина", вот мы и получаем "и-о-вайт буг"
Хотя, мо-быть я и не прав ;)
Речь именно о том баге что на
Речь именно о том баге что на kernel.org но, если почитать то что там написано проблема не в энвидиевском мосте, не в сорте планировщика и не в NCQ, хотя всякие танцы с бубном отодвигают слегка этот баг. Предпоследний на этот момент комментарий «доставляет».
UPD ещё написано что баг провоцируют java софтины, возможно мою ситуацию усугубляет то что я использую торрент-клиент Vuze который на яве и там сотни две торрентов, пару месяцев назад я даже игрался с ulimit на предмет открытых файлов.
у меня тупняк возникает при
у меня тупняк возникает при svn up больших репов, типа оверлея сабайона, но только в момент после запуска синхронизации и до момента когда svn начал что-то выводить на экран, менее жёсткие тупняки когда копирую что-то большое на флэшку или другой винт, при emerge --sync во время регенерации кэша.
iowait?
evadim, как я понимаю Вашу ситуацию: Во время синхронизации svn идёт
интенсивный обмен пакетами + поиск по базе данных на локальном диске, что
тоже сильно грузит "хонтийца" (южный мост)? Что-то мне сдаётся, что
тут ядро-то и не при чём, собственно.
З.Ы: могу лишь предложить зайти на сайт производителя вашей мать-платы,
посмотреть обновления BIOS, как-либо связанные с улучшениями режима
DMA, после чего - сами знаете, что делать :)
BIOS стоит последний, только
BIOS стоит последний, только проблема появилась после очередного обновления ядра, давным давно. И вообще к такому эффекту приводит именно большая нагрузка на hdd. Новых версий BIOS'а нету.
На ядрёной багзилле
На ядрёной багзилле высказывалось мнение что этот баг проявляется только на x86_64. У когонить на x86 эта бага проявляется?
Кажеться пахнет булочками ...
lexa_ написал(а): На ядрёной
кстати да, после смены железа с P4 на CoreDuo и перехода на х86_64 стал замечать такую ерунду, до этого все было отлично.
________________________
"We Will Win"Я бы очень попросил
Я бы очень попросил страдальцев имеющих данные проблемы на x86 отписаться, чтоб укрепить/разрушить мою уверенность в том что это x86_64 специфичный косяк.
Кажеться пахнет булочками ...
lexa_ написал(а): Я бы очень
У меня на x86 никаких проблем нет.На x86_64 есть.
На одном и том-же железе?
На одном и том-же железе?
Кажеться пахнет булочками ...
да.Core i7 960, мать на
да.Core i7 960, мать на p55(gigabyte P55-UD3), 4 гига памяти.
Может это связано с
Может это связано с использованием контроллера ICH10 ?
Кажеться пахнет булочками ...
Нет, не в ICH10 дело. На
Нет, не в ICH10 дело. На контроллере от nvidia (MPC55) баг тоже есть. Точнее на ядрах 26-31 был, 32-ое не ставил. Выражался в диком тупняке системы при копировании больших файлов между разными hdd. Сейчас на 33-м всё гладко, процентов на 95 это баг то-ли исправлен, то-ли скрыт. Надеюсь всё-таки исправлен.
Ну у меня он и на 33 ядре
Ну у меня он и на 33 ядре есть, и даже не при копировании больших файлов возникает а иногда спонтанно.
Включил block_dump(echo 1 > /proc/sys/vm/block_dump)(если будете так делать отключите сислог, или направле klog в консоль а не на диск), чтоб смотреть кто на диск пишет, однако во время фриза никакой особой активности дисковой ненаблюдалось, а лампочка на диске горит. Такчто я во всём виню контроллер.
P.S. с выключенным NCQ вроде стало получше, но это не лекарство.
Кажеться пахнет булочками ...
Знаете, я тут вспоминал что
Знаете, я тут вспоминал что ещё я в конфиге ядра менял при переходе с 31 на 33, и вспомнилось вот что, было:
Kernel hacking ---> IO delay type (port 0x80 based port-IO delay [recommended])
стало:
Kernel hacking ---> IO delay type (no port-IO delay)
может это и ересь, но почему бы и нет? Попробуйте.
Скажите пожалуйста своё
Скажите пожалуйста своё железо(особенно интересен контроллер) и конфиг ядра.
Кажеться пахнет булочками ...
sata_nv
zcat /proc/config.gz
lshw
nVidia MCP55 sata, модуль ядра sata_nv
petrun
Это заговор корпораций против Linux, очевидно же. =)
Однако в RHEL с кучей бэкпортов (и блобов) и ядром 2.6.18-53.1.19.el5 подобных проблем нет.
Данная тема уже становится неким баяном, в рассылке
неоднократно поднималась, предлагались разные решения, высказывались разные гипотезы о природе сего явления.
taaroa написал(а): Однако в
Вот на CentOS 5 (тот же RHEL 5) те же проблемы
________________________
"We Will Win"и?
Все работает просто замечательно (хотя, наверное может и еще лучше).
А подобные Вашей ссылки мало о чем говорят, что то у кого то как то... кстати из той же ссылки, там товарищ обновил ядрышко ("обновился до версии CentOS 5.3, 2.6.18-128.el5") и проблемы "магически" отпали.
taaroa написал(а): petrun
Так 2.6.18 же.Кажется проблема позже появилась.Видимо не те бэкпорты)
petrun написал(а):taaroa
Вроде того.
Три системы на amd64, никогда
Три системы на amd64, никогда не замечал. Везёт мне, однако.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Можно узнать какие
Можно узнать какие материнки(в основном интересно какие диковые контроллеры используются)?
Кажеться пахнет булочками ...
В профиле всё железо на
В профиле всё железо на основных машинах указано (-:Е
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Покажите пожалуйста конфиг
Покажите пожалуйста конфиг ядра вот с этой машинки: AMD Athlon64 3000+, 2 Гб DDR, ESI Juli@, nVidia GeForce 7600 GS @ ASUS K8N-VM
Кажеться пахнет булочками ...
Цитата: % wgetpaste -s ca -c
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.