date:20170726

Re: [OpenSIPS-Users] Accounting of 200 OK and BYE

2017-07-26 Thread Daniel Zanutti

Hi Bogdan

So on transaction accounting, the record is written after transaction
receives final response. So it's not written as soon I receive BYE, but
when I receive the 200OK of the BYE.

My customer is complaining that the call is taking 200ms more and our
system is charging 1 sec more than on his billing. On million calls, this
is generating a some thousands difference.

Thanks for the information!

Regards

On Tue, Jul 25, 2017 at 6:36 AM, Bogdan-Andrei Iancu 
wrote:

> Hi Daniel,
>
> There are 3 types of accountings in OpenSIPS - per message, per
> transaction, per dialog.
>
> For the per message, it is clear :) . When doing per-transaction
> accounting, the ACC record is written when the transaction is completed
> with a final response (>=200) on the UAS side (towards caller). For the
> dialog based accounting, the time reference (for ending the call) is the
> reception of BYE request; still the CDR is written on the BYE final reply
> (as OpenSIPS allows you to collect CDR info from the BYE replies too).
>
> Best regards,
>
> Bogdan-Andrei Iancu
>   OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
>
> OpenSIPS Bootcamp 2017, Houston, US
>   http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
>
> On 07/20/2017 10:49 PM, Daniel Zanutti wrote:
>
> Hi Alex
>
> I'm having a billing problem from receiving BYE to 200 OK is taking more
> than 500ms. If BYE is accounted when it's received, great!
>
> Are you absolutely sure it works this way?
>
> Thanks
>
> On Thu, Jul 20, 2017 at 4:26 PM, Alex Balashov 
> wrote:
>
>> My understanding is that this is a rather simple module without
>> sophisticated state componentry, and that it logs things immediately as
>> received, in the same iteration of message processing.
>>
>> -- Alex
>>
>> --
>> Principal, Evariste Systems LLC (www.evaristesys.com)
>>
>> Sent from my Google Nexus.
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Small problem with opensips-cp MI

2017-07-26 Thread Scott Fertig

I apologize, I just found the issue on my own. Looks like it was because I left 
the default "JSON" in the json MI portion of the config, but I just found in 
the documentation the default is "json". I changed to all lower case and the 
issue is resolved. 





From: "Scott Fertig"  
To: "users"  
Sent: Wednesday, July 26, 2017 5:37:30 PM 
Subject: [OpenSIPS-Users] Small problem with opensips-cp MI 

HI, first I apologize if this has been gone over already but I have been 
searching and have not been able to find an answer as of yet. 

Simply my problem is that I cannot seem to get the MI connection setup properly 
in opensips-cp. I have tried json as well as FIFO with no success and was 
wondering if someone could point out what I may be doing wrong here. I am using 
Opensips 2.2.5 and Opensips-cp 6.2. 

When trying json my opensips-cp boxes.global.inc.php MI section looks as so: 

$boxes[$box_id]['mi']['conn']="json:127.0.0.1:/JSON"; 

I have mi_json and json loaded after the http and httpd modules in 
opensips.cfg: 

 HTTPD module 
loadmodule "httpd.so" 
modparam("httpd", "port", ) 

 MI_HTTP module 
loadmodule "json.so" 
loadmodule "mi_http.so" 
loadmodule "mi_json.so" 

When I try to use the MI commands section in the control panel, I issue a 
command and get back the error: 
"MI command failed with 400" 

Also I can see opensips listening on port : 
tcp 0 0 0.0.0.0: 0.0.0.0:* LISTEN 15232/opensips 


When I try to use fifo I get a different error, my boxes config looks like: 
$boxes[$box_id]['mi']['conn']="fifo:/tmp/opensips_fifo"; 

I can verify that the file exits in /tmp with the correct name and that the 
fifo module is loaded: 
ls -al /tmp/opensips_fifo 
prw-rw-rw- 1 root root 0 Jul 26 16:40 /tmp/opensips_fifo 

 FIFO Management Interface 
loadmodule "mi_fifo.so" 
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") 
modparam("mi_fifo", "fifo_mode", 0666) 


When trying to use fifo I get this error: 
Unknwon/Unsupported type[fifo] for MI URL 


Hopefully someone can point me in the right direction, I'm not exactly sure 
where to go next on this problem. 




___ 
Users mailing list 
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users 
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Small problem with opensips-cp MI

2017-07-26 Thread Scott Fertig

HI, first I apologize if this has been gone over already but I have been 
searching and have not been able to find an answer as of yet. 

