[OpenSIPS-Users] question on core statistics.
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Apr 24 08:27:54 UTC 2024
Which queue are you referring at?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 22.04.2024 09:17, Johan De Clercq wrote:
> Goed morning,
>
> How can I then increase opensips’s internal queue size?
>
> Best regards, Johan
>
> Verzonden vanuit Outlook voor iOS <https://aka.ms/o0ukef>
> ------------------------------------------------------------------------
> *Van:* Bogdan-Andrei Iancu <bogdan at opensips.org>
> *Verzonden:* Thursday, April 18, 2024 4:29:41 PM
> *Aan:* OpenSIPS users mailling list <users at lists.opensips.org>; Johan
> De Clercq <Johan at democon.be>
> *Onderwerp:* Re: [OpenSIPS-Users] question on core statistics.
> The `drop_requests` statistic is incremented when:
> * the request is dropped by a pre-script callback (like B2B when there
> is no script execution for certain messages)
> * the stateless `forward()` core function failed to send out something.
>
> Regards,
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
> https://www.opensips-solutions.com <https://www.opensips-solutions.com>
> https://www.siphub.com <https://www.siphub.com>
> On 18.04.2024 17:19, Johan De Clercq wrote:
>> No I don't.
>> what I find strange is that MAX_RECV_BUFFER_SIZE 262144 is the
>> default value of net.core.rmem_max and net.core.rmem_default.
>>
>> Op do 18 apr 2024 om 16:02 schreef Ben Newlin <Ben.Newlin at genesys.com
>> <mailto:Ben.Newlin at genesys.com>>:
>>
>> Are you calling drop() anywhere in your script?
>>
>> https://www.opensips.org/Documentation/Script-CoreFunctions-3-4#toc13
>> <https://www.opensips.org/Documentation/Script-CoreFunctions-3-4#toc13>
>>
>> Ben Newlin
>>
>> *From: *Users <users-bounces at lists.opensips.org
>> <mailto:users-bounces at lists.opensips.org>> on behalf of Johan De
>> Clercq <Johan at democon.be <mailto:Johan at democon.be>>
>> *Date: *Thursday, April 18, 2024 at 5:27 AM
>> *To: *OpenSIPS users mailling list <users at lists.opensips.org
>> <mailto:users at lists.opensips.org>>
>> *Subject: *Re: [OpenSIPS-Users] question on core statistics.
>>
>> * EXTERNAL EMAIL - Please use caution with links and attachments *
>>
>> ------------------------------------------------------------------------
>>
>> would it make sense to recompile with other flags ? And how do I
>> set them (I don't find these of menuconfig's compile options)?
>>
>> Currently it has MAX_RECV_BUFFER_SIZE 262144 and BUF_SIZE 65535.
>>
>> Can somebody explain also what both flags mean.
>>
>> Op do 18 apr 2024 om 11:07 schreef Johan De Clercq
>> <Johan at democon.be <mailto:Johan at democon.be>>:
>>
>> would it make sense to recompile with other flags ?
>>
>> Currently it has MAX_RECV_BUFFER_SIZE 262144 and BUF_SIZE 65535.
>>
>> Can somebody explain also what both flags mean.
>>
>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP,
>> PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
>>
>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144,
>> MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
>>
>> poll method support: poll, epoll, sigio_rt, select.
>>
>> Op do 18 apr 2024 om 10:32 schreef Johan De Clercq
>> <Johan at democon.be <mailto:Johan at democon.be>>:
>>
>> Guys,
>>
>> I have an opensips instance running with 24 worker children.
>>
>> The worker load is very low.
>>
>> UDP queues are on 50 megs.
>>
>> when i query via the OS
>>
>> cat /proc/net/udp
>>
>> sl local_address rem_address st tx_queue rx_queue tr
>> tm->when retrnsmt uid timeout inode ref pointer drops
>>
>> 590: 03231D0A:13C4 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 413684019 2
>> ffff880074820bc0 0
>>
>> 591: 03231D0A:13C5 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 413766438 2
>> ffff880465e4a440 0
>>
>> 592: 03231D0A:13C6 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 412035865 2
>> ffff8803e5a56b80 0
>>
>> 934: 01231D0A:151C 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 26790 2 ffff88046c054840 0
>>
>> 935: 0201FFEF:151D 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 26787 2 ffff88046c054bc0 0
>>
>> 935: 01231D0A:151D 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 26791 2 ffff88046c0544c0 0
>>
>> 1972: 00000000:D92A 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 15506 2 ffff88046dce5040 0
>>
>> 5479: 00000000:E6DD 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 22811 2 ffff880465e4ab40 0
>>
>> 12075: AA0914AC:00A1 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 20572 2 ffff88086d020800 0
>>
>> 12075: 0100007F:00A1 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 20571 2 ffff88086d020b80 0
>>
>> 13320: 00000000:857E 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 100 0 17515 2 ffff8800368ac780 0
>>
>> 15661: 00000000:CEA3 00000000:0000 07 00000000:00000000
>> 00:00000000 00000000 0 0 15505 2 ffff8800368acb00 0
>>
>> => no drops
>>
>> what worries me is that there are drop requests and they
>> go up when I query via the mi interface
>>
>> opensipsctl fifo get_statistics drop_requests
>>
>> core:drop_requests:: 198107
>>
>> opensipsctl fifo get_statistics drop_requests
>>
>> core:drop_requests:: 199157
>>
>> opensipsctl_reg fifo get_statistics drop_requests
>>
>> core:drop_requests:: 204116
>>
>> I don't see any memory issue, also the processload is low.
>>
>> so 3 questions:
>>
>> - what exactly is drop_request.
>>
>> - do I need to worry about this
>>
>> - how can I make them go lower.
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>> <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20240424/c939ab17/attachment-0001.html>
More information about the Users
mailing list