LINUX.ORG.RU
Форум — Admin  

dd over nfs. Откуда тормоза?


0

0

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

$ sudo dd if=/dev/vg0/lv_root-snapshot of=/srv/dataserver/backup/artem-laptop/lv_root.img

При этом процессор и винт простаивают. И все процессы дружно выстраиваются в очередь на операции чтения/записи.

Пробовал копировать физический раздел - тот же результат. Зато обычные файлы типа киношки копируется без проблем.

К /srv/dataserver/ у меня примонитрована шара через NFS. Сервер - wifi-роутер. К нему подключен внешний накопитель через жутко медленный USB 1, поэтому сам по себе сервер очень медленный.

NFS работает через UDP (TCP не завелся почему-то), подключается следующей командой:

192.168.2.1:/tmp/data /srv/dataserver nfs rw,rsize=8192,wsize=8192,hard,nolock,intr 0 0

Когда комп слегка оживает, top показывает примерно следующую картину:

top - 17:06:01 up 20:43, 3 users, load average: 5.94, 4.04, 2.29
Tasks: 226 total, 1 running, 225 sleeping, 0 stopped, 0 zombie
Cpu(s): 8.8%us, 4.2%sy, 0.0%ni, 32.3%id, 54.3%wa, 0.2%hi, 0.2%si, 0.
Mem: 1017992k total, 947048k used, 70944k free, 51124k buffers
Swap: 1048568k total, 71768k used, 976800k free, 368860k cached



Последнее исправление: raa (всего исправлений: 1)
← Как отловить «eth0: link up» и «eth0: link down»
Centos5.4+OpenLdap2.4+Samba3.52 -Проблемы с правами на файлы →
Ответ на: комментарий от AITap

Побольше? Вы имеете в виду параметр команды dd или mount? Я указывал bs=1024 в dd. Мне показалось, что скорее нужно поменьше, чем побольше. Вроде бы система не так сильно тормозила. Но все равно тормозила.

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

Попробовал bs=102400 - не полегчало.

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

> dma?

$ sudo hdparm -I /dev/sda | grep dma
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
* CFA advanced modes: pio5 *pio6 mdma3 mdma4

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

И вот так подвисает

$ sudo dd if=/dev/zero of=/srv/dataserver/backup/artem-laptop/lv_root.img

А вот так не подвисает

$ sudo dd if=/dev/vg0/lv_root of=/dev/null

Нагрузка чувствуется, конечно, ибо, вероятно, поток данных в этом случае намного выше. Но ничего не виснет, можно спокойно продолжать работать.

raa
() автор топика

У вас при копировании какие-либо другие процессы не пытаются получить доступ к файлам на NFS? А то может запущен какой файловый менджер или ещё что. А смонтированно у вас с опцией hard. Попробуйте сначала запустить top (из корневого или домашнего каталога), а потом посмотреть что происходит при копировании, какие процессы попадают в состояние «D» (uninterruptible sleep).

Может попробовать смонтировать с опцией soft, хотя может будет хуже.

Зато обычные файлы типа киношки копируется без проблем.

Копируются куда? На NFS раздел или на обычный?

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

Спасибо, сейчас попробую.

Зато обычные файлы типа киношки копируется без проблем.

Копируются куда? На NFS раздел или на обычный?


Конечно я говорил об NFS. Локально даже копирование раздела не вешает систему, что и видно из моего предыдущего сообщения.

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

Трудно смотреть в top, когда система висит :)

Вот парочка ситуаций, которые я успел «сфоткать» сразу после отвисания:


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
36 root 20 0 0 0 0 D 2 0.0 0:25.20 kswapd0
280 root 20 0 0 0 0 D 0 0.0 0:00.28 kdmflush
295 root 20 0 0 0 0 D 0 0.0 0:00.24 jbd2/dm-0-8
672 root 20 0 0 0 0 D 0 0.0 0:00.28 jbd2/dm-1-8
750 root 20 0 0 0 0 D 0 0.0 0:00.18 flush-252:1
2744 root 20 0 0 0 0 D 0 0.0 0:00.50 kdmflush
2750 root 20 0 0 0 0 D 0 0.0 0:00.90 kcopyd

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
36 root 20 0 0 0 0 D 0 0.0 0:26.30 kswapd0
698 root 20 0 0 0 0 D 0 0.0 0:00.05 i915
1017 root 20 0 101m 28m 4752 D 0 2.9 8:56.84 Xorg
2775 root 20 0 3396 568 444 D 0 0.1 1:05.95 dd
3303 artem 20 0 134m 15m 11m D 0 1.5 0:00.46 chrome
3319 artem 20 0 7628 3776 1964 D 0 0.4 0:00.12 lsb_release
3335 artem 20 0 56928 1568 388 D 0 0.2 0:00.00 chrome