Simply my problem is that I cannot seem to get the MI connection setup properly 
in opensips-cp. I have tried json as well as FIFO with no success and was 
wondering if someone could point out what I may be doing wrong here. I am using 
Opensips 2.2.5 and Opensips-cp 6.2. 

When trying json my opensips-cp boxes.global.inc.php MI section looks as so: 

$boxes[$box_id]['mi']['conn']="json:127.0.0.1:/JSON"; 

I have mi_json and json loaded after the http and httpd modules in 
opensips.cfg: 

 HTTPD module 
loadmodule "httpd.so" 
modparam("httpd", "port", ) 

 MI_HTTP module 
loadmodule "json.so" 
loadmodule "mi_http.so" 
loadmodule "mi_json.so" 

When I try to use the MI commands section in the control panel, I issue a 
command and get back the error: 
"MI command failed with 400" 

Also I can see opensips listening on port : 
tcp 0 0 0.0.0.0: 0.0.0.0:* LISTEN 15232/opensips 


When I try to use fifo I get a different error, my boxes config looks like: 
$boxes[$box_id]['mi']['conn']="fifo:/tmp/opensips_fifo"; 

I can verify that the file exits in /tmp with the correct name and that the 
fifo module is loaded: 
ls -al /tmp/opensips_fifo 
prw-rw-rw- 1 root root 0 Jul 26 16:40 /tmp/opensips_fifo 

 FIFO Management Interface 
loadmodule "mi_fifo.so" 
modparam("mi_fifo", "fifo_name", "/tmp/opensips_fifo") 
modparam("mi_fifo", "fifo_mode", 0666) 


When trying to use fifo I get this error: 
Unknwon/Unsupported type[fifo] for MI URL 


Hopefully someone can point me in the right direction, I'm not exactly sure 
where to go next on this problem. 



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] ERROR:core:proto_udp_send

2017-07-26 Thread Dawid Mielnik

Hi Liviu,

Exact version info:

version: opensips 2.2.2 (x86_64/linux)
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_lt, epoll_et, sigio_rt, select.
git revision: 9eb177d
main.c compiled on 11:43:55 Nov  3 2016 with gcc 4.4.7

BR,
Dawid

On Wed, Jul 26, 2017 at 7:09 PM, Liviu Chircu  wrote:

> Hi Dawid,
>
> This seems to have been fixed a long time ago [1], so I'm a bit puzzled.
> Just to be 100% sure, can you try to locate the exact binary path your
> OpenSIPS service is running on, and figure out the exact version that way?
> (e.g. output of "/usr/local/sbin/opensips -V")
>
> [1]: https://github.com/OpenSIPS/opensips/commit/d3aaf44c
>
> Liviu Chircu
> OpenSIPS Developerhttp://www.opensips-solutions.com
>
> On 26.07.2017 19:11, Dawid Mielnik wrote:
>
> Hi All,
>
> Can you help me understand the cause of these error messages ?
>
> [...]
> Jul 26 09:56:00.259767 ERR 32258  ERROR:core:proto_udp_send:
> sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
> unavailable(11)
> Jul 26 09:56:00.259813 ERR 32258  ERROR:core:proto_udp_send:
> sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
> unavailable(11)
> Jul 26 09:56:00.259822 ERR 32258  ERROR:core:proto_udp_send:
> sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
> unavailable(11)
> Jul 26 09:56:00.259831 ERR 32258  ERROR:core:proto_udp_send:
> sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
> unavailable(11)
> Jul 26 09:56:00.259839 ERR 32258  ERROR:core:proto_udp_send:
> sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
> unavailable(11)
> Jul 26 09:56:00.259847 ERR 32258  ERROR:core:proto_udp_send:
> sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
> unavailable(11)
> [...]
>
>
> Opensips 2.2.2.
> I am also using rest_client - for each call, before being proxied, an http
> request is made by rest_client. Before and during this time the http server
> was overloaded and took quite long time. I am suspecting that this is
> linked to it but would like to understand how exactly.
>
> Thanks,
> Dawid
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] ERROR:core:proto_udp_send

2017-07-26 Thread Liviu Chircu


Hi Dawid,

This seems to have been fixed a long time ago [1], so I'm a bit puzzled. 
Just to be 100% sure, can you try to locate the exact binary path your 
OpenSIPS service is running on, and figure out the exact version that 
way? (e.g. output of "/usr/local/sbin/opensips -V")


