Port-xen archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
xennet0: rx no buf under NetBSD 6.1.5 domU
Good afternoon folks,
I've setup a domU to process NetFlow data using wip/pmacct, and have
begun running into periods where the domU kernel starts complaining with
a dmesg stream of:
xennet0: rx no buf
xennet0: rx no buf
xennet0: rx no buf
xennet0: rx no buf
xennet0: rx no buf
I've had a Google around, and found thread [1] which describes the
behavior, but no indication of resolution. Based on the troubleshooting
suggestions there, I'll include the following:
pmacct01$ sudo netstat -m
57 mbufs in use:
27 mbufs allocated to data
3 mbufs allocated to packet headers
27 mbufs allocated to socket names and addresses
438 calls to protocol drain routines
pmacct01$ sudo vmstat -m | grep -e mbpl -e mclpl -e Name
vmstat: Kmem statistics are not being gathered by the kernel.
Name Size Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg
Maxpg Idle
mbpl 512 53230 0 52826 646 593 53 62 2
inf 2
mclpl 2048 437 0 436 219 214 5 11 4
131072 4
pmacct01$ netstat -a | grep -e Proto -e tcp -e udp
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 18 0 pmacct01.postgresql kibana01.65285
ESTABLISHED
tcp 0 0 pmacct01.postgresql kibana01.65383
ESTABLISHED
tcp 0 0 *.postgresql *.* LISTEN
tcp 0 0 pmacct01.ssh 10.11.83.66.51046
ESTABLISHED
tcp 0 0 *.ssh *.* LISTEN
udp 0 0 localhost.ntp *.*
udp 0 0 pmacct01.ntp *.*
udp 0 0 *.ntp *.*
udp 2037 0 *.iop *.*
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp6 0 0 *.postgresql *.* LISTEN
tcp6 0 0 *.ssh *.* LISTEN
udp6 0 0 fe80::1%lo0.ntp *.*
udp6 0 0 localhost.ntp *.*
udp6 0 0 fe80::216:3eff:f.ntp *.*
udp6 0 0 localhost.65534 localhost.65534
udp6 0 0 *.ntp *.*
Given Manuel's suggestion in the referenced thread, I'm wondering if the
*.iop queue is what leading to the condition; which is the NetFlow
listener. Running netstat a handful of times rapidly shows the queue
value jumping anywhere from 0 up to 10k entries.
Is the suggestion that the process we have listening there isn't
collecting the waiting connections rapidly enough? I'd like the
ascertain if it's something which is more "correct" or feasible to
address by allocating additional buffer somewhere OS side, or if I need
to look at the software side and see if it's not allocating something
adequately for NetBSD specifically. (Which is entirely possible... the
import of wip/pmacct is my doing.)
Suggestions welcomed.
Best,
Mike.
[1] http://mail-index.netbsd.org/netbsd-users/2012/11/19/msg012003.html
Home |
Main Index |
Thread Index |
Old Index