[~solved] Тормозит система во время операций с диском
Приветствую всех!
Собственно проблема изложена в теме.
Немного поясню. В простое все работает замечательно, но стоит начать копировать с раздела на раздел (либо из сети) чего-нибудь тяжелое (несколько гигов) начинаются жуткие тормоза: приложения открываются по 10 секунд, подтормаживает скроллинг в firefox и отклик приложений на какие-либо команды тоже увеличивается..
Система вроде неслабенькая: intel dual-core e5200 @4ghz + 2gb ram @1ghz, винт seagate sata2 80gb
В ядре вроде ничего изысканного не включаю.
Стоят планировщик CFQ + preemtible RCU
В логах никакой ругани по поводу жесткого диска.
hdparm -T /dev/sda:
/dev/sda:
Timing cached reads: 3600 MB in 2.00 seconds = 1800.06 MB/sec
hdparm -t /dev/sda:
/dev/sda:
Timing buffered disk reads: 200 MB in 3.01 seconds = 66.35 MB/sec
Флаги стоят:
CFLAGS="-march=native -O2 -pipe"
LDFLAGS="-Wl,--as-needed"
В чем может быть дело?
Заранее благодарен за любую помощь :)
UPD:
Решение
1) перейти с амд64 обратно на x86 архитектуру (что я и сделал, ибо надоели проблемы с java, лень держать emul-libs
и т п)
2) если очень хочется амд64, но сильно мешают тормоза: отключить NCQ (это означает потеря производительности) + планировщик BFQ или VR
- Для комментирования войдите или зарегистрируйтесь
советую изучить
советую изучить http://bugzilla.kernel.org/show_bug.cgi?id=12309
багу год скоро, отловить не могут =( проявляется после 16-18-й версии ядра.
спасибо, не знал что так
спасибо, не знал что так печально все..
а вы для себя нашли какое-нибудь решение?
я поставил пару патчей - не помогло.
решил попробовать zen-sources с планировщиком BFQ, вроде немного получше стало..
vlc например запустился и почти не подвисает при `dd if=/dev/zero of=/tmp/test bs=1M count=1M`, а вот огнелис продолжает захлебываться.
Могу немного рассказать о том
Могу немного рассказать о том что не помогает.
Этот баг не зависит ни от планировщика, ни от файловой системы, ни от архитектуры (x86 и x86_64)
Проявляется при записи/чтении на пределе скорости дисковых устройств.
Я перепробовал множество вариантов настройки ядра, но к сожалению локализовать не получилось -- улучшения на уровне "вроде полегче", но это самообман.
Пока что моё "решение" (если это можно так назвать) не нагружать на 100% дисковую подсистему, иначе лаги иксов и ожидания запуска терминала по минуте. Дело в том что у меня железо старое, планирую скоро апгрейд, надеюсь смена чипсета nVidia 570 SLI на что-то поновее решит проблему, потому что для этого шлака ничего нового в плане драйверов в ядре не предвидеться =(
haku написал(а):Могу немного
Есть [подтверждаемое личным опытом] подозрение, что в предельном режиме многое зависит ещё и от контроллера.
Торможение системы --- результат далеко не худший из возможных.
:wq
--
Live free or die
как это не погано звучит и
как это не погано звучит и как бы не было обидно, но в оффтопике при аналогичной нагрузке на дисковые устройства не ведет к тормозам, тем более к таким :(
а ты распакуй portage
а ты распакуй portage snapshot под оффтопиком, и попробуй полазить по этому каталогу, да посмотри сколько он места занял...
тут поднимается не вопрос
тут поднимается не вопрос эффективности файловых систем, или проблема сжирания места мелкими файлами за счет большого размера блока ФС. а вопрос резкого падения производительности системы( в частрости жестких тормозов) при нагрузках на диск на пределе его скоростых хаарктеристик. так вот под оффтопиком при таких нагрузках нет проблем с общей производительностью системы.
.
Если это так критично - покупай и ставь себе оффтопик.
Это подпись, которую невозможно истолковать неправильно
ты меня не понял :) я не
ты меня не понял :) я не говорю, о том что оффтопик рулит - это было бы в корне неверно. я говорю, что именно этой проблемы в нем нет, хотя других конечно вагон и тележка. да и не надо высокопарных "покупай". все и так знают, что частные лица (особенно подкованные в компьютерной грамоте, и тем более сисадмины, к коим я отношусь) в большинстве случаев не используют лицензионный оффтопик ;) не надо тут холивара. я констатировал факт про этот баг вот и все :) мне самому обидно, что моя любимая ось так тормозит при дисковых операциях ;)
Мне помогло отключение NCQ
Мне помогло отключение NCQ (планировщик bfq, на других все попрежнему):
echo 1 > /sys/block/sda/device/queue_depth
теперь при аццком загрузе dd, vlc стартует моментально и огнелис продолжает скроллить плавно!
А насчет архитектуры, вы это прочитали или сами пробовали?
Просто тут: http://bugzilla.kernel.org/show_bug.cgi?id=7372 некоторые пишут, что на 32 битах все несколько оптимистичнее..
Сам Andrew Morton там признался, что понятия не имеет что пошло не так начиная с ядра 2.6.17.
А баг действительно "бородатый" и обсуждается также еще тут: http://forums.gentoo.org/viewtopic-t-482731-postdays-0-postorder-asc-start-850.html
4ndrey написал(а):да, вы
Встречался с таким советом, сейчас перепроверил -- не помогает, правда у меня скрипт не просто пишет а читает и пишет то что прочитал рядом в директории (файлы по 2-3 Гб). При этом система не оставляет квантов времени для работы других процессов с системой ввода-вывода =( а уже загруженная опера стабильно раз в 2-3 минуты отказывается отвечать на управление на 10-15 секунд (такой вот дикий фриз из-за i/o wait)
Личный опыт, две генты на hdd, 32 и 64 бита.
а можно ваш скрипт
а можно ваш скрипт попробовать?
кстати, я там исправил предыдущее сообщение.
щас заменил, что все-таки не все планировщики одинако полезны, например трюк с отключением ncq мне тоже не помог на cfq и deadline, а вот если использовать bfq или fifo или vr, то становится ощутимо лучше.
eix zen-sourcesNo matches
Какой оверлей? Этот планировщик попробовать хочется.
(Про скрипт в личку ответил)
это в zen-overlay однако,
это в zen-overlay
либо сам планировщик отдельно: http://feanor.sssup.it/~fabio/linux/bfq/patches/v2.6.30/
однако, решением проблемы это конечно не назовешь: отключение ncq дает побочный эффект в виде ухудшения быстродействия ( например, программы компилируются существенно дольше)
так что получается палка на двух концах, ладно буду пробовать дальше, если что напишу
hddd
О у меня такое же! Но только на USB венике Seagate Free Desktop Agent 1TB
Причем на других УСБ вениках такой проблемы нет, хотя мне иногда кажется что это из-за файловой системы ext3
Working on Gentoo Linux for Asus P535 and Qtopia :-)
для статистики попробуйте:
для статистики попробуйте:
dd if=/dev/zero of=/tmp/test bs=1M count=1M
//только вместо /tmp/test пусть к вашему Seagate Free Desktop Agent 1TB (потом не забудьте файл удалить)
и аналогично, на "других УСБ вениках".
во время выполнения данной команды попробуйте позапускать приложения, полазить по инету, как надоест нажмите ctrl-с в консоле и потом поделитесь здесь впечатлениями :)
пробовал также. тормоза
пробовал также. тормоза просто ядерные. нагрузка проца около 95% обоих потоков (HT) причем. top говорит, что wa=75% остальное отжирает dd.
будем ждать фикса :)
ждать то будем конечно, но
ждать то будем конечно, но судя по состоянию бага на bugzilla.kernel.org, нет девелоперов желающих им заняться.. :(
И я :)
тормозов нет
Тормоза есть когда
Working on Gentoo Linux for Asus P535 and Qtopia :-)
1. Топикстартер! SATA2 винты
1. Топикстартер! SATA2 винты нужно ставить в режим AHCI в биос и включать поддержку AHCI в ядре!
Включите AHCI и будет вам счастье ;-)
2. Правильно выберите файловую систему! ;-)
1. поставил, но счастья нет
1. поставил, но счастья нет :)
2. а что посоветуете? стоит ext4
я с ней не работал, но ее
я с ней не работал, но ее хорошо рекламируют ;-) думаю, можно оставить... еще посмотрите какой режим журналирования стоит, если полное, то тормоза очевидны ;-)
что говорит dmesg об AHCI? есть уверенность, что подцепилось?
вообще имхо при нагрузке на винт всё и должно подтормаживать, если копирование происходит на винт, на котором располагается корень...
dmesg | grep ahci: ahci
dmesg | grep ahci:
ahci 0000:00:1f.2: version 3.0
ahci 0000:00:1f.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
ahci: SSS flag set, parallel bus scan disabled
ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pio slum part ems
ahci 0000:00:1f.2: setting latency timer to 64
А насчет журналирования, то ничего дополнительно не настраивал, не знаю как там по умолчанию..
Насчет вашего имхо, вот например в оффтоповых системах такого почему-то не наблюдается, хоть блюрейные образы туда-сюда копируй: браузер при этом продолжает работать как ни в чем не бывало.
Так что мое имхо: нужно разумно управлять ресурсами, пусть фильмы копируются, но тогда не на пределе возможностей винта, чтобы это не мешало другим программам.
PS: А у вас, например, все нормально во время выполнения команды: dd if=/dev/zero of=/tmp/test bs=1M count=1M ?
ну, допустим у меня несколько
ну, допустим у меня несколько винтов:
когда я выполняю eix-update то у меня один проц грузится на 100% и запускаемые проги запускаются дольше... в принципе любые проги, которые обращаются к диску работают медленне... остальные (что висят в памети) работают без тормозов...
однако если я кодирую пару фильмов в HD на отдельном LVM, то тормозов вообще не замечаю... если б не плазмоид с загрузкой процов, то и не замечу, что что-то выполняется...
Цитата:однако если я кодирую
Вот только при кодировании видео (особенно HD) узкое место - процессор, а не жесткие диски, поэтому и тормозов описанных нет.
попробовал копировать BluRay
попробовал копировать BluRay диски туда сюда по одному винту и с одного на другой, если не задействую диск, на котором корень, то вообще ничего не замечаю =))) возможно это потому, что винт с корневой ФС 80ГБ и очень старый SATA1, остальное SATA2 и новое (~год)... возможно потому, что 8ГБ оперативы и полностью отсутствует подкачка... в общем я на свою систему не жалуюсь =) если и есть тормоза какие, то они ожидаемы...
Включено ли в ядре # DMA
Включено ли в ядре
? Помнится, были аналогичные проблемы из-за того, что не заметил, как отключил DMA. :)
было выключено, включил,
было выключено, включил, пересобрал ядро - лучше не стало :(
покажи hdparm -I
покажи
hdparm -I /dev/sdaесли не стесняешься
таже проблема, но только при
таже проблема, но только при запуске transmission c 71 торентами, виснет всё: опера, кеды, всё, через пару минут отпускает.
фс системы рейзер4, папки хоум рейзер3
думаю, природа проблемы та
думаю, природа проблемы та же, посмотрите на работу программ при: dd if=/dev/zero of=/tmp/test bs=1M count=1M
обновил ядро до 2.6.30.2,
обновил ядро до 2.6.30.2, вроде не тормозит
пользую ядро 2.6.30-r3 с
пользую ядро 2.6.30-r3 с патчем BFQ. При запуске dd if=/dev/zero of=/mnt/test bs=1M count=1M особо тормозов нет. Тормоза проявляются когда запускаю еще что-нибудь тяжелое (виртуальную машину).
Продолжение эпопеи с багом
Продолжение эпопеи с багом здесь - http://bugzilla.kernel.org/show_bug.cgi?id=12309#c397
Желающих плотно тестить этот баг похоже немного.
- - -
Аналогичная проблема на x86. Подпишусь, что бы отслеживать тему...
- - -
А почему у некоторых такой проблемы не наблюдается? Може все дело в контролере?...
У меня nForce560, может для этого контролера есть какой-нибудь другой драйвер?
Самого, вроде бы, данная
Самого, вроде бы, данная проблема не беспокоит, но в ближайшем времени собираюсь перейти на amd64, поэтому немного взволнован.
А никто не пробовал тестовый патч (http://bugzilla.kernel.org/show_bug.cgi?id=12309#c360, для новых ядер обновление чуть ниже)? Люди, отписывающиеся там, говорили что им помогало, причем "фантастически".
P.S. Intel Corporation 82801IB (ICH9) 2 port SATA IDE Controller на ASUS P5K
- - -
Приложил я этот патч (из поста 366 на .30 ядро) - на глазок стало немного лучше - а
приборыtop все равно показывают так же: 2.3%us, 15.0%sy, ..., 80.1%wa, во время dd...