Зашкаливает %wa при создании образов в brasero

Когда создаю ISO образ в программе brasero (другие пока не пробовал), то всё начинает дико тормозить. Когда в top смотрю загрузку прцоессора (top, потом 1), то одно из ядер (обычно четвёртое) имеет в колонке %wa под 100%. Это ж получается, что ядро долго ждёт окончания операции ввода/вывода (видимо с HDD), так? Остальные ядра загружены не сильно, примерно 95% idle. Но всё равно всё ужасно тормозит :( В чём может быть проблема?

Процессор Phenom II x4 955 (3.2ГГц), памяти 2x2Гб DDR3 1333MHz, винты Samsung HD160JJ и HD502IJ, конкретно образ пишу на первый винт, система установлена на нём-же.

Значит у вас I/O система

Значит у вас I/O система хилая. A одно ядро - потому как программа однопотоковая.
Для точной диагностики посмотрите sar, iostat, vmstat.
Ну и, на всякий случай, предварительно убедитесь, что в системных логах нет ошибок, а то может просто диск дохлый.

iostat: Linux

iostat:

Linux 2.6.39-gentoo-r3 (localhost) 	08/19/2011 	_x86_64_	(4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3.22    0.00    0.75    7.14    0.00   88.90

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sdb              52.51      5201.41         0.11   41352692        872
scd0              0.01         0.03         0.00        242          0
sda              82.14      2316.06      2734.99   18413305   21743970

vmstat:

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  1     24  42916  34984 3174004    0    0  1879   683  515  613  3  1 89  7

sar не работает:

Cannot open /var/log/sa/sa19: No such file or directory

Я понимаю ,что одно ядро загружается из-за однопоточности, но почему всё тормозит? Другие процессы вполне могут работать на других ядрах, не могут же все попасть на одно. Ну да ладно.. Можно ли что-то настроить?

Смотреть надо не так, а,

Смотреть надо не так, а, например

iostat 1 111
vmstat 1 111

детали - в мане!

Процессы тормозят из-за затыка в канале ввода/вывода, поэтому процессор/ядра вообще ни при чем.
Настраивать тут практически нечего - надо железо менять!... ;)
Кстати, что у вас за диски - САТА/ПАТА?
Как включены?
Покажите (разумеется на холостом ходу)

hdparm -tT /dev/sd?

Диски SATA, включены просто в

Диски SATA, включены просто в SATA разъёмы на материнке. Материнка MSI 770-C45. Вывод hdparm:

/dev/sda:
 Timing cached reads:   7772 MB in  2.00 seconds = 3887.30 MB/sec
 Timing buffered disk reads: 188 MB in  3.02 seconds =  62.17 MB/sec

/dev/sdb:
 Timing cached reads:   7566 MB in  2.00 seconds = 3784.18 MB/sec
 Timing buffered disk reads: 272 MB in  3.02 seconds =  90.15 MB/sec

вроде все нормально. покажите

вроде все нормально. покажите еще

dmesg |grep -i -e sd -e gb

и с вами будет все ясно... ;)

Command line:

Command line: root=/dev/sda3
Using GB pages for direct mapping
ACPI: RSDP 00000000000faaf0 00014 (v00 ACPIAM)
ACPI: RSDT 00000000c7f90000 00040 (v01 7599MS A7599100 20100904 MSFT 00000097)
ACPI: DSDT 00000000c7f905d0 098F4 (v01  A7599 A7599100 00000100 INTL 20051117)
ACPI: SSDT 00000000c7f9a000 0088C (v01 A M I  POWERNOW 00000001 AMD  00000001)
Kernel command line: root=/dev/sda3
Aperture beyond 4GB. Ignoring.
ACPI: EC: Look up EC in DSDT
Installing knfsd (copyright (C) 1996 ).
ahci 0000:00:11.0: AHCI 0001.0100 32 slots 4 ports 3 Gbps 0xf impl SATA mode
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
sd 0:0:0:0: [sda] 312581808 512-byte logical blocks: (160 GB/149 GiB)
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 1:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 1:0:0:0: Attached scsi generic sg1 type 0
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
 sdb: sdb1 sdb2 < sdb5 >
