Re: arp -na performance w/ many permanent entries

2010-06-09 Thread Nick Rogers
On Sun, Jun 6, 2010 at 4:23 PM, Nick Rogers ncrog...@gmail.com wrote: On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper yanef...@gmail.comwrote: I agree with Jeremy. I think that the problem that you've discovered is the fact that it's using stdio-based buffered output instead of

Re: arp -na performance w/ many permanent entries

2010-06-06 Thread Nick Rogers
On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper yanef...@gmail.com wrote: I agree with Jeremy. I think that the problem that you've discovered is the fact that it's using stdio-based buffered output instead of buffering more of the contents in a string and punting it out in larger

Re: arp -na performance w/ many permanent entries

2010-06-05 Thread Nick Rogers
On Mon, May 31, 2010 at 10:54 PM, Nick Rogers ncrog...@gmail.com wrote: [root@ ~]# time arp -na /dev/null real 0m12.761s user 0m2.959s sys 0m9.753s [root@ ~]# Notice that arp -na takes about 13s to execute even though there is no other load. This can get a lot worse by a few orders of

Re: arp -na performance w/ many permanent entries

2010-06-05 Thread Jeremy Chadwick
On Sat, Jun 05, 2010 at 09:48:01PM -0400, Nick Rogers wrote: On Mon, May 31, 2010 at 10:54 PM, Nick Rogers ncrog...@gmail.com wrote: [root@ ~]# time arp -na /dev/null real 0m12.761s user 0m2.959s sys 0m9.753s [root@ ~]# Notice that arp -na takes about 13s to execute even

Re: arp -na performance w/ many permanent entries

2010-06-05 Thread Garrett Cooper
On Sat, Jun 5, 2010 at 8:16 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Sat, Jun 05, 2010 at 09:48:01PM -0400, Nick Rogers wrote: On Mon, May 31, 2010 at 10:54 PM, Nick Rogers ncrog...@gmail.com wrote: [root@ ~]# time arp -na /dev/null real 0m12.761s user 0m2.959s sys

arp -na performance w/ many permanent entries

2010-05-31 Thread Nick Rogers
I have an 8.0-RELEASE system with 4000 permanent ARP entries due to having a network interface (em(4)) configured with 4000 aliases. The arp -na command takes what I consider to be an extremely long time to finish (up to 30s on an otherwise unloaded system). I am able to replicate this in a test