[1]: https://github.com/OpenSIPS/opensips/commit/d3aaf44c

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 26.07.2017 19:11, Dawid Mielnik wrote:

Hi All,

Can you help me understand the cause of these error messages ?

[...]
Jul 26 09:56:00.259767 ERR 32258  ERROR:core:proto_udp_send: 
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource 
temporarily unavailable(11)
Jul 26 09:56:00.259813 ERR 32258  ERROR:core:proto_udp_send: 
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource 
temporarily unavailable(11)
Jul 26 09:56:00.259822 ERR 32258  ERROR:core:proto_udp_send: 
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource 
temporarily unavailable(11)
Jul 26 09:56:00.259831 ERR 32258  ERROR:core:proto_udp_send: 
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource 
temporarily unavailable(11)
Jul 26 09:56:00.259839 ERR 32258  ERROR:core:proto_udp_send: 
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource 
temporarily unavailable(11)
Jul 26 09:56:00.259847 ERR 32258  ERROR:core:proto_udp_send: 
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource 
temporarily unavailable(11)

[...]


Opensips 2.2.2.
I am also using rest_client - for each call, before being proxied, an 
http request is made by rest_client. Before and during this time the 
http server was overloaded and took quite long time. I am suspecting 
that this is linked to it but would like to understand how exactly.


Thanks,
Dawid



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] ERROR:core:proto_udp_send

2017-07-26 Thread Dawid Mielnik

Hi All,

Can you help me understand the cause of these error messages ?

[...]
Jul 26 09:56:00.259767 ERR 32258  ERROR:core:proto_udp_send:
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
unavailable(11)
Jul 26 09:56:00.259813 ERR 32258  ERROR:core:proto_udp_send:
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
unavailable(11)
Jul 26 09:56:00.259822 ERR 32258  ERROR:core:proto_udp_send:
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
unavailable(11)
Jul 26 09:56:00.259831 ERR 32258  ERROR:core:proto_udp_send:
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
unavailable(11)
Jul 26 09:56:00.259839 ERR 32258  ERROR:core:proto_udp_send:
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
unavailable(11)
Jul 26 09:56:00.259847 ERR 32258  ERROR:core:proto_udp_send:
sendto(sock,0x7fb4817b3ba8,563,0,0x7fb484c23f10,16): Resource temporarily
unavailable(11)
[...]


Opensips 2.2.2.
I am also using rest_client - for each call, before being proxied, an http
request is made by rest_client. Before and during this time the http server
was overloaded and took quite long time. I am suspecting that this is
linked to it but would like to understand how exactly.

Thanks,
Dawid
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Does not release shared memory

2017-07-26 Thread Evgeniy G. via Users

I hope someone will help in the future when a similar situation arises.
Found the reason for the leak of private memory (pkmem). When the memory
ends in the logs of the message, a message is displayed.
2017-07-26T03: 42: 10.1251 B2BUA INFO: core: fm_malloc: unable to allocate a
large enough fragment!
2017-07-26T03: 42: 10.1252 B2BUA ERROR: core: do_action: memory allocation
failure
2017-07-26T03: 42: 10.1253 B2BUA ERROR: core: pv_set_ruri_port: do action
failed
2017-07-26T03: 42: 10.1254 B2BUA ERROR: core: do_assign: setting PV failed
2017-07-26T03: 42: 10.1255 B2BUA ERROR: core: do_assign: error at /
usr/local/opensips231//etc/opensips/opensips.cfg:221
2017-07-26T03: 42: 10.1256 B2BUA ERROR: core: fm_malloc: not enough free pkg
memory (0 bytes left, need 64), please increase the "-M" command line
parameter!
2017-07-26T03: 42: 10.1257 B2BUA INFO: core: fm_malloc: attempting
defragmentation ...

I was wondering why he displays an error in line 221. Here it is:
   $rd = $avp(dest_domain); $rp = $ avp(dest_port);

Where I set the values above
$avp dest_domain) = $dd;
$avp(dest_port) = $dp;

I commented out the line:
#$rd = $avp(dest_domain); $rp = $ avp (dest_port);

