FreeBSD: Як виправити "ping: sendto: немає буферного простору"?


27

Я намагаюся пінг-код віддаленого хоста, але я отримую помилку.

# ping 192.168.80.1
PING 192.168.80.1 (192.168.80.1): 56 data bytes
ping: sendto: No buffer space available
ping: sendto: No buffer space available
^C
--- 192.168.80.1 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

Він працює для інших хостів:

# ping 192.168.16.1
PING 192.168.16.1 (192.168.16.1): 56 data bytes
64 bytes from 192.168.16.1: icmp_seq=0 ttl=254 time=0.442 ms
64 bytes from 192.168.16.1: icmp_seq=1 ttl=254 time=0.402 ms
^C
--- 192.168.16.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.402/0.422/0.442/0.020 ms
#

Повідомлення "Немає місця в буфері", схоже, вказує на певну помилку пам'яті. І дійсно, коли я перевіряю в Netstat, номер "кластери mbuf" виглядає ДУЖЕ неправильно:

# netstat -m
11780 mbufs in use
4294966716/32768 mbuf clusters in use (current/max)
0/3/6656 sfbufs in use (current/peak/max)
1785 KBytes allocated to network
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

Що тут відбувається? Чи є можливість виправити це без простоїв, чи мені потрібно перезавантажити хост або перезапустити мережевий інтерфейс?


1
Чи можете ви розмістити вихід dmesg?
Майк Н

Я приклеював своє. У моєму випадку це резервна копія, яка десь забила чергу, мені незрозуміло, чому - але призупинення та відновлення резервного копіювання (rsync --bwlimit = 40) вирішили проблему для нас. Я також спробував подвоїтись net.inet.tcp.sendbuf_maxі net.inet.tcp.recvbuf_maxнічого не змінив.
anarcat

Відповіді:


11

Оскільки проблема здається ізольованою лише до одного інтерфейсу - я припускаю, що ви використовуєте звичайні старі маски класу C для цих двох мереж - я просто швидко відмовлюся від неї:

# ifconfig en0 down
# ifconfig en0 up

Очевидно, що тут потрібно замінити правильне ім'я інтерфейсу en0.

Можливо, вам доведеться перезапустити будь-які сервери, які прослуховують цей інтерфейс, і будь-яке встановлене TCP-з'єднання, використовуючи його, випаде, коли ви це зробите. Однак це коротко, тому я насправді не вважаю такий тест "простоєм".

Будьте впевнені, що цього не робите, ввівши ssh'd у вікно інтерфейсу, який ви підстрибуєте. Найкраще ввійти на консоль, коли ви це зробите, якщо зможете. Якщо сервер віддалений, найкраще підключити модем, оскільки підстрибування мережевих інтерфейсів не впливатиме на послідовне отримання gettys. Якщо ви повинні зробити це під час входу в мережу, переконайтеся, що ваше з'єднання надходить через інший інтерфейс.


4
Ну, виявляється, цей інтерфейс мав нещільний кабель Ethernet. Я підтягнув кабель, і помилка "Немає місця в буфері" відпала. Тепер мені потрібно розібратися, чи потрібно мені турбуватися про номер 'mbuf', чи зрозуміє це самостійно?
Стефан Ласєвський

На жаль, підстрибуючи інтерфейс не виправив його (на цій машині є кілька інтерфейсів, я спробував кожен з них послідовно, а потім все відразу, сподіваючись, що щось звільнить простір). Я перезавантажив коробку, і, сподіваємось, ця проблема не повториться після того, як ми полагодимо кабель.
Стефан Ласєвський

1
Оновлення через 4 роки. Так, мені потрібно турбуватися про помилку mbuf. Ця проблема періодично з’являється на моїх скриньках FreeBSD і майже завжди пов’язана з великим навантаженням на мережу, а можливо, і з помилковим кабелем.
Стефан Ласєвський

Підстрибуючи виправив це для мене.
гравітація

Я прийшов сюди спеціально для OpenBSD 5.8 AMD64, що працює на Cloudstack під управлінням CentOS6.5 AMD64. Кожен раз, коли фізичне поле переривається, цей vm не може вийти. Я намагався підстрибнути інтерфейс, і це не вийшло. Я просто подумав, що поділюсь тут, якщо хтось піде схожим шляхом. ОНОВЛЕННЯ - менше ніж через хвилину він працює, тому, можливо, це все виправить.
danno
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.