форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

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

"Низкая производительность диска на чтение"	+/–
Сообщение от Anonymus on 28-Окт-14, 18:15
Есть два сервера А и Б, на сервере Б запустил mv -v каталога с А на локальный диск сервера Б через NFS. Вывод команды mv периодически подвисает на несколько секунд. Стал смотреть в чём затык. sar -d 1 на сервере Б никакой дисковой активности на запись в момент подвисаний не показывает, iptraf соответственно показывает никакой трафик, но, внимание, если запускаю sar -d 1 на сервере А, то процесс перемещения прёт с нормальной скоростью, без затыков. Прибиваю sar на сервере А - передача затыкается. Запускаю - прёт снова. Чего я недогоняю?
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Низкая производительность диска на чтение"	+/–
Сообщение от me (??) on 28-Окт-14, 21:33
> но, внимание, если запускаю sar -d 1 на сервере А, то > процесс перемещения прёт с нормальной скоростью, без затыков. Прибиваю sar на > сервере А - передача затыкается. Запускаю - прёт снова. Чего я > недогоняю? забавно, а ты уверен, что так только sar влияет, а не, скажем, любая комманда с периодическим выхлопом в сеть? через ssh, ведь, запускаешь, не через console?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Низкая производительность диска на чтение"	+/–
	Сообщение от Anonymus on 29-Окт-14, 06:58
	Возможно, но периодически я переключался в screen-е, так что выхлопа в сеть иногда и не было. Вобщем, то был бэкап перед заменой диска, сейчас воткну новый и буду посмотреть.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Низкая производительность диска на чтение"	+/–
	Сообщение от Anonymus on 29-Окт-14, 10:49
	Ты прав. Влияет именно вывод в консоль через ssh. Пробовал в обратную сторону, в Б на А, команда копирования выполняется на стороне А. Никаких проблем нет, причём прёт в три раза быстрее. Пробовал iperf, он показывает одинаковую пропускную способность в обе стороны. Load average в htop ниже нуля во всех случаях. Параметры монтирования NFS одинаковые. Диск уже стоит другой, от него ничего не зависит. Прошлые мои проблемы с NFS были связаны с долгим коннектом из-за rpcsec_gss_krb5. Куда копать - не пойму. Туплю до сих пор, а делать чё-та надо.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Низкая производительность диска на чтение"	+/–
	Сообщение от me (??) on 30-Окт-14, 14:05
	> Ты прав. Влияет именно вывод в консоль через ssh. > Пробовал в обратную сторону, в Б на А, команда копирования выполняется на > стороне А. Никаких проблем нет, причём прёт в три раза быстрее. > Куда копать - не пойму. Туплю до сих пор, а делать чё-та > надо. это сетевые стэйты очевидно, хз - где, искать надо. На вскидку приходят в глову сразу arp, фильтр, fdb (эта может протухнуть и хостах и на свитче). поробуй tcpdump на A и Б на тех интерфейсах что движут трафф (только на А это надо в файл писать, и может, в скрине и скрин - закрыть, что-б он траф не слал, что-б не смешивать его с эффектом, который ты и без того ловишь). Посмотреть, кто первым заткнется. Машины, кстати, в одном сегменте стоят или через роутер? Если в одном, я-б сразу arp таблицу посмотрел в момент, когда они заткнуться и сравнил с маками на интерфейсах. Не теряет-ли Б, часом мак А. Тогда твоё соединение пишущее может как обновлятор работь для него все время.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "Низкая производительность диска на чтение"	+/–
	Сообщение от Anonymus on 01-Ноя-14, 08:49
	> поробуй tcpdump на A и Б на тех интерфейсах что движут трафф > (только на А это надо в файл писать, и может, в > скрине и скрин - закрыть, что-б он траф не слал, что-б > не смешивать его с эффектом, который ты и без того ловишь). чёт-туплю чего в tcpdump-е смотреть-то? > Посмотреть, кто первым заткнется. Машины, кстати, в одном сегменте стоят или через > роутер? Если в одном, я-б сразу arp таблицу посмотрел в момент, > когда они заткнуться и сравнил с маками на интерфейсах. Не теряет-ли > Б, часом мак А. Тогда твоё соединение пишущее может как обновлятор > работь для него все время. Один сегмент, с маками и arp всё в порядке - проверил. Тот диск, что я снял с А был с системой. Я воткнул его в другой комп, поправил ip, hostname, воткнул вместо А тем же самым патчкордом. Никаких проблем с копированием не заметил. Может чего с железом не так, и с чего вдруг не так? В dmesg ничего подозрительного не видать.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	9. "Низкая производительность диска на чтение"	+/–
	Сообщение от me (??) on 01-Ноя-14, 21:48
	>> поробуй tcpdump на A и Б на тех интерфейсах что движут трафф >> (только на А это надо в файл писать, и может, в >> скрине и скрин - закрыть, что-б он траф не слал, что-б >> не смешивать его с эффектом, который ты и без того ловишь). > чёт-туплю чего в tcpdump-е смотреть-то? >> Посмотреть, кто первым заткнется. кто первым  заткнется. кто-то, скорее всего Б, в какой-то момент перестал слышать А. не похоже, что-б это была проблема Б. так что либо А либо свитч. Посмотреть, все-ли видит Б, что А отправляет.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	8. "Низкая производительность диска на чтение"	+/–
	Сообщение от Anonymus on 01-Ноя-14, 12:03
	Вообще такое подозрение, что где-то время от времени теряются пакетики. Потерялся-таймаут, потерялся - снова таймаут. Очень похожее поведение.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	10. "Низкая производительность диска на чтение"	+/–
	Сообщение от me (??) on 01-Ноя-14, 21:51
	> Вообще такое подозрение, что где-то время от времени теряются пакетики. Потерялся-таймаут, > потерялся - снова таймаут. Очень похожее поведение. так и есть, скорее всего.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

2. "Низкая производительность диска на чтение"	+/–
Сообщение от _KUL (ok) on 29-Окт-14, 04:50
> Есть два сервера А и Б, на сервере Б запустил mv -v > каталога с А на локальный диск сервера Б через NFS. Вывод > команды mv периодически подвисает на несколько секунд. Стал смотреть в чём > затык. sar -d 1 на сервере Б никакой дисковой активности на > запись в момент подвисаний не показывает, iptraf соответственно показывает никакой трафик, > но, внимание, если запускаю sar -d 1 на сервере А, то > процесс перемещения прёт с нормальной скоростью, без затыков. Прибиваю sar на > сервере А - передача затыкается. Запускаю - прёт снова. Чего я > недогоняю? А что lsof | grep sar говорит? А iotop? Что показывает htop в строке Load average не больше ли кол-во блокирующих процессов (которые ожидают ресурсов для продолжения работы) чем кол-во ядер в системе? По мидитируйте над выводом ps auxf
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Низкая производительность диска на чтение"	+/–
	Сообщение от Anonymus on 29-Окт-14, 07:03
	> А что lsof | grep sar говорит? А iotop? Что показывает htop > в строке Load average не больше ли кол-во блокирующих процессов (которые > ожидают ресурсов для продолжения работы) чем кол-во ядер в системе? По > мидитируйте над выводом ps auxf Да какой там load average, простой файлопомоечный сервер, я-единственный юзер на тот момент. О, тока что вспомнил, года полтора назад лечил тормоза в NFS. Щас поищу что тогда делал.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

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

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