Yes those files were TCP sockets, and I was using "--proto tcp" option. I
did not observe this issue for UDP, because it is connectionless protocol.
But the bad thing is that OpenVPN did not recover even after I killed all
those 1200 clients and OpenVPN server continued to consume CPU at 100%
Hi Ansis,
On Thursday 26 August 2010 19:56:56 Ansis Atteka wrote:
> 4. During a OpenVPN 1200 client bomb test I observed that OpenVPN stalled
> with 100% CPU. In the openvpn log I saw that there are too many opened
> files (output of "ls /proc/PID/fd | wc -l" showed that there were 1027
> opened
Hi Ansis,
Ansis Atteka wrote:
Hi Jan,
2. The reason for tun0 TX packets being dropped seems more like a Tun
queue thing. I would guess that OpenVPN does not poll frequently
enough for incoming packets from TUN device. I am wondering if anyone
else was able to connect with >1000 clients to a
Hi Ansis,
very interesting results, it's been on my TODO list to do some extensive
benchmarking for some time, especially in a 1 Gbps and 10 Gbps network
environment. See some comments below
Ansis Atteka wrote:
Hello
I have done some benchmarking of OpenVPN and wanted to share my
numbers
Hello
I have done some benchmarking of OpenVPN and wanted to share my numbers and
also ask some questions. Here is a table that shows how OpenVPN scales. I
ran up to 4 instances of OpenVPN servers simulatenously with different
ciphers:
ICMP test (MiByes/s)
*Cipher\OpenVPNs instances*
*1*
*2*