Pointed out to use for private memory (pkmem) 1 MB and restarted opensips.
Before loading, I looked at the statistics
[Root @ sbc sbin] # ./opensipsctl fifo get_statistics pkmem: | Grep pkmem:
[45]
Pkmem: 4-total_size :: 1048576
Pkmem: 4-used_size :: 103224
Pkmem: 4-real_used_size :: 146368
Pkmem: 4-max_used_size :: 146368
Pkmem: 4-free_size :: 902208
Pkmem: 4-fragments :: 393
Pkmem: 5-total_size :: 1048576
Pkmem: 5-used_size :: 103224
Pkmem: 5-real_used_size :: 146368
Pkmem: 5-max_used_size :: 146368
Pkmem: 5-free_size :: 902208
Pkmem: 5-fragments :: 393

Load included:
[Root @ sbc sbin] # ./opensipsctl fifo get_statistics pkmem: | Grep pkmem:
[45]
Pkmem: 4-total_size :: 1048576
Pkmem: 4-used_size :: 103272
Pkmem: 4-real_used_size :: 147976
Pkmem: 4-max_used_size :: 156968
Pkmem: 4-free_size :: 900600
Pkmem: 4-fragments :: 395
Pkmem: 5-total_size :: 1048576
Pkmem: 5-used_size :: 103224
Pkmem: 5-real_used_size :: 146368
Pkmem: 5-max_used_size :: 146368
Pkmem: 5-free_size :: 902208
Pkmem: 5-fragments :: 393

[Root @ sbc sbin] # ./opensipsctl fifo get_statistics pkmem: | Grep pkmem:
[45]
Pkmem: 4-total_size :: 1048576
Pkmem: 4-used_size :: 103272
Pkmem: 4-real_used_size :: 148024
Pkmem: 4-max_used_size :: 157056
Pkmem: 4-free_size :: 900552
Pkmem: 4-fragments :: 395
Pkmem: 5-total_size :: 1048576
Pkmem: 5-used_size :: 103224
Pkmem: 5-real_used_size :: 146368
Pkmem: 5-max_used_size :: 146368
Pkmem: 5-free_size :: 902208
Pkmem: 5-fragments :: 393
[Root @ sbc sbin] #



[Root @ sbc sbin] # ./opensipsctl fifo get_statistics pkmem: | Grep pkmem:
[45]
Pkmem: 4-total_size :: 1048576
Pkmem: 4-used_size :: 103272
Pkmem: 4-real_used_size :: 148024
Pkmem: 4-max_used_size :: 157056
Pkmem: 4-free_size :: 900552
Pkmem: 4-fragments :: 395
Pkmem: 5-total_size :: 1048576
Pkmem: 5-used_size :: 103280
Pkmem: 5-real_used_size :: 147624
Pkmem: 5-max_used_size :: 155416
Pkmem: 5-free_size :: 900952
Pkmem: 5-fragments :: 395


[Root @ sbc sbin] # ./opensipsctl fifo get_statistics pkmem: | Grep pkmem:
[45]
Pkmem: 4-total_size :: 1048576
Pkmem: 4-used_size :: 103272
Pkmem: 4-real_used_size :: 148024
Pkmem: 4-max_used_size :: 157056
Pkmem: 4-free_size :: 900552
Pkmem: 4-fragments :: 395
Pkmem: 5-total_size :: 1048576
Pkmem: 5-used_size :: 103280
Pkmem: 5-real_used_size :: 147984
Pkmem: 5-max_used_size :: 157256
Pkmem: 5-free_size :: 900592
Pkmem: 5-fragments :: 395
[Root @ sbc sbin] #

For 1100 seconds opensips successfully processed 11500 calls, statistics
[Root @ sbc sbin] # ./opensipsctl fifo get_statistics pkmem: | Grep pkmem:
[45]
Pkmem: 4-total_size :: 1048576
Pkmem: 4-used_size :: 103272
Pkmem: 4-real_used_size :: 148024
Pkmem: 4-max_used_size :: 157064
Pkmem: 4-free_size :: 900552
Pkmem: 4-fragments :: 395
Pkmem: 5-total_size :: 1048576
Pkmem: 5-used_size :: 103280
Pkmem: 5-real_used_size :: 148080
Pkmem: 5-max_used_size :: 157256
Pkmem: 5-free_size :: 900496
Pkmem: 5-fragments :: 395
[Root @ sbc sbin] #

The reason was in assigning the value of rd and rp.



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Does-not-release-shared-memory-tp7608065p7608138.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Does not release shared memory

2017-07-26 Thread Evgeniy G. via Users