sd 1:0:0:0: [sdb] Attached SCSI disk
EXT3-fs (sda3): error: couldn't mount because of unsupported optional features (240)
EXT2-fs (sda3): error: couldn't mount because of unsupported optional features (240)
EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null)
EXT4-fs (sda3): re-mounted. Opts: (null)
EXT4-fs (sda4): mounted filesystem with ordered data mode. Opts: (null)
EXT3-fs (sdb5): using internal journal
EXT3-fs (sdb5): mounted filesystem with writeback data mode
Adding 1060284k swap on /dev/sda2.  Priority:-1 extents:1 across:1060284k 
EXT4-fs (sda3): re-mounted. Opts: commit=0
EXT4-fs (sda4): re-mounted. Opts: commit=0

Все у вас нормально с

Все у вас нормально с железом, если что не устраивает - ставьте отдельный контроллер на каждый диск - иначе ничего лучшего, скорее всего не доб'етесь. Кстати, - будьте осторожны с дешевыми контроллерами, перед покупкой обязательно почитайте специализированные форумы и статьи - многие из них достаточно левые, например, один какой-то после получаса работы терял ДМА и, соответственно, на порядок падала скорость.

P.S. из приведенных вами данных не увидел зашкаливания - на в/в только 7%!.;)
Посмотрите, что будут показывать iostat/vmstat (в цикле) при работе программы - возможно появятся идеи..
Можете попробовать поиграться с ядром (scheduler'ы и все такое).
Также поройтесь в Интернете на предмет торможения системы из-за интенсивного в/в - очень много инфы, особенно по SATA, ну и, конечно, на английском. Может и на русском найдете - я не смотрел.

Успехов!

/

SysA написал(а):
Настраивать тут практически нечего - надо железо менять!... ;)

Кстати, по моим наблюдениям именно i/o сейчас является узким местом (а не объем оперативной памяти или характеристики процессора, разработчики коих пришли в такой уютненький тупичок).
Особенно если соотнести с терабайтными размера накопителей.

Но чисто теоретически можно допустить и странную логику приложения.
Если сравнить с стандартным:
mkisofs -r -D -J -o image.iso source_dir/
как оно?

:wq
--
Live free or die

Да то же самое - 96%wa...

Да то же самое - 96%wa... Только не виснет ничего :) А с brasero получается, что другие окна сереют и не отвечают (в частности FireFox).

96% нормально. У меня в

96% нормально. У меня в конторе хапэшные серваки уже на 15~25% умирают в прямом смысле слова ;)

Ну вот я сейчас запустил

Ну вот я сейчас запустил копирование большого файла (фильм 18Гб) с одного винта на другой - тоже 90-95%, при этом ничего не тормозит. А значит и не напрягает. То похоже в brasero какие-то косяки. Всем спасибо.

Посмотрите что покажет cat

Посмотрите что покажет cat /sys/class/block/sd[a,b]/queue/scheduler , возможно там noop, поставьте cfq (или наоборот), не факт что поможет, но попробовать можно. 12309 суров.

Вобщем сам заинтересовался,

Вобщем сам заинтересовался, потестил iozone -O -i0 -i2 -s4g -r64k на noop, deadline и cfq. При noop и deadline жёсткий 12309, вплоть до зависания мыши в иксах (deadline чуть быстрее чем noop, процентов на 3-8), а вот с cfq всё на удивление гладко, и не намного медленнее чем с deadline, зато системой можно пользоваться даже при высоком уровне i/o операций.

                                   random  random
     KB  reclen   write rewrite    read    write
4194304      64    2092    2148    5749    2196

noop обычно с NCQ включают.

noop обычно с NCQ включают.

$ dmesg | grep -i ncq [

$ dmesg | grep -i ncq
[    1.390656] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part 
[    1.896800] ata1.00: 250069680 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[    1.906779] ata2.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
[    2.048143] ata3.00: 1465147055 sectors, multi 0: LBA48 NCQ (depth 31/32), AA

интересно. Надо тоже

интересно. Надо тоже протестировать на досуге

Там вот так: noop deadline

Там вот так:

noop deadline [cfq]

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".