<div dir="ltr">Hey Liviu and Bogdan,<br><br><div>Thanks for the help! There are intermediate test results:<br><div>- (-m 1024 -M 32 -a F_MALLOC) with sequentially tls reloads, the speed situation does not change:</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>#opensips-cli -x mi get_statistics fragments && opensips-cli -x mi get_statistics free_size && opensips-cli -x mi get_statistics real_used_size && time opensips-cli -x mi tls_reload</div></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px">{<br>    "shmem:fragments": <span style="background-color:rgb(255,255,0)">2211707</span><br>}<br>{<br>    "shmem:free_size": 803916912<br>}<br>{<br>    "shmem:real_used_size": 269797192<br>}<br>"OK"<br>real    1m25.763s<br><br>#opensips-cli -x mi get_statistics fragments && opensips-cli -x mi get_statistics free_size && opensips-cli -x mi get_statistics real_used_size && time opensips-cli -x mi tls_reload<br>    "shmem:fragments": <span style="background-color:rgb(255,255,0)">2212109</span><br>}<br>{<br>    "shmem:free_size": 803993112<br>}<br>{<br>    "shmem:real_used_size": 269775568<br>}<br>"OK"<br>real    1m20.740s<br><br>#opensips-cli -x mi get_statistics fragments && opensips-cli -x mi get_statistics free_size && opensips-cli -x mi get_statistics real_used_size && time opensips-cli -x mi tls_reload<br>{<br>    "shmem:fragments": <span style="background-color:rgb(255,255,0)">2212511</span><br>}<br>{<br>    "shmem:free_size": 803915424<br>}<br>{<br>    "shmem:real_used_size": 269799376<br>}<br>"OK"<br>real    1m17.780s<br><br>#opensips-cli -x mi get_statistics fragments && opensips-cli -x mi get_statistics free_size && opensips-cli -x mi get_statistics real_used_size && time opensips-cli -x mi tls_reload<br>    "shmem:fragments": <span style="background-color:rgb(255,255,0)">2212913</span><br>}<br>{<br>    "shmem:free_size": 803858880<br>}<br>{<br>    "shmem:real_used_size": 269855408<br>}<br>"OK"<br>real    1m13.682s<br><br>#opensips-cli -x mi get_statistics fragments && opensips-cli -x mi get_statistics free_size && opensips-cli -x mi get_statistics real_used_size && time opensips-cli -x mi tls_reload<br>{<br>    "shmem:fragments": <span style="background-color:rgb(255,255,0)">2213337</span><br>}<br>{<br>    "shmem:free_size": 803876200<br>}<br>{<br>    "shmem:real_used_size": 269865624<br>}<br></blockquote><div><br>- (-m 1024 -M 32 -a HP_MALLOC) with this memory allocator the service does not even start as systemd kills it by timeout:</div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><i>Jun 11 16:33:33 opensips-01.localhost systemd[1]: opensips.service: Failed with result 'timeout'.<br></i><i>Jun 11 16:33:33 opensips-01.localhost systemd[1]: Stopped opensips.service - OpenSIPS is a very fast and flexible SIP (RFC3261) server.<br></i><i>Jun 11 16:33:33 opensips-01.localhost systemd[1]: opensips.service: <span style="background-color:rgb(255,255,0)">Consumed 1min 52.462s CPU time.<br></span></i><div><br></div></blockquote>>

What is the usage of the shm mem (use the shmem: stats class to see) ?<div>At the time of tls reload I can’t get any statistics (this time opensips eats 100% of the CPU), only there is a possibility between reloads</div><div><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><br class="gmail-Apple-interchange-newline"></blockquote></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">пт, 31 мая 2024 г. в 11:51, Liviu Chircu <<a href="mailto:liviu@opensips.org">liviu@opensips.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Denys,<br>
<br>
The report shows OpenSSL library doing small SHM allocations (4, 10, <br>
608, 24... bytes), which seem to frequently take place inside the <br>
PEM_read_bio_X509() loop (as part of the load_certificate_db() <br>
function).  Such a sequence of allocations could be stress-testing the <br>
allocator in a way that could justify 250 ms per certificate in total, <br>
as it is fragmenting the memory.  The effect can be more pronounced the <br>
*less* stuff is going on in your OpenSIPS instance, as the process of <br>
breaking up the big memory chunk into smaller units may use up to <br>
hundreds of cycles on each allocation.  For example:  testing box with <br>
no SIP traffic, or 'tls_reload' after a fresh restart, etc.<br>
<br>
Please try the following:<br>
<br>
- still using F_MALLOC, try doing more 'tls_reload' operations in a <br>
row.  Does performance improve?<br>
<br>
- try using the "-a HP_MALLOC" allocator when booting your OpenSIPS - <br>
that one favors memory fragmentation a bit more, so subsequent reloads <br>
should be faster<br>
<br>
Best regards,<br>
<br>
Liviu Chircu<br>
<a href="http://www.twitter.com/liviuchircu" rel="noreferrer" target="_blank">www.twitter.com/liviuchircu</a> | <a href="http://www.opensips-solutions.com" rel="noreferrer" target="_blank">www.opensips-solutions.com</a><br>
<br>
On 14.05.2024 16:47, Denys Pozniak wrote:<br>
> I disabled logging and added some resources to the virtual machine.<br>
> On a working OpenSIPS, I reloaded the tls several times and in <br>
> parallel ran a trap.<br>
> #opensips-cli -x mi tls_reload<br>
> #opensips-cli -x trap<br>
><br>
> If possible, please analyze it again, maybe you could find something <br>
> interesting:<br>
> <a href="https://github.com/denyspozniak/opensips_tls_debug/tree/main" rel="noreferrer" target="_blank">https://github.com/denyspozniak/opensips_tls_debug/tree/main</a><br>
><br>
> Thanks in advance!<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><br><div><div>BR,</div><div>Denys Pozniak<br></div><div><br></div><div><br></div></div></div></div>