Thank you for opensipsctl fifo ps
[root@sbc sbin]#  ./opensipsctl fifo ps
Process::  ID=0 PID=15438 Type=attendant
Process::  ID=1 PID=15440 Type=MI FIFO
Process::  ID=2 PID=15441 Type=time_keeper
Process::  ID=3 PID=15442 Type=timer
Process::  ID=4 PID=15444 Type=SIP receiver udp:10.2.1.52:7062 
Process::  ID=5 PID=15445 Type=SIP receiver udp:10.2.1.52:7062 
Process::  ID=6 PID=15446 Type=SIP receiver udp:XXX.XXX.XXX.XXX:7062 
Process::  ID=7 PID=15448 Type=SIP receiver udp:XXX.XXX.XXX.XXX:7062 
Process::  ID=8 PID=15449 Type=TCP receiver
Process::  ID=9 PID=15451 Type=TCP receiver
Process::  ID=10 PID=15452 Type=TCP receiver
Process::  ID=11 PID=15454 Type=TCP receiver
Process::  ID=12 PID=15455 Type=TCP receiver
Process::  ID=13 PID=15457 Type=TCP receiver
Process::  ID=14 PID=15458 Type=TCP receiver
Process::  ID=15 PID=15466 Type=TCP receiver
Process::  ID=16 PID=15467 Type=Timer handler
Process::  ID=17 PID=15468 Type=TCP main
[root@sbc sbin]# 




--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Does-not-release-shared-memory-tp7608065p7608136.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Does not release shared memory

2017-07-26 Thread Liviu Chircu


Here are some more MI commands that might be useful:

opensipsctl fifo ps -> the type of each process

opensipsctl fifo get_statistics dialog: tm: usrloc: -> display in-memory 
# of transactions / dialogs / registered users


Like before, if you suspect a leak, please provide the output of the 
above MI commands, along with a "kill -SIGUSR1" memory map as instructed 
earlier, and we should have a solid indication as to whether there's a 
real problem at hand or not.


Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 26.07.2017 16:02, Evgeniy G. via Users wrote:

Now I'm testing the server under load, 600 calls per minute and watching the
situation. I have only two sockets in the configuration:
listen = udp: 10.2.1.61: 7062
listen = udp: ХХ.ХХ.ХХХ.XXX: 7062
In the children parameter the value 2 is specified. But I can not understand
why 18 processes are created at startup ?... It's interesting that only two
of them take a role in the processing of calls, why? ... I found this out,
because of the decrease in two processes (pkmem:4 and pkmem:5) of pkg memory
.
Please explain the work with pkg memory when it is released.
I watched the server for 3 hours under load and 1 hour without, as a result,
on two processes the free private memory (pkmem) was rectilinearly reduced.
After testing, without restarting the server, private memory (pkgmem) is not
released, is it the way it should be?