Вообще говоря, практически все активные процессы почередно падают в спячку. kswapd0 вообще находится почти в перманентном состоянии сна. Наверное, эффект подвисания вызван засыпанием процессов видеодрайвера и Xorg. Но подвисание остальных процессов тоже не радует.

Еще один интересный факт. Никаких тормозов не наблюдалось вообще, пока я не запустил парочку тяжеловесных приложений, увеличив потренеие памяти с 40% до 70%. После этого, даже после закрытия тех приложений (расход памяти упал до 50%), постоянно что-то подвисает.

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

> Может попробовать смонтировать с опцией soft, хотя может будет хуже.

Попробовал. Лучше точно не стало :)

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

Не знаю, странно всё это. Если есть желание разбираться дальше, можно сделать трассировку системных вызовов при копировании с помощью dd и с помощью cp.

То есть запустить:

strace dd if=/dev/sda of=/srv/dataserver/backup/artem-laptop/sda count=1000

и посотреть, может dd между read() и write() вызывает sync()...

kswapd0 вообще находится почти в перманентном состоянии сна.

«D» --- это не состоянии сна, это uninterruptible sleep, фактически значит что процесс в состоянии syscall на операции ввода/вывода. Не знаю, хорошо ли, что kswapd0 находится в этом состоянии, особенно, с учётом того, что есть свободная память. Есть какие ругательства в dmesg?

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

> и посотреть, может dd между read() и write() вызывает sync()..

Нет, не вызывает

«D» --- это не состоянии сна, это uninterruptible sleep, фактически значит что процесс в состоянии syscall на операции ввода/вывода


Ну я это и имел в виду :)

Есть какие ругательства в dmesg?


Вот такое нашел. Не понимаю что это значит. Вроде не относится к делу.

[ 10.360285] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 11
[ 10.360348] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 10.360405] <3>00 ff ff ff ff ff ff 00 06 af 20 10 00 00 00 00 .......... .....
[ 10.360414] <3>01 12 01 03 80 13 0b 78 0a fa 56 92 56 54 98 24 .......x..V.VT.$
[ 10.360423] <3>1a 4f 54 00 00 00 01 01 01 01 01 01 01 01 01 01 .OT.............
[ 10.360431] <3>01 01 01 01 01 01 b0 13 00 40 41 58 19 20 18 88 .........@AX. ..
[ 10.360439] <3>03 01 c3 71 00 00 00 18 00 00 00 0f 00 00 00 00 ...q............
[ 10.360447] <3>00 00 00 00 00 00 00 00 00 20 00 00 00 fe 00 41 ......... .....A
[ 10.360456] <3>55 4f 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe UO. ....
[ 10.360464] <3>00 41 30 38 38 00 00 00 00 00 00 00 00 00 00 00 .A088...........
[ 10.360471]
[ 10.465181] [drm:edid_is_valid] *ERROR* Raw EDID:
[ 10.465253] <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 10.465261] <3>00 00 00 00 00 00 00 00 00 00 ff ff ff ff ff ff ................
[ 10.465269] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 10.465276] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 10.465283] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 10.465291] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 10.465298] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
[ 10.465305] <3>ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................

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

> Попробуй с опцией async, может помочь...

Тоже не помогло ((

raa
() автор топика

Небольшая, но важная поправка.

Я соврал, что обычные файлы копируются нормально. То есть так и есть, но только когда копируешь С шары. А если НА шару, то те же самые тормоза. Неважно, dd или cp.

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

Так что, вероятно, корень проблемы лежит вовсе не в nfs, а в синхронной работе с диском. Как это лечить? Планировщик ведь самый лучший выбран. Да и вообще, планировщик устанавливается на физический девайс, как тогда быть с nfs - непонятно.

raa
() автор топика

> NFS работает через UDP

Как мне объясняли, на udp нет информации о доставке пакета и если пакет не дойдёт то мы об этом просто не узнаем. С этого времени я немного стремаюсь nfs, но в принципе можно сверить md5.

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

Говорят atop значительно лучше обычного top.

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

Очень похоже, что NFS-шара экспортирована с опцией sync (дефолтное поведение).

Попробуй с опцией async, может помочь...

Тоже не помогло ((

А как ты пробовал? Опцию async надо указывать не на клиенте при монтировании, а на сервере, при экспорте.

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

Если при локальном копировании заметные тормоза, (ИМХО, секунда это много) большой load average много процессов в состоянии D, то, nfs, не причём. Надо искать другую причину. Смотрите, работает ли DMA, нормальное ли состояние винта по smart'у, может конфликт из-за видеодрайвера. Наверно, имеет смысл создать новую тему, так как эта была про nfs, и там перечислить всю аппаратную конфигурацию. Ну и про snapshot LVM поподробнее.

mky ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Как отловить «eth0: link up» и «eth0: link down»
Admin
Centos5.4+OpenLdap2.4+Samba3.52 -Проблемы с правами на файлы →