forum.opennet.ru - "dd over nfs. Откуда тормоза?" (9)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

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

Форумы Открытые системы на сервере (Др. сетевые сервисы / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"dd over nfs. Откуда тормоза?"		+/–
Сообщение от raacer (ok) on 02-Июн-10, 21:10
Помогите пожалуйста разобраться с проблемой. При выполнении следующей команды компьютер безбожно тормозит. $ 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 Указание параметра bs не помогает. cat вместо dd дает тот же эффект. В случае копирования в /dev/null тормозов нет. Пара снимков процессов, выпадавших в спячку: 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 Что делать?
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

dd over nfs. Откуда тормоза?, sHaggY_caT, 01:25 , 03-Июн-10, (1)

dd over nfs. Откуда тормоза?, raacer, 01:40 , 03-Июн-10, (2)

dd over nfs. Откуда тормоза?, sHaggY_caT, 01:42 , 03-Июн-10, (3)

dd over nfs. Откуда тормоза?, raacer, 02:01 , 03-Июн-10, (4)

dd over nfs. Откуда тормоза?, sHaggY_caT, 02:05 , 03-Июн-10, (5)

dd over nfs. Откуда тормоза?, raacer, 02:22 , 03-Июн-10, (6)
dd over nfs. Откуда тормоза?, Аноним, 02:29 , 03-Июн-10, (7)

dd over nfs. Откуда тормоза?, raacer, 17:39 , 03-Июн-10, (8)

dd over nfs. Откуда тормоза?, raacer, 19:07 , 03-Июн-10, (9)

Сообщения по теме [Сортировка по времени | RSS]

1. "dd over nfs. Откуда тормоза?" +/–

Сообщение от sHaggY_caT (ok) on 03-Июн-10, 01:25

>[оверквотинг удален]
>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
>
>
>Что делать?
Явно основная проблема (io)wait, а не cpu usage, как можно было бы подумать, и как часто бывает при dd. Все висит колом в D.
Что делать?
Мне кажется, попробовать поиграться с CFQ, если он есть в этом ядре.
Так же, а почему Вы не хотите монтировать lvm-снапшот, и снимать бэкап тем же таром с него?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "dd over nfs. Откуда тормоза?" +/–

Сообщение от raacer (ok) on 03-Июн-10, 01:40

>Так же, а почему Вы не хотите монтировать lvm-снапшот, и снимать бэкап
>тем же таром с него?
Увидел несколько преимуществ у копирования образа:
1. не вызывает проблем с сохранением прав доступа, как при rsync через nfs;
2. позволяет легко примонитровать и использовать образ, в отличие от архива;
3. автоматически отделает данные на диске от устройств, примонтированных данных и прочего;
4. в виду своей целостности и простоты кажется самым надежным;
5. существенно упрощает процесс полного восстановления раздела;
6. делает минимальную нагрузку на систему.
Последнее, конечно, в свете данной темы довольно спорно :-D Но как Вы заметили, проблема ведь не в наргузке на CPU.
Конечно, можно было бы не заморачиваться и использовать то что лучше работает. Но все же хочется разобраться и использовать то что кажется в данной ситуации наиболее удобным и подходящим.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "dd over nfs. Откуда тормоза?" +/–

Сообщение от sHaggY_caT (ok) on 03-Июн-10, 01:42

>[оверквотинг удален]
>4. в виду своей целостности и простоты кажется самым надежным;
>5. существенно упрощает процесс полного восстановления раздела;
>6. делает минимальную нагрузку на систему.
>
>Последнее, конечно, в свете данной темы довольно спорно :-D Но как Вы
>заметили, проблема ведь не в наргузке на CPU.
>
>Конечно, можно было бы не заморачиваться и использовать то что лучше работает.
>Но все же хочется разобраться и использовать то что кажется в
>данной ситуации наиболее удобным и подходящим.
Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть доступно в Вашем роутере)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "dd over nfs. Откуда тормоза?" +/–

Сообщение от raacer (ok) on 03-Июн-10, 02:01

>Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть
>доступно в Вашем роутере)
А это как поможет? Ведь USB порт, через который подключен внешний накопитель, не станет от этого быстрее.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "dd over nfs. Откуда тормоза?" +/–

Сообщение от sHaggY_caT (ok) on 03-Июн-10, 02:05

>>Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть
>>доступно в Вашем роутере)
>
>А это как поможет? Ведь USB порт, через который подключен внешний накопитель,
>не станет от этого быстрее.
так и dd копировать быстрее не сможет, упрется в сеть.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "dd over nfs. Откуда тормоза?" +/–

Сообщение от raacer (ok) on 03-Июн-10, 02:22

>>>Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть
>>>доступно в Вашем роутере)
>>
>>А это как поможет? Ведь USB порт, через который подключен внешний накопитель,
>>не станет от этого быстрее.
>
>так и dd копировать быстрее не сможет, упрется в сеть.
Ну и пусть. Скорость копирования не критична. Главное, чтоб он остальные процессы не вешал.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "dd over nfs. Откуда тормоза?" +/–

Сообщение от Аноним (??) on 03-Июн-10, 02:29

>>>Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть
>>>доступно в Вашем роутере)
>>
>>А это как поможет? Ведь USB порт, через который подключен внешний накопитель,
>>не станет от этого быстрее.
>
>так и dd копировать быстрее не сможет, упрется в сеть.
на сколько я понимаю, там скорость и так не больше 1-2МБ/c, попробовать опустить ее еще конечно можно, но смысл? ради эксперимента разве.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

8. "dd over nfs. Откуда тормоза?" +/–