[root@sbc sbin]# date
Срд Июл 26 09:31:45 MSK 2017
[root@sbc sbin]# ./opensipsctl fifo get_statistics pkmem:
[root@sbc sbin]# ./opensipsctl fifo get_statistics pkmem:
pkmem:0-total_size:: 67108864
pkmem:0-used_size:: 66608
pkmem:0-real_used_size:: 112560
pkmem:0-max_used_size:: 112560
pkmem:0-free_size:: 66996304
pkmem:0-fragments:: 510
pkmem:1-total_size:: 67108864
pkmem:1-used_size:: 87128
pkmem:1-real_used_size:: 135912
pkmem:1-max_used_size:: 146248
pkmem:1-free_size:: 66972952
pkmem:1-fragments:: 526
pkmem:2-total_size:: 67108864
pkmem:2-used_size:: 64832
pkmem:2-real_used_size:: 110664
pkmem:2-max_used_size:: 110672
pkmem:2-free_size:: 66998200
pkmem:2-fragments:: 500
pkmem:3-total_size:: 67108864
pkmem:3-used_size:: 64832
pkmem:3-real_used_size:: 110664
pkmem:3-max_used_size:: 110672
pkmem:3-free_size:: 66998200
pkmem:3-fragments:: 500
pkmem:4-total_size:: 67108864
pkmem:4-used_size:: 1144576
pkmem:4-real_used_size:: 2058560
pkmem:4-max_used_size:: 2069256
pkmem:4-free_size:: 65050304
pkmem:4-fragments:: 36614
pkmem:5-total_size:: 67108864
pkmem:5-used_size:: 1381584
pkmem:5-real_used_size:: 2495896
pkmem:5-max_used_size:: 2506568
pkmem:5-free_size:: 64612968
pkmem:5-fragments:: 44959
pkmem:6-total_size:: 67108864
pkmem:6-used_size:: 119960
pkmem:6-real_used_size:: 166824
pkmem:6-max_used_size:: 173640
pkmem:6-free_size:: 66942040
pkmem:6-fragments:: 518
pkmem:7-total_size:: 67108864
pkmem:7-used_size:: 119960
pkmem:7-real_used_size:: 166824
pkmem:7-max_used_size:: 173808
pkmem:7-free_size:: 66942040
pkmem:7-fragments:: 518
pkmem:8-total_size:: 67108864
pkmem:8-used_size:: 119840
pkmem:8-real_used_size:: 165912
pkmem:8-max_used_size:: 165912
pkmem:8-free_size:: 66942952
pkmem:8-fragments:: 515
pkmem:9-total_size:: 67108864
pkmem:9-used_size:: 119840
pkmem:9-real_used_size:: 165912
pkmem:9-max_used_size:: 165912
pkmem:9-free_size:: 66942952
pkmem:9-fragments:: 515
pkmem:10-total_size:: 67108864
pkmem:10-used_size:: 119840
pkmem:10-real_used_size:: 165912
pkmem:10-max_used_size:: 165912
pkmem:10-free_size:: 66942952
pkmem:10-fragments:: 515
pkmem:11-total_size:: 67108864
pkmem:11-used_size:: 119840
pkmem:11-real_used_size:: 165912
pkmem:11-max_used_size:: 165912
pkmem:11-free_size:: 66942952
pkmem:11-fragments:: 515
pkmem:12-total_size:: 67108864
pkmem:12-used_size:: 119840
pkmem:12-real_used_size:: 165912
pkmem:12-max_used_size:: 165912
pkmem:12-free_size:: 66942952
pkmem:12-fragments:: 515
pkmem:13-total_size:: 67108864
pkmem:13-used_size:: 119840
pkmem:13-real_used_size:: 165912
pkmem:13-max_used_size:: 165912
pkmem:13-free_size:: 66942952
pkmem:13-fragments:: 515
pkmem:14-total_size:: 67108864
pkmem:14-used_size:: 119840
pkmem:14-real_used_size:: 165912
pkmem:14-max_used_size:: 165912
pkmem:14-free_size:: 66942952
pkmem:14-fragments:: 515
pkmem:15-total_size:: 67108864
pkmem:15-used_size:: 119840
pkmem:15-real_used_size:: 165912
pkmem:15-max_used_size:: 165912
pkmem:15-free_size:: 66942952
pkmem:15-fragments:: 515
pkmem:16-total_size:: 67108864
pkmem:16-used_size:: 119840
pkmem:16-real_used_size:: 165912
pkmem:16-max_used_size:: 165912
pkmem:16-free_size:: 66942952
pkmem:16-fragments:: 515
pkmem:17-total_size:: 67108864
pkmem:17-used_size:: 109904
pkmem:17-real_used_size:: 155832
pkmem:17-max_used_size:: 155832
pkmem:17-free_size:: 66953032
pkmem:17-fragments:: 504
[root@sbc sbin]#




[root@sbc sbin]# date
Срд Июл 26 10:35:47 MSK 2017

[root@sbc sbin]# ./opensipsctl fifo get_statistics pkmem:
pkmem:0-total_size:: 67108864
pkmem:0-used_size:: 66608
pkmem:0-real_used_size:: 112560

Re: [OpenSIPS-Users] Does not release shared memory

2017-07-26 Thread Evgeniy G. via Users

Now I'm testing the server under load, 600 calls per minute and watching the
situation. I have only two sockets in the configuration:
listen = udp: 10.2.1.61: 7062
listen = udp: ХХ.ХХ.ХХХ.XXX: 7062
In the children parameter the value 2 is specified. But I can not understand
why 18 processes are created at startup ?... It's interesting that only two
of them take a role in the processing of calls, why? ... I found this out,
because of the decrease in two processes (pkmem:4 and pkmem:5) of pkg memory
.
Please explain the work with pkg memory when it is released.
I watched the server for 3 hours under load and 1 hour without, as a result,
on two processes the free private memory (pkmem) was rectilinearly reduced.
After testing, without restarting the server, private memory (pkgmem) is not
released, is it the way it should be?

