[strongSwan] Performance issue with 25k IPsec tunnels (using 5.0.4 strongswan and load-tester plugin)

[Chinmaya Dwibedy]

Hi Martin
I think, my email missed your kind attention. I
am stuck to move forward. Can you please guide me to proceed further? Thanks a
lot in advance for your suggestion.
Regards,
Chinmaya
 
On Friday, October 4, 2013 12:26 PM, Chinmaya Dwibedy <ckdwibedy at yahoo.com> wrote:
  
Hi Martin,
I did profiling
the Charon implementation (using perf profiler tool) to find the main
bottleneck with 25k IPsec connections (without data traffic). The perf tool
generates an output file called perf.data. That file can then be analyzed using
the perf report. I found from call stack in the perf profiler ,: gmpn_addmul_1
function in  libgmp.so.3.4.1 consumes
most of the CPU cycles on both the Linux systems ( IKE Initiator as well as  IKE Responder) . It was clearly the hottest
procedure in the Chardon keying daemon (IKEv2). What I understand, the
strongswan uses the gmp library for the implementation of DH and we are using
the DH group as modp1024 at both ends.
Here goes the
results of #perf report
3.72%           charon  libgmp.so.3.4.1                                                                      [.] __gmpn_addmul_1
     0.86%           charon  libcharon.so.0.0.0                                                                   [.] checkout_by_message
     0.38%           charon  libc-2.11.1.so                                                                       [.] memcmp
     0.19%           charon  libgmp.so.3.4.1                                                                      [.] __gmpn_add_n
     0.15%           charon  libgmp.so.3.4.1                                                                      [.] __gmpn_mul_1
     0.10%           charon  libgmp.so.3.4.1                                                                      [.] 0x00000000022ed8
     0.09%           charon  libgmp.so.3.4.1                                                                      [.] __gmpn_sqr_basecase
     0.09%           charon  libgmp.so.3.4.1                                                                      [.]
__gmpn_sqr_diagonal
     0.07%           charon  libgmp.so.3.4.1                                                                      [.] __gmpn_lshift
     0.04%           charon  libgmp.so.3.4.1                                                                      [.]
__gmpn_sub_n
     0.04%           charon  libc-2.11.1.so                                                                       [.] 0x00000000096284
     0.04%           charon  libpthread-2.11.1.so                                                                 [.]
pthread_rwlock_rdlock
     0.04%           charon  libpthread-2.11.1.so                                                                 [.] __pthread_rwlock_unlock
     0.02%           charon  libc-2.11.1.so                                                                       [.] __libc_malloc
     0.02%           charon  libgmp.so.3.4.1                                                                      [.] __gmpn_mul_basecase
     0.02%           charon  libgmp.so.3.4.1                                                                      [.] __gmpz_powm
     0.02%           charon  libstrongswan-sha1.so                                                                [.] SHA1Transform
     0.02%           charon  libc-2.11.1.so                                                                       [.] cfree
     0.02%           charon  [kernel.kallsyms]                                                                    [k] sha_transform
     0.02%           charon  libc-2.11.1.so                                                                       [.] vfprintf
     0.02%           charon  libgmp.so.3.4.1                                                                      [.] __gmpn_kara_mul_n
     0.01%           charon  [kernel.kallsyms]                                                                    [k] finish_task_switch
     0.01%           charon  libgmp.so.3.4.1                                                                      [.]
__gmpn_sqr_n
     0.01%           charon  [kernel.kallsyms]                                                                    [k] _raw_spin_unlock_irqrestore
     0.01%           charon  libcharon.so.0.0.0                                                                   [.]
vlog
     0.01%           charon  [kernel.kallsyms]                                                                    [k] smp_call_function_many
     0.01%           charon  libstrongswan-sha1.so                                                                [.]
SHA1Update
     0.00%           charon  libc-2.11.1.so                                                                       [.] memcpy
     0.00%           charon  libc-2.11.1.so                                                                       [.]
Do I need to
use the Libgcrypt instead of GMP library?  If yes, please suggest how to do that. Or will you suggest drilling down
into  gmpn_addmul_1 function (GMP software component) to figure out the real
cause?
Thanks in advance for your help and suggestions.
 
Regards,
Chinmaya
 

________________________________
 From: Martin Willi <martin at strongswan.org>
To: Chinmaya Dwibedy <ckdwibedy at yahoo.com> 
Cc: "users at lists.strongswan.org" <users at lists.strongswan.org> 
Sent: Wednesday, September 25, 2013 1:10 PM
Subject: Re: [strongSwan] Performance issue with 20k IPsec tunnels (using 5.0.4 strongswan and load-tester plugin)
  


> I find, there are lots of retransmissions (as it prints the status of
> the initiation with *character mostly) in console. I know, these are
> certainly considered to be bad. But I have set the retransmit_timeout
> and retransmit_tries to 300 seconds and 300 times respectively, which
> is a huge.

The retransmissions usually indicate that one of the peers is
overloaded. Increasing retransmission timeouts can't solve your
performance limitations; this might help to work around the issues you
see in your lab, but certainly does not resemble what you have on a real
setup. Further, the charon.half_open_timeout strongswan.conf setting
defaulting to 30s
 will delete the IKE_SA on the responder if it does not
come up within that timeout.

As said before, I think you should focus on finding the bottleneck of
your setup rather than adjusting your client configuration. Use a
profiling tool.


Regards
Martin



   

_______________________________________________
Users mailing list
Users at lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20131021/b5e5c94e/attachment.html>