Вы здесь

[~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 написал:
Могу немного рассказать о том что не помогает.
Этот баг не зависит ни от планировщика, ни от файловой системы, ни от архитектуры (x86 и x86_64)
Проявляется при записи/чтении на пределе скорости дисковых устройств.

Есть [подтверждаемое личным опытом] подозрение, что в предельном режиме многое зависит ещё и от контроллера.
Торможение системы --- результат далеко не худший из возможных.

:wq
--
Live free or die

как это не погано звучит и как бы не было обидно, но в оффтопике при аналогичной нагрузке на дисковые устройства не ведет к тормозам, тем более к таким :(

а ты распакуй portage snapshot под оффтопиком, и попробуй полазить по этому каталогу, да посмотри сколько он места занял...

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

Если это так критично - покупай и ставь себе оффтопик.

Это подпись, которую невозможно истолковать неправильно

ты меня не понял :) я не говорю, о том что оффтопик рулит - это было бы в корне неверно. я говорю, что именно этой проблемы в нем нет, хотя других конечно вагон и тележка. да и не надо высокопарных "покупай". все и так знают, что частные лица (особенно подкованные в компьютерной грамоте, и тем более сисадмины, к коим я отношусь) в большинстве случаев не используют лицензионный оффтопик ;) не надо тут холивара. я констатировал факт про этот баг вот и все :) мне самому обидно, что моя любимая ось так тормозит при дисковых операциях ;)

Мне помогло отключение 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 написал:
да, вы правы.. планировщик тут непричем.

Зато мне помогло отключение NCQ:
echo 1 > /sys/block/sda/device/queue_depth
теперь при аццком загрузе dd, vlc стартует моментально и огнелис продолжает скроллить плавно!

Встречался с таким советом, сейчас перепроверил -- не помогает, правда у меня скрипт не просто пишет а читает и пишет то что прочитал рядом в директории (файлы по 2-3 Гб). При этом система не оставляет квантов времени для работы других процессов с системой ввода-вывода =( а уже загруженная опера стабильно раз в 2-3 минуты отказывается отвечать на управление на 10-15 секунд (такой вот дикий фриз из-за i/o wait)

4ndrey написал:
А насчет архитектуры, вы это прочитали или сами пробовали?

Личный опыт, две генты на hdd, 32 и 64 бита.

а можно ваш скрипт попробовать?
кстати, я там исправил предыдущее сообщение.
щас заменил, что все-таки не все планировщики одинако полезны, например трюк с отключением ncq мне тоже не помог на cfq и deadline, а вот если использовать bfq или fifo или vr, то становится ощутимо лучше.

eix zen-sources
No matches found.

Какой оверлей? Этот планировщик попробовать хочется.
(Про скрипт в личку ответил)

это в zen-overlay
либо сам планировщик отдельно: http://feanor.sssup.it/~fabio/linux/bfq/patches/v2.6.30/

однако, решением проблемы это конечно не назовешь: отключение ncq дает побочный эффект в виде ухудшения быстродействия ( например, программы компилируются существенно дольше)
так что получается палка на двух концах, ладно буду пробовать дальше, если что напишу

О у меня такое же! Но только на 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, нет девелоперов желающих им заняться.. :(

4ndrey написал:
для статистики попробуйте:
dd if=/dev/zero of=/tmp/test bs=1M count=1M
//только вместо /tmp/test пусть к вашему Seagate Free Desktop Agent 1TB (потом не забудьте файл удалить)
и аналогично, на "других УСБ вениках".

во время выполнения данной команды попробуйте позапускать приложения, полазить по инету, как надоест нажмите ctrl-с в консоле и потом поделитесь здесь впечатлениями :)

тормозов нет

Тормоза есть когда

dd if=/dev/sdb of=/home/ftp/pub/sdb

Working on Gentoo Linux for Asus P535 and Qtopia :-)

1. Топикстартер! SATA2 винты нужно ставить в режим AHCI в биос и включать поддержку AHCI в ядре!

Включите AHCI и будет вам счастье ;-)

2. Правильно выберите файловую систему! ;-)

1. поставил, но счастья нет :)
2. а что посоветуете? стоит ext4

я с ней не работал, но ее хорошо рекламируют ;-) думаю, можно оставить... еще посмотрите какой режим журналирования стоит, если полное, то тормоза очевидны ;-)

что говорит dmesg об 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 на отдельном LVM, то тормозов вообще не замечаю... если б не плазмоид с загрузкой процов, то и не замечу, что что-то выполняется...

Вот только при кодировании видео (особенно HD) узкое место - процессор, а не жесткие диски, поэтому и тормозов описанных нет.

попробовал копировать BluRay диски туда сюда по одному винту и с одного на другой, если не задействую диск, на котором корень, то вообще ничего не замечаю =))) возможно это потому, что винт с корневой ФС 80ГБ и очень старый SATA1, остальное SATA2 и новое (~год)... возможно потому, что 8ГБ оперативы и полностью отсутствует подкачка... в общем я на свою систему не жалуюсь =) если и есть тормоза какие, то они ожидаемы...

Включено ли в ядре

# DMA Devices
CONFIG_INTEL_IOATDMA=y
CONFIG_DMA_ENGINE=y

? Помнится, были аналогичные проблемы из-за того, что не заметил, как отключил DMA. :)

было выключено, включил, пересобрал ядро - лучше не стало :(

покажи hdparm -I /dev/sda
если не стесняешься

таже проблема, но только при запуске transmission c 71 торентами, виснет всё: опера, кеды, всё, через пару минут отпускает.
фс системы рейзер4, папки хоум рейзер3

localhost ss # hdparm -T -t  /dev/sda

/dev/sda:
 Timing cached reads:   11374 MB in  2.00 seconds = 5692.75 MB/sec
 Timing buffered disk reads:  258 MB in  3.01 seconds =  85.66 MB/sec
localhost ss # uname -a
Linux localhost 2.6.30.2 #1 SMP Tue Jul 21 20:23:07 YEKST 2009 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux

думаю, природа проблемы та же, посмотрите на работу программ при: dd if=/dev/zero of=/tmp/test bs=1M count=1M

обновил ядро до 2.6.30.2, вроде не тормозит

пользую ядро 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...