[root@sbc sbin]# date
Срд Июл 26 09:31:45 MSK 2017
[root@sbc sbin]# ./opensipsctl fifo get_statistics pkmem: 
[root@sbc sbin]# ./opensipsctl fifo get_statistics pkmem: 
pkmem:0-total_size:: 67108864
pkmem:0-used_size:: 66608
pkmem:0-real_used_size:: 112560
pkmem:0-max_used_size:: 112560
pkmem:0-free_size:: 66996304
pkmem:0-fragments:: 510
pkmem:1-total_size:: 67108864
pkmem:1-used_size:: 87128
pkmem:1-real_used_size:: 135912
pkmem:1-max_used_size:: 146248
pkmem:1-free_size:: 66972952
pkmem:1-fragments:: 526
pkmem:2-total_size:: 67108864
pkmem:2-used_size:: 64832
pkmem:2-real_used_size:: 110664
pkmem:2-max_used_size:: 110672
pkmem:2-free_size:: 66998200
pkmem:2-fragments:: 500
pkmem:3-total_size:: 67108864
pkmem:3-used_size:: 64832
pkmem:3-real_used_size:: 110664
pkmem:3-max_used_size:: 110672
pkmem:3-free_size:: 66998200
pkmem:3-fragments:: 500
pkmem:4-total_size:: 67108864
pkmem:4-used_size:: 1144576
pkmem:4-real_used_size:: 2058560
pkmem:4-max_used_size:: 2069256
pkmem:4-free_size:: 65050304
pkmem:4-fragments:: 36614
pkmem:5-total_size:: 67108864
pkmem:5-used_size:: 1381584
pkmem:5-real_used_size:: 2495896
pkmem:5-max_used_size:: 2506568
pkmem:5-free_size:: 64612968
pkmem:5-fragments:: 44959
pkmem:6-total_size:: 67108864
pkmem:6-used_size:: 119960
pkmem:6-real_used_size:: 166824
pkmem:6-max_used_size:: 173640
pkmem:6-free_size:: 66942040
pkmem:6-fragments:: 518
pkmem:7-total_size:: 67108864
pkmem:7-used_size:: 119960
pkmem:7-real_used_size:: 166824
pkmem:7-max_used_size:: 173808
pkmem:7-free_size:: 66942040
pkmem:7-fragments:: 518
pkmem:8-total_size:: 67108864
pkmem:8-used_size:: 119840
pkmem:8-real_used_size:: 165912
pkmem:8-max_used_size:: 165912
pkmem:8-free_size:: 66942952
pkmem:8-fragments:: 515
pkmem:9-total_size:: 67108864
pkmem:9-used_size:: 119840
pkmem:9-real_used_size:: 165912
pkmem:9-max_used_size:: 165912
pkmem:9-free_size:: 66942952
pkmem:9-fragments:: 515
pkmem:10-total_size:: 67108864
pkmem:10-used_size:: 119840
pkmem:10-real_used_size:: 165912
pkmem:10-max_used_size:: 165912
pkmem:10-free_size:: 66942952
pkmem:10-fragments:: 515
pkmem:11-total_size:: 67108864
pkmem:11-used_size:: 119840
pkmem:11-real_used_size:: 165912
pkmem:11-max_used_size:: 165912
pkmem:11-free_size:: 66942952
pkmem:11-fragments:: 515
pkmem:12-total_size:: 67108864
pkmem:12-used_size:: 119840
pkmem:12-real_used_size:: 165912
pkmem:12-max_used_size:: 165912
pkmem:12-free_size:: 66942952
pkmem:12-fragments:: 515
pkmem:13-total_size:: 67108864
pkmem:13-used_size:: 119840
pkmem:13-real_used_size:: 165912
pkmem:13-max_used_size:: 165912
pkmem:13-free_size:: 66942952
pkmem:13-fragments:: 515
pkmem:14-total_size:: 67108864
pkmem:14-used_size:: 119840
pkmem:14-real_used_size:: 165912
pkmem:14-max_used_size:: 165912
pkmem:14-free_size:: 66942952
pkmem:14-fragments:: 515
pkmem:15-total_size:: 67108864
pkmem:15-used_size:: 119840
pkmem:15-real_used_size:: 165912
pkmem:15-max_used_size:: 165912
pkmem:15-free_size:: 66942952
pkmem:15-fragments:: 515
pkmem:16-total_size:: 67108864
pkmem:16-used_size:: 119840
pkmem:16-real_used_size:: 165912
pkmem:16-max_used_size:: 165912
pkmem:16-free_size:: 66942952
pkmem:16-fragments:: 515
pkmem:17-total_size:: 67108864
pkmem:17-used_size:: 109904
pkmem:17-real_used_size:: 155832
pkmem:17-max_used_size:: 155832
pkmem:17-free_size:: 66953032
pkmem:17-fragments:: 504
[root@sbc sbin]# 




