Hi David,
I tested openvpn 2.2.2, this is the result:
200 client connections, the renegotiation time is 600 seconds.
2013/9/28 10:07 139216 KB
2013/9/28 10:17 265252
2013/9/28 10:27 267100
2013/9/28 10:37 268948
2013/9/28 10:47 269740
2013/9/28 10:57 270532
2013/9/28 11:07 270532
2013/9/28 11:17 270532
2013/9/28 11:27 270532
2013/9/28 11:37 270796
2013/9/28 11:47 270796
2013/9/28 11:57 270796
2013/9/28 12:07 270796
2013/9/28 12:17 270796
2013/9/28 12:27 271060
2013/9/28 12:37 271060
2013/9/28 12:47 271060
..........
2013/9/28 23:58 271060
2013/9/29 0:18 271060
The openvpn 2.2.2 does not have memory leak. It does not like openvpn 2.3.2
which memory is increased again and again.
This may be openvpn 2.3.2 special issue.
Thanks,
Brad
On Sat, Sep 28, 2013 at 10:48 PM, Brad Zhang <hebei5...@gmail.com> wrote:
> Thanks David. I understand your said. I will try the openvpn 2.2.2 with
> the same configuration. I will post the result later.
>
> Brad Zhang
>
>
> On Fri, Sep 27, 2013 at 7:43 PM, David Sommerseth <
> openvpn.l...@topphemmelig.net> wrote:
>
>> On 27/09/13 11:45, Brad Zhang wrote:
>> > Thanks David for your so quickly replying.
>> >
>> > 6.
>> > I want to use polarssl, so I upgrade the openvpn from 2.1 rc4 to 2.3.2.
>> > Openvpn 2.2.2 does not support polarssl.
>> > But openvpn 2.3.2 with polarssl also has memory leak.
>> > openvpn2.3.2 + polarssl + 200 connections.
>> > initiate 31M
>> > renegotiate 1 44M
>> > renegotiate 2 44M
>> > renegotiate 3 44M
>> > renegotiate 4 45M
>>
>> Okay, but 2.1_rc4 is really too old to compare against. It's from April
>> 2007! And OpenVPN 2.1.4 (released Nov 2010) is not the same as 2.1_rc4.
>>
>> And no releases before 2.3 supports PolarSSL. So if you're able to test
>> 2.1_rc4, please compile OpenVPN 2.2.2 (released Dec 2011). OpenVPN is a
>> fairly trivial package to compile and test. It only provides a single
>> binary which you need to copy out and run. There's no additional files
>> or libraries required to run.
>>
>> The reason I ask for 2.2.2 testing is that the gap between 2.2.x and
>> 2.3.x is quite big - especially on the SSL layer side. In addition, the
>> networking code has been modified a lot too, to implement IPv6 support
>> in 2.3. And I don't want to start looking at those changes before I
>> know 2.2.2 is not leaking. Because if 2.2.2 is leaking, then we need to
>> look at completely different code changes.
>>
>>
>> > 7.
>> > I do not use plugin or script in openvpn 2.3.2.
>> > This is server config:
>> > dev tun0
>> > dev-type tun
>> > mode server
>> > tls-server
>> > tun-mtu 1500
>> > proto tcp-server
>> > local 0.0.0.0
>> > port 443
>> > persist-key
>> > persist-tun
>> > verb 3
>> > mute 20
>> > keepalive 10 60
>> > cipher DES-EDE3-CBC
>> > auth SHA1
>> > ca ca.crt
>> > cert server.crt
>> > key server.pem
>> > max-clients 2000
>> > dh dh.dh
>> > duplicate-cn
>> > topology subnet
>> > server 192.168.111.0 255.255.255.0
>> > push "route 11.11.1.0 255.255.255.0"
>> > reneg-sec 600
>> > management 127.0.0.1 7505
>> > status /tmp/status 30
>> > status-version 2
>> > client-config-dir /tmp/ccd/
>>
>> All this looks pretty fine. It's basically a pretty standard server
>> config. I suspect this leak is happening somewhere around the SSL
>> session handling, or the code paths along "multi learn address". But I
>> can't say for sure yet.
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>>
>>
>>
>> > On Fri, Sep 27, 2013 at 4:34 PM, David Sommerseth
>> > <openvpn.l...@topphemmelig.net <mailto:openvpn.l...@topphemmelig.net>>
>> > wrote:
>> >
>> > ----- Original Message -----
>> > > From: "Brad Zhang" <hebei5...@gmail.com <mailto:
>> hebei5...@gmail.com>>
>> > > To: openvpn-users@lists.sourceforge.net
>> > <mailto:openvpn-users@lists.sourceforge.net>
>> > > Sent: Friday, 27 September, 2013 8:11:56 AM
>> > > Subject: [Openvpn-users] Does openvpn 2.3.2 has memory leak?
>> > >
>> > > Hi all,
>> > >
>> > > I tested openvpn 2.3.2 (openssl) with 200 connections. Set the
>> > renegotiation
>> > > value to 600 seconds.
>> > >
>> > > initiate: 136M
>> > > renegotiate 1 259M
>> >
>> > This gap from initial to the first renegotiation isn't unexpected.
>> > It's not
>> > necessarily a leak itself, but most likely memory allocated for each
>> > client.
>> > We've estimated earlier that it's roughly 1MB per client. Your
>> > growth here
>> > is around 600KB per client, so I'd say that's within the expected
>> > limits.
>> >
>> > > renegotiate 2 262M
>> > > renegotiate 3 264M
>> > > renegotiate 4 266M
>> > > renegotiate 5 267M
>> >
>> > Here you have incremental steps of 2MB per renegotiation, which
>> > means with
>> > 200 clients roughly 10KB per client. This does however sound like a
>> > smaller
>> > memory leak.
>> >
>> > For wow long time did you run this test? Did you let the clients
>> > disconnect at then end to see if the memory impact was reduced after
>> > OpenVPN
>> > releases the sessions? (OpenVPN may keep session data for some time
>> > after a
>> > disconnect in case it was connection drop-out, esp. with UDP. Look
>> at
>> > --explicit-exit-notify in the man page for some more information)
>> >
>> > Also, how did you measure OpenVPN's memory usage?
>> >
>> > > I have tried the openvpn 2.1 rc4, there is no this issue. I do not
>> > know why
>> > > the memory usage will increase after one time renegotiation. Could
>> > someone
>> > > help me?
>> >
>> > To compare against 2.1_rc4 is a bit too big gap. I'd appreciate if
>> you
>> > could run your test against 2.2.2. And if that's still leaking, you
>> > would
>> > need to check against 2.1.4 (the last 2.1 community version)
>> >
>> > Could we also see your server config? Just to see if you use some
>> > kind of
>> > plugins, script hooks or other possible candidates for triggering
>> > this issue.
>> >
>> > I'm running OpenVPN 2.3 servers a couple of places, but not with 200
>> > clients.
>> > But I've not noticed any particular issues there. However, if the
>> > leak is
>> > ~10KB per client, it would most likely have had scheduled
>> maintenance
>> > reboots happening before noticing a leak.
>> >
>> >
>> > --
>> > kind regards,
>> >
>> > David Sommerseth
>> >
>> >
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>>
>>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
