Setup some queues and prioritise your ACK's ;)
The box is fine under the load I'm sure, but you'll still need to
prioritise those TCP acknowledgments to make things snappy when lots of
traffic is going on..
On 02/10/14 17:13, Ville Valkonen wrote:
Hello Patrick,
On 2 October 2014 17:32, Patrick <[email protected]> wrote:
Hi,
I use a OpenBSD based firewall (version 5.2, I know I should upgrade but ...)
between a 8 host cluster of Linux server and 300 clients which will access this
clutser via VNC. Each server is connected with one gigabit port to a dedicated
switch and the firewall has on each site one gigabit (dedicated switch and
campus network).
The users complains about slow VNC response times (if I connect a client system
to the dedicated switch, the access is faster, even during peak hours), and the
admins of the cluster blame my firewall :(.
I use MRTG for traffic monitoring (data retrieves from OpenBSD in one minute
interval) and can see average traffic of 160 Mbit/s during office hours and
peaks and 280 Mbit/s. With bwm-ng and a five second interval I can see peaks
and 580 Mbit/s. The peak packets per second is arround 80000 packets (also
measured with bwm-ng). The interrupt of CPU0 is in peak 25%. So with this data
I don't think the firewall is at the limit, I'm right?
The server is a standard Intel Xeon (E3-1220V2, 4 Cores, 3.10 GHz) with 4 GByte
of memory and 4 1 Gbit/s ethernet cooper Intel nics (driver em).
Where is the problem? Can't the nics handle more packets/second? How can I
check for this?
If I connect a client system directly to the dedicated system, the response
times are better.
Thanks for your help,
Patrick
In addition to dmesg, could you please provide the following information:
$ pfctl -si
$ sysctl kern.netlivelocks
and interrupt statistics (by systat for example) would be helpful.
Thanks!
--
Regards,
Ville