Сообщение от raacer (ok) on 03-Июн-10, 17:39

>Мне кажется, попробовать поиграться с CFQ, если он есть в этом ядре.
Вроде все как надо:
artem@artem-laptop:/$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
artem@artem-laptop:/$ cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "dd over nfs. Откуда тормоза?" +/–

Сообщение от raacer (ok) on 03-Июн-10, 19:07

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "dd over nfs. Откуда тормоза?"		+/–
Сообщение от sHaggY_caT (ok) on 03-Июн-10, 01:25
>[оверквотинг удален] >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 > > >Что делать? Явно основная проблема (io)wait, а не cpu usage, как можно было бы подумать, и как часто бывает при dd. Все висит колом в D. Что делать? Мне кажется, попробовать поиграться с CFQ, если он есть в этом ядре. Так же, а почему Вы не хотите монтировать lvm-снапшот, и снимать бэкап тем же таром с него?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	2. "dd over nfs. Откуда тормоза?"		+/–
	Сообщение от raacer (ok) on 03-Июн-10, 01:40
	>Так же, а почему Вы не хотите монтировать lvm-снапшот, и снимать бэкап >тем же таром с него? Увидел несколько преимуществ у копирования образа: 1. не вызывает проблем с сохранением прав доступа, как при rsync через nfs; 2. позволяет легко примонитровать и использовать образ, в отличие от архива; 3. автоматически отделает данные на диске от устройств, примонтированных данных и прочего; 4. в виду своей целостности и простоты кажется самым надежным; 5. существенно упрощает процесс полного восстановления раздела; 6. делает минимальную нагрузку на систему. Последнее, конечно, в свете данной темы довольно спорно :-D Но как Вы заметили, проблема ведь не в наргузке на CPU. Конечно, можно было бы не заморачиваться и использовать то что лучше работает. Но все же хочется разобраться и использовать то что кажется в данной ситуации наиболее удобным и подходящим.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	3. "dd over nfs. Откуда тормоза?"		+/–
	Сообщение от sHaggY_caT (ok) on 03-Июн-10, 01:42
	>[оверквотинг удален] >4. в виду своей целостности и простоты кажется самым надежным; >5. существенно упрощает процесс полного восстановления раздела; >6. делает минимальную нагрузку на систему. > >Последнее, конечно, в свете данной темы довольно спорно :-D Но как Вы >заметили, проблема ведь не в наргузке на CPU. > >Конечно, можно было бы не заморачиваться и использовать то что лучше работает. >Но все же хочется разобраться и использовать то что кажется в >данной ситуации наиболее удобным и подходящим. Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть доступно в Вашем роутере)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	4. "dd over nfs. Откуда тормоза?"		+/–
	Сообщение от raacer (ok) on 03-Июн-10, 02:01
	>Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть >доступно в Вашем роутере) А это как поможет? Ведь USB порт, через который подключен внешний накопитель, не станет от этого быстрее.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	5. "dd over nfs. Откуда тормоза?"		+/–
	Сообщение от sHaggY_caT (ok) on 03-Июн-10, 02:05
	>>Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть >>доступно в Вашем роутере) > >А это как поможет? Ведь USB порт, через который подключен внешний накопитель, >не станет от этого быстрее. так и dd копировать быстрее не сможет, упрется в сеть.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	6. "dd over nfs. Откуда тормоза?"		+/–
	Сообщение от raacer (ok) on 03-Июн-10, 02:22
	>>>Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть >>>доступно в Вашем роутере) >> >>А это как поможет? Ведь USB порт, через который подключен внешний накопитель, >>не станет от этого быстрее. > >так и dd копировать быстрее не сможет, упрется в сеть. Ну и пусть. Скорость копирования не критична. Главное, чтоб он остальные процессы не вешал.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	7. "dd over nfs. Откуда тормоза?"		+/–
	Сообщение от Аноним (??) on 03-Июн-10, 02:29
	>>>Еще, кроме CFQ, можно предложить агрессивный шейпинг nfs трафика (это должно быть >>>доступно в Вашем роутере) >> >>А это как поможет? Ведь USB порт, через который подключен внешний накопитель, >>не станет от этого быстрее. > >так и dd копировать быстрее не сможет, упрется в сеть. на сколько я понимаю, там скорость и так не больше 1-2МБ/c, попробовать опустить ее еще конечно можно, но смысл? ради эксперимента разве.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	8. "dd over nfs. Откуда тормоза?"		+/–
	Сообщение от raacer (ok) on 03-Июн-10, 17:39
	>Мне кажется, попробовать поиграться с CFQ, если он есть в этом ядре. Вроде все как надо: artem@artem-laptop:/$ cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq] artem@artem-laptop:/$ cat /sys/block/sdb/queue/scheduler noop anticipatory deadline [cfq]
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

9. "dd over nfs. Откуда тормоза?"		+/–
Сообщение от raacer (ok) on 03-Июн-10, 19:07
Небольшая, но важная поправка. Я соврал, что обычные файлы копируются нормально. То есть так и есть, но только когда копируешь С шары. А если НА шару, то те же самые тормоза. Неважно, dd или cp. Более того, я понял, что те же самые тормоза и подвисания есть при локальном копировании файла на тот же раздел. Просто они очень короткие, обычно до секунды, редко больше. Так что, вероятно, корень проблемы лежит вовсе не в nfs, а в синхронной работе с диском. Как это лечить? Планировщик ведь самый лучший выбран. Да и вообще, планировщик устанавливается на физический девайс, как тогда быть с nfs - непонятно.
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору