[httperf] fd-unavail non-null
david at lang.hm
david at lang.hm
Sat Sep 4 04:08:02 PDT 2010
On Fri, 3 Sep 2010, Sylvain Geneves wrote:
> On 09/02/2010 08:36 PM, Rick Jones wrote:
>>> *) I'll try that but i'm not sure how the OS will behave when
>>> assigning multiple IPs to a single NIC
>> It should behave just fine. Support for multiple IPs per NIC has been in
>> almost every TCP/IP stack out there for years.
>>> *) I fear that assigning more than one IP to a single NIC on the
>>> server will stress the network load-balancing algorithm of the OS too
>> How so?
> In my previous experience, when using the Linux NIC bonding system to assign
> more than one IP per NIC, we weren't able to achieve full network
> That's why I think that even if doing this on the clients is fine, it could
> add a significan overload on the server, because it has much more networking
> to deal with.
> But that's just thoughts and I haven't tested that configuration in this
> precise case.
you don't need to use NIC bonding, all you need to do is to allocate
additional IPs to the existing interface.
with ifconfig you can assign the IP addresses to things like eth0:0
with the new ip command you can directly assign multiple IP addresses to a
if you have the server software bind to 0.0.0.0 (the default for most
servers) you don't have to do anything with the server software to make
>>> actually I tuned TCP parameters for my tests, and after chechking that
>>> it turns out that TIME_WAIT is dramatically reduced to 1sec in my
>>> configuration, so I'm surprised this problem arises this fast (seems
>>> to be any rate above 1000sess/sec).
> come to think of it, it's not surprising at all : since of my client machines
> have eight cores, I naively launched 8 httperf instances on each one.
> Since I was having fd-unavail errors (EMFILE), which means per-process errors
> instead of ftab-full (ENFILE), which are system-wide, I didn't realise it
> could be the cause of my problems in the first place.
> using more machines with 4 httperf instances allows me to bench higher rates.
> anyway thanks for your help!
>> rick jones
>> httperf mailing list
>> httperf at linux.hpl.hp.com
> httperf mailing list
> httperf at linux.hpl.hp.com
More information about the httperf