[root@sbc sbin]# date
Срд Июл 26 10:35:47 MSK 2017

[root@sbc sbin]# ./opensipsctl fifo get_statistics pkmem: 
pkmem:0-total_size:: 67108864
pkmem:0-used_size:: 66608
pkmem:0-real_used_size:: 112560
pkmem:0-max_used_size:: 112560
pkmem:0-free_size:: 66996304
pkmem:0-fragments:: 510
pkmem:1-total_size:: 67108864
pkmem:1-used_size:: 87128
pkmem:1-real_used_size:: 135912
pkmem:1-max_used_size:: 146248
pkmem:1-free_size:: 66972952
pkmem:1-fragments:: 526
pkmem:2-total_size:: 67108864
pkmem:2-used_size:: 64832
pkmem:2-real_used_size:: 110664
pkmem:2-max_used_size:: 110672
pkmem:2-free_size:: 66998200
pkmem:2-fragments:: 500
pkmem:3-total_size:: 67108864
pkmem:3-used_size:: 64832
pkmem:3-real_used_size:: 110664
pkmem:3-max_used_size:: 110672
pkmem:3-free_size:: 66998200
pkmem:3-fragments:: 500

Re: [OpenSIPS-Users] Does not release shared memory

2017-07-26 Thread Evgeniy G. via Users

Hi, Liviu Chircu
Has found out in what the reason - the reason was in too big (very big)
values of parameters:
modparam ("tm", "fr_timeout", 3)
modparam ("tm", "fr_inv_timeout", 12)
modparam ("tm", "wt_timer", 15000)

I copied the parameters from an article on the Internet, so I did not pay
attention to their values.
During debugging, I noticed that after the transaction ended in case of
errors, for a very long time in tcpdump I saw the answers that generated the
opensips, understood that it should not be so, but postponed the setting.
And when I decided to reduce the time for generating answers or requests
without an answer, then I found out that the problem with not freeing memory
was exactly this.
Now I've reduced the values and everything has risen as it should be.



--
View this message in context: 
http://opensips-open-sip-server.1449251.n2.nabble.com/Does-not-release-shared-memory-tp7608065p7608134.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] !rest_get behavior

2017-07-26 Thread Liviu Chircu


Hi Tito,

It seems that originally, the rest_xxx() functions could return either 
"false" or "true", depending if the used libcurl was patched or not. 
This commit [1] fixed the problem, but the doc examples were not 
updated. I'll have it fixed.


[1]: https://github.com/OpenSIPS/opensips/commit/1363a620

Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

On 25.07.2017 21:18, Tito Cumpen wrote:


Group

I am using the latest opensips 2.3 and I am wondering why a 404 
response doesn't invoke this block ?



if (!rest_get("http://$avp(api)/cc/authorized/$fU/$rU", 
"$json(authresponse)", "$var(ct)", "$var(rcode)")) {


xlog("Error code $var(rcode) in HTTP GET!\n");


xlog("on account of admittance error we are sending the call to the AS 
server for processing");


route(ASroute);

}



the far end response looks like this.


HTTP/1.1 404 Not Found.

X-Powered-By: Express.

Vary: Origin, Accept-Encoding.

Access-Control-Allow-Credentials: true.

Content-Type: text/plain; charset=utf-8.

Content-Length: 9.

ETag: W/"9-nR6tc+Z4+i9RpwqTOwvwFw".

Date: Tue, 25 Jul 2017 18:11:39 GMT.

Connection: keep-alive.

.

Not Found

from the example it looks like other 4XX responses are considered.


Thanks,
Tito




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Accounting of 200 OK and BYE

Re: [OpenSIPS-Users] Small problem with opensips-cp MI

[OpenSIPS-Users] Small problem with opensips-cp MI

Re: [OpenSIPS-Users] ERROR:core:proto_udp_send

Re: [OpenSIPS-Users] ERROR:core:proto_udp_send

[OpenSIPS-Users] ERROR:core:proto_udp_send

Re: [OpenSIPS-Users] Does not release shared memory

Re: [OpenSIPS-Users] Does not release shared memory

Re: [OpenSIPS-Users] Does not release shared memory

Re: [OpenSIPS-Users] Does not release shared memory

Re: [OpenSIPS-Users] Does not release shared memory

Re: [OpenSIPS-Users] !rest_get behavior

12 matches

Site Navigation

Mail list logo

Footer information