LINUX.ORG.RU

Тормоза при интенсивном IO


0

0

При копировании толстого файла наблюдаются тормоза. Вся гуйня периодически замирает, дикие задержки при переключении окон, одно ядро загружено на 100%, второе на ~50%. Копировал разными способами, с HDD на внешний диск и на тот же раздел; использовал cp, dd и гуйню, симптомы одинаковые везде.

Файловая система на источнике ext3. Железо не дохлое, камень на 2 ядра, 2Гб ОЗУ (свободно было около 700Мб). Диск SATA WDC WD1600AAJS, контроллер ATI SB600. Дебиан тестинг, все пакеты свежие, ведро 2.6.30-2-686.

В чем может быть причина? Баг в ядре? hdparm говорит что HDD работает в udma6, но ощущения как от pio.

★★★★★

У меня тоже дикие тормоза при копировании троло^Wтолстых файлов. У всех остальных на ЛОРе все отлично, мы просто что-то неосилили.

slyjoe
()

Попробовал с ext4 на ext4, те же тормоза, так что дело не в ФС

nu11 ★★★★★
() автор топика

на тот же раздел

Омг,

HDD на внешний диск

Омг.

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

wfrr ★★☆
()
Ответ на: комментарий от wfrr

>В обоих случаях данные могут копироваться через буфер в оперативке.

они и копируются, но CPU это сильно нагружать не должно, man dma. У меня же нагружается как при обычном pio. Во времена 2.6.1x такого безобразия не помню.

hdparm -i /dev/sda

/dev/sda:

Model=WDC, FwRev=05.06H05, SerialNo=WD-WMAP95644202
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=50
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=312579695
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

* signifies the current active mode

nu11 ★★★★★
() автор топика

У меня то же самое было. В ядре баг, судя по всему, причём проявляется и на CFQ и на BFQ. Откатился на .30 - помогло.

xetf ★★
()
Ответ на: комментарий от isden

планировщики пробовал крутить, ionice -c 3 в сочетании с nice 10 немного помогают. Но мне непонятно почему CPU вообще так сильно загружается при дисковых операциях. Читай предыдущий пост.

nu11 ★★★★★
() автор топика
Ответ на: комментарий от xetf

>Откатился на .30 - помогло.

у меня и так 2.6.30 :)

nu11 ★★★★★
() автор топика
Ответ на: комментарий от isden

>с elevator=deadline отлично пашет.

переключил на deadline, полегчало, но лучше всех оказался старый добрый anticipatory. Долбаные красноглазые разработчики с их тестами на серверах :(

nu11 ★★★★★
() автор топика
Ответ на: комментарий от isden

cfq конечно же, его давно уже дефолтным пихают почти во всех дистрах, начиная с 18го ведра. Вроде как на загруженных серверах он дает лучшую суммарную производительность. Но на десктопе нафик не нужен.

А в бубунте что сейчас по дефолту? Неужели deadline? anticipatory не пробовал?

nu11 ★★★★★
() автор топика
Ответ на: комментарий от nu11

> А в бубунте что сейчас по дефолту? Неужели deadline? anticipatory не пробовал?

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

isden ★★★★★
()

была такая же фигня с cfq (bfq толком не пробовал, ибо система висла)

сделал, как тут кто-то советовал - поставил в биосе режим AHCI и планировщик noop

в итоге, при копировании 2-гигового файла с ext4 на XFS (диск один и тот же) скорость ошеломляет - >100Мб/сек, но тормоза гуя просто огуевающие

ierarx
()
Ответ на: комментарий от nu11

Интересная у вас жизнь, однако!

Погонял сейчас файл 4.4Гб при разных io schedulers, проверил на всех 4-х. Ощущения работы гуя одинаковые, ЦПУ загружен ~ одинаково (15-20%), время копирования 153-162 сек (скорость 28-29MB/s)

При каждом прогоне запускал еще oowriter посмотреть на отзывчивость системы

скрипт простой:

#!/bin/bash

if [ $# -lt 3 ]; then
        echo "Usage: $0 <noop|cfq|anticipatory|deadline> <src file> /mnt/<dst dir>"
        exit 1
fi

sync

if echo " noop anticipatory deadline cfq " | grep -q " $1 "; then
        echo "$1" > /sys/block/sda/queue/scheduler
        echo "$1" > /sys/block/sdc/queue/scheduler
else
        echo "$1 : IO scheduler not exist"
fi

echo "sda"
cat /sys/block/sda/queue/scheduler
echo "sdc"
cat /sys/block/sdc/queue/scheduler

sync
echo "Drop file cache"
echo "3" > /proc/sys/vm/drop_caches

if [ -f "$2" -a -d "/mnt/$3" ]; then
        echo "Start copy"
        time (cp "$2" "/mnt/$3"; sync)
fi
fn=`basename "$2"`
rm "/mnt/$3/$fn"

Вобщем так и не понял разницы между разными io schedulers

sdio ★★★★★
()
Ответ на: комментарий от sdio

>Ощущения работы гуя одинаковые

а что с гуем делал? У меня 2 экземпляра мозиллы на разных рабочих столах, в каждом по несколько вкладок. Я переключал вкладки в одном, немного крутил страницы туда-сюда. Потом переключал на второй рабочий стол и тыкал вторую мозиллу. Потом переключался между окнами, там был writer и несколько экземпляров окуляра с открытыми книжками. С дефолтным CFQ все это периодически замирало на несколько секунд, иногда даже указатель мыши останавливался, хорошо хоть музыка не прерывалась. С AS небольшие задержки, но все достаточно живо.

Попробуй не очищать кеш, а наоборот начать с забитым кешем. Можно к примеру скопировать один файл, затем другой. У меня обычно большая часть свободной памяти занята кешами, сейчас попробую очистить.

nu11 ★★★★★
() автор топика
Ответ на: комментарий от sdio

Очистил кеш, с cfq стало заметно живее... пока кеш опять не заполнил свободную память :) На anticipatory кеш слабо влияет. Сколько памяти у тебя под кеш используется? Сколько свободной? Копируешь на другой физический диск или на этот же?

nu11 ★★★★★
() автор топика
Ответ на: комментарий от nu11

Цитируем nu11

Копируешь на другой физический диск или на этот же?

С sdc на sda

sdio ★★★★★
()
Ответ на: комментарий от xorik

цитата:

«Фактически это выражается в том, что машина совершенно перестаёт тормозить при 100% загрузке IO Wait (интенсивная работа с винтом, копирование больших файлов и т.п.) Можно в фоне запустить пару компиляций (Gentoo, привет!), копирование файла с винта на винт и при этом десктоп практически не тормозит там, где до этого буквально вставал колом» (про cfq речь)

4.2 какое-то наглое

ierarx
()
Ответ на: комментарий от xorik

Тут 3 варианта. Либо во времена написания той статьи ведро работало по-другому, либо тут влияет vfs_cache_pressure, либо кто-то нагло лжет :)

Поставил vfs_cache_pressure 1000, с cfq ситуация не изменилась. Значит осталось 2 варианта :)

nu11 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.