Re: [Freeswitch-users] High load on database server
possible that you have somwhere redundant SQL request from your script or dialplan... ----- Original Message ----- From: "Madovsky" <infos@madovsky.org> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Thursday, October 27, 2011 2:15 AM Subject: Re: [Freeswitch-users] High load on database server
try the version 2.3.0 of ODBC (compiled from sources) I can't tell you if it will work because I never had more than 20 councurrent calls but it should be better anyeway
----- Original Message ----- From: "Cliff Wells" <cliff@develix.com> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Thursday, October 27, 2011 2:02 AM Subject: Re: [Freeswitch-users] High load on database server
On Wed, 2011-10-26 at 11:12 -0500, Anthony Minessale wrote:
if you have older unixodbc edit /etc/odbcinst.ini and add the param Threading=0 to each db entry.
In general postgres to me appears to care more about multithreaded environments and with the above threading=0 change works pretty well.
I tried this (after googling a bit and coming across an older thread you responded to) and it didn't change anything. Crashes at ~330 concurrent calls like clockwork. This was with unixODBC 2.14 and PostgreSQL 8.4 odbc driver.
Regards, Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Thu, 2011-10-27 at 02:21 -0400, Madovsky wrote:
possible that you have somwhere redundant SQL request from your script or dialplan...
As I mentioned previously, we also have some applications (mod_lua) that utilize the internal odbc pool, so the concurrency is somewhat higher (but not a lot, maybe another 20%). Regards, Cliff
You should be able to test the DB connections w/o live traffic.. -Avi On Thu, Oct 27, 2011 at 8:34 AM, Cliff Wells <cliff@develix.com> wrote:
On Thu, 2011-10-27 at 02:21 -0400, Madovsky wrote:
possible that you have somwhere redundant SQL request from your script or dialplan...
As I mentioned previously, we also have some applications (mod_lua) that utilize the internal odbc pool, so the concurrency is somewhat higher (but not a lot, maybe another 20%).
Regards, Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Well, that was the reason why I stopped using lua a while ago. It crashes on high load if database queries are involved. I had crashes with both native FS odbc support or with luasql. On Thursday 27 October 2011, Cliff Wells wrote:
On Thu, 2011-10-27 at 02:21 -0400, Madovsky wrote:
possible that you have somwhere redundant SQL request from your script or dialplan...
As I mentioned previously, we also have some applications (mod_lua) that utilize the internal odbc pool, so the concurrency is somewhat higher (but not a lot, maybe another 20%).
Regards, Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
That is FUD, please refrain. If properly setup and deployed database stuff is fine. If some people have had problems, there is a reason they are just too busy to figure out why and move on..... On Thu, Oct 27, 2011 at 6:51 AM, Sergey Okhapkin <sos@sokhapkin.dyndns.org>wrote:
Well, that was the reason why I stopped using lua a while ago. It crashes on high load if database queries are involved. I had crashes with both native FS odbc support or with luasql.
On Thursday 27 October 2011, Cliff Wells wrote:
On Thu, 2011-10-27 at 02:21 -0400, Madovsky wrote:
possible that you have somwhere redundant SQL request from your script or dialplan...
As I mentioned previously, we also have some applications (mod_lua) that utilize the internal odbc pool, so the concurrency is somewhat higher (but not a lot, maybe another 20%).
Regards, Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
What does it mean? That I cannot access the DB from scripts? Sent from my mobile device On Oct 27, 2011, at 8:21, "Madovsky" <infos@madovsky.org> wrote:
possible that you have somwhere redundant SQL request from your script or dialplan...
----- Original Message ----- From: "Madovsky" <infos@madovsky.org> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Thursday, October 27, 2011 2:15 AM Subject: Re: [Freeswitch-users] High load on database server
try the version 2.3.0 of ODBC (compiled from sources) I can't tell you if it will work because I never had more than 20 councurrent calls but it should be better anyeway
----- Original Message ----- From: "Cliff Wells" <cliff@develix.com> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Thursday, October 27, 2011 2:02 AM Subject: Re: [Freeswitch-users] High load on database server
On Wed, 2011-10-26 at 11:12 -0500, Anthony Minessale wrote:
if you have older unixodbc edit /etc/odbcinst.ini and add the param Threading=0 to each db entry.
In general postgres to me appears to care more about multithreaded environments and with the above threading=0 change works pretty well.
I tried this (after googling a bit and coming across an older thread you responded to) and it didn't change anything. Crashes at ~330 concurrent calls like clockwork. This was with unixODBC 2.14 and PostgreSQL 8.4 odbc driver.
Regards, Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I means that depend the quality of your script ;) ----- Original Message ----- From: "Hynek Cihlar" <hynek.cihlar@gmail.com> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Thursday, October 27, 2011 3:46 AM Subject: Re: [Freeswitch-users] High load on database server
What does it mean? That I cannot access the DB from scripts?
Sent from my mobile device
On Oct 27, 2011, at 8:21, "Madovsky" <infos@madovsky.org> wrote:
possible that you have somwhere redundant SQL request from your script or dialplan...
----- Original Message ----- From: "Madovsky" <infos@madovsky.org> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Thursday, October 27, 2011 2:15 AM Subject: Re: [Freeswitch-users] High load on database server
try the version 2.3.0 of ODBC (compiled from sources) I can't tell you if it will work because I never had more than 20 councurrent calls but it should be better anyeway
----- Original Message ----- From: "Cliff Wells" <cliff@develix.com> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Thursday, October 27, 2011 2:02 AM Subject: Re: [Freeswitch-users] High load on database server
On Wed, 2011-10-26 at 11:12 -0500, Anthony Minessale wrote:
if you have older unixodbc edit /etc/odbcinst.ini and add the param Threading=0 to each db entry.
In general postgres to me appears to care more about multithreaded environments and with the above threading=0 change works pretty well.
I tried this (after googling a bit and coming across an older thread you responded to) and it didn't change anything. Crashes at ~330 concurrent calls like clockwork. This was with unixODBC 2.14 and PostgreSQL 8.4 odbc driver.
Regards, Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Thu, 2011-10-27 at 11:55 -0400, Madovsky wrote:
I means that depend the quality of your script ;)
Quality isn't the issue here. The script is too simple to be incorrect (and it carefully releases the odbc connection back to the pool in a hangup handler). I have written poor-quality code plenty of times, but 25 years as a programmer usually allows me the luxury of knowing when I'm doing it, thanks. In any case, Lua scripts work fine. Google will tell you that unixODBC before 2.3.0 was a bit of a mess, so I expect the issue lies there, but again, I emphasize, everything WORKS GREAT (been using it for a couple of years now) until you get to very high concurrency (about 330 concurrent calls on a single system). If you don't expect to handle more than 300 concurrent calls, then you do not need to worry about it. At all. Regards, Cliff
ha ok, good luck so ----- Original Message ----- From: "Cliff Wells" <cliff@develix.com> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Thursday, October 27, 2011 12:26 PM Subject: Re: [Freeswitch-users] High load on database server
On Thu, 2011-10-27 at 11:55 -0400, Madovsky wrote:
I means that depend the quality of your script ;)
Quality isn't the issue here. The script is too simple to be incorrect (and it carefully releases the odbc connection back to the pool in a hangup handler). I have written poor-quality code plenty of times, but 25 years as a programmer usually allows me the luxury of knowing when I'm doing it, thanks.
In any case, Lua scripts work fine. Google will tell you that unixODBC before 2.3.0 was a bit of a mess, so I expect the issue lies there, but again, I emphasize, everything WORKS GREAT (been using it for a couple of years now) until you get to very high concurrency (about 330 concurrent calls on a single system). If you don't expect to handle more than 300 concurrent calls, then you do not need to worry about it. At all.
Regards, Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Did you try to locate the source of the segmantation fault? At least the module. Sent from my mobile device On Oct 27, 2011, at 18:27, Cliff Wells <cliff@develix.com> wrote:
On Thu, 2011-10-27 at 11:55 -0400, Madovsky wrote:
I means that depend the quality of your script ;)
Quality isn't the issue here. The script is too simple to be incorrect (and it carefully releases the odbc connection back to the pool in a hangup handler). I have written poor-quality code plenty of times, but 25 years as a programmer usually allows me the luxury of knowing when I'm doing it, thanks.
In any case, Lua scripts work fine. Google will tell you that unixODBC before 2.3.0 was a bit of a mess, so I expect the issue lies there, but again, I emphasize, everything WORKS GREAT (been using it for a couple of years now) until you get to very high concurrency (about 330 concurrent calls on a single system). If you don't expect to handle more than 300 concurrent calls, then you do not need to worry about it. At all.
Regards, Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Thu, 2011-10-27 at 18:42 +0200, Hynek Cihlar wrote:
Did you try to locate the source of the segmantation fault? At least the module.
Here's a sample: freeswitch[30818]: segfault at 710 ip 00007f343516b491 sp 00007f33f17b7fc0 error 4 in psqlodbcw.so[7f3435126000+7d000] I know it's pointing at the PostgreSQL ODBC driver (and this may, in fact, be the case), but it's hard to know whether the driver itself is the issue, or whether mishandling of the driver is at fault. Also, in 2.3.0, unixODBC stopped shipping their own PostgreSQL driver and now use the one shipped with PostgreSQL instead, so this may have an impact on stability. In any case, until I'm able to do more testing with 2.3.0 I'm just speculating. Cliff
That's not useful, you need to collect the core and run gdb on it. On Thu, Oct 27, 2011 at 2:07 PM, Cliff Wells <cliff@develix.com> wrote:
On Thu, 2011-10-27 at 18:42 +0200, Hynek Cihlar wrote:
Did you try to locate the source of the segmantation fault? At least the module.
Here's a sample:
freeswitch[30818]: segfault at 710 ip 00007f343516b491 sp 00007f33f17b7fc0 error 4 in psqlodbcw.so[7f3435126000+7d000]
I know it's pointing at the PostgreSQL ODBC driver (and this may, in fact, be the case), but it's hard to know whether the driver itself is the issue, or whether mishandling of the driver is at fault.
Also, in 2.3.0, unixODBC stopped shipping their own PostgreSQL driver and now use the one shipped with PostgreSQL instead, so this may have an impact on stability. In any case, until I'm able to do more testing with 2.3.0 I'm just speculating.
Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
On Thu, 2011-10-27 at 14:11 -0500, Anthony Minessale wrote:
That's not useful, you need to collect the core and run gdb on it.
I also assume I'd need the debug versions of the related software installed? Cliff
On Thu, Oct 27, 2011 at 2:07 PM, Cliff Wells <cliff@develix.com> wrote: On Thu, 2011-10-27 at 18:42 +0200, Hynek Cihlar wrote: > Did you try to locate the source of the segmantation fault? At least > the module.
Here's a sample:
freeswitch[30818]: segfault at 710 ip 00007f343516b491 sp 00007f33f17b7fc0 error 4 in psqlodbcw.so[7f3435126000+7d000]
I know it's pointing at the PostgreSQL ODBC driver (and this may, in fact, be the case), but it's hard to know whether the driver itself is the issue, or whether mishandling of the driver is at fault.
Also, in 2.3.0, unixODBC stopped shipping their own PostgreSQL driver and now use the one shipped with PostgreSQL instead, so this may have an impact on stability. In any case, until I'm able to do more testing with 2.3.0 I'm just speculating.
Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
ya On Thu, Oct 27, 2011 at 2:28 PM, Cliff Wells <cliff@develix.com> wrote:
On Thu, 2011-10-27 at 14:11 -0500, Anthony Minessale wrote:
That's not useful, you need to collect the core and run gdb on it.
I also assume I'd need the debug versions of the related software installed?
Cliff
On Thu, Oct 27, 2011 at 2:07 PM, Cliff Wells <cliff@develix.com> wrote: On Thu, 2011-10-27 at 18:42 +0200, Hynek Cihlar wrote: > Did you try to locate the source of the segmantation fault? At least > the module.
Here's a sample:
freeswitch[30818]: segfault at 710 ip 00007f343516b491 sp 00007f33f17b7fc0 error 4 in psqlodbcw.so[7f3435126000+7d000]
I know it's pointing at the PostgreSQL ODBC driver (and this may, in fact, be the case), but it's hard to know whether the driver itself is the issue, or whether mishandling of the driver is at fault.
Also, in 2.3.0, unixODBC stopped shipping their own PostgreSQL driver and now use the one shipped with PostgreSQL instead, so this may have an impact on stability. In any case, until I'm able to do more testing with 2.3.0 I'm just speculating.
Cliff
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:
http://lists.freeswitch.org/mailman/options/freeswitch-users
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
participants (6)
-
Anthony Minessale
-
Avi Marcus
-
Cliff Wells
-
Hynek Cihlar
-
Madovsky
-
Sergey Okhapkin