Issue #3613
Load-test jobs scheduled after tunnels are terminated
Description
Started some load-test initators using multiple "ipsec load-tester initiate" commands: "ipsec load-tester initiate 10 100"
I would then terminate the tunnels using
"swanctl -t -i load-test" or "swanctl -t -i load-test --force"
After the tunnels all terminate, I would repeat by running additonal ipsec load-test commands. I started looking at the jobs/threads after seeing performance struggles on repeated tests.
I noticed that in the output of the "swanctl -S" command, the "jobs scheduled" field would not drop back to 0. The number of jobs would accumulate as I would run additional load-test commands.
Restarting the ipsec service does reset everything as expected. I don't have a need to be able to keep bringing test tunnels up and then down. Restarting ipsec is fine and I am expecting that is how this plugin may have been designed to be used, which is fine. However, I wanted to open a ticket in case there is a potential underlying issue outside the scope of the load-tester or if this isn't your expected behavior.
Below is some example out of the swanctl -S commands show the jobs scheduled not dropping to 0. Also included snippets from the load-tester and charon conf files.
03:37:05 worker threads: 32 total, 27 idle, working: 4/0/1/0 job queues: 0/0/0/0 jobs scheduled: 0 IKE_SAs: 0 total, 0 half-open 03:39:05 worker threads: 32 total, 27 idle, working: 4/0/1/0 job queues: 0/0/0/0 jobs scheduled: 30 IKE_SAs: 10 total, 0 half-open 03:40:35 worker threads: 32 total, 27 idle, working: 4/0/1/0 job queues: 0/0/0/0 jobs scheduled: 30 IKE_SAs: 0 total, 0 half-open 03:42:15 worker threads: 32 total, 27 idle, working: 4/0/1/0 job queues: 0/0/0/0 jobs scheduled: 320 IKE_SAs: 100 total, 0 half-open 03:43:55 worker threads: 32 total, 27 idle, working: 4/0/1/0 job queues: 0/0/0/0 jobs scheduled: 220 IKE_SAs: 0 total, 0 half-open
load-tester.conf
load-tester { load = yes enable = yes addrs_keep = no version = 2 initiators = 0 iterations = 0 delay = 1000 init_limit = 0 ca_dir = /usr/local/etc/swanctl/x509ca issuer_cert = /usr/local/etc/swanctl/x509ca/enb-signing.crt issuer_key = /usr/local/etc/swanctl/private/enb-signing.key ike_rekey = 3600 child_rekey = 1800 crl = http://test/crl/enb/signing.crl.pem addrs { ens33 = 2001a:b:4001:f::2/64 } addrs_keep = yes addrs_prefix = 64 #initiator = 2001a:b:4001:f::1 responder = 2001a:b:7001:1::1 initiator_auth = pubkey responder_auth = pubkey responder_id = C=US, CN=site1pair1 initiator_id = CN=conn-%d, OU=load-test, O=strongSwan initiator_tsi = ::/0 initiator_tsr = ::/0 delete_after_established = no digest = sha256 mode = tunnel proposal = aes256gcm16-sha256-modp2048 esp = aes256gcm16-sha256 request_virtual_ip = yes dpd_delay = 30 shutdown_when_complete = no }
charon.conf (only configured parms shown, everything else is default)
charon { dos_protection = no ikesa_table_segments = 128 ikesa_table_size = 1024 initiator_only = yes install_routes = no install_virtual_ip = yes interfaces_use = ens33 reuse_ikesa = no threads = 32 }
History
#1 Updated by Tobias Brunner 4 months ago
- Status changed from New to Feedback
For every IKE_SA there are a number of jobs queued (for rekeying, retransmits etc.). These are not cleared if the corresponding IKE_SA is terminated (our job scheduler does not allow for that). But they will basically just be no-ops if the IKE_SA is already gone (there is some overhead as they occupy one of the threads and when trying to check out the IKE_SA for a job, but most use SPIs to do so i.e. that happens via hashtable).