SQLite is BUSY often, switch to PostgreSQL?

[TurabG]

I have 2pcu 8gb ram machine running FusionPBX with 14 extensions, 4 gateways and up to now, with maximum 5 or 6 concurrent calls. The last 3 days, I am seeing complaints from my customers about our phones not being available. I checked my provider logs, there are approximately 15 calls each day that can't reach us, that never make into FusionPBX call detail logs. I see "SQLite is BUSY" warnings in the log file a couple of times a day.

I know, from the old posts and from the working principle of SQLite, that it can be busy at times. But I shouldn't see this log entry everyday a couple of times, especially with an instance which is not very busy and crowded. I think FreeSWITCH and FusionPBX can handle much more crowded use cases with FS still using SQLite for its core. So what can be wrong with my instance here?

While trying to understand and diagnose what could be causing this, in the mean time, I am also considering to switch the FS core DB to PostgreSQL to avoid these locking conflicts. But is this really the wise solution? You know FS has native PgSQL support for quite a time now. When should someone really consider migrating their FS DB to PgSQL from SQLite?

 

[markjcrane]

SQLite is BUSY will be accompanied with some number like 299. Its counting down backwards so this means it tried one time and it was locked. This is not a concern this is normal operation. Now if the number gets down low into the double digits then you have a problem.

 

[TurabG]

Thank you, my instance stays at 299. I already understood it's not much of a concern but as I said in the first post, I am concerned for two reasons;

1- I see this quite often everyday, which wasn't the case before.
2- There are many calls that can't make into my log, that are dropped after the provider sends me. (Though not quite sure if the problem is on my side but I can at least see their logs sending me calls, while I see no activity on my side. So I thought maybe this database being busy coinciding the calls we can't receive.)

 

[DigitalDaz]

Do you have that sqlite database running in RAM, that would probably suit you, it does most of us?

 

[TurabG]

AFAIK, it's not in memory; because I haven't done anything for it and I don't see a guide how to make it. How can I make it work in memory?

Edit: I found this guide in FS documentation:

FreeSWITCH DB in RAMdrive | FreeSWITCH Documentation

About

developer.signalwire.com

This is enough or I need to take some steps on Fusion side too?

 

[junction1153]

Sorry to hijack this thread but I found this interesting. For those who have experience, is it better to run the freeswitch database through Postgres, or is setting up SQLite in RAMdrive better? Specifically for high capacity.

 

[TurabG]

Sorry to hijack this thread but I found this interesting. For those who have experience, is it better to run the freeswitch database through Postgres, or is setting up SQLite in RAMdrive better? Specifically for high capacity.

That's actually one of my questions already:

But is this really the wise solution? You know FS has native PgSQL support for quite a time now. When should someone really consider migrating their FS DB to PgSQL from SQLite?

 

[TurabG]

Update: I might have found the reason why we can't receive some of the calls. Our instance is behind a firewall, for which I am very glad. I didn't realize that our requests to the provider has our public IP in our "VIA" headers but we also have the firewall IP in the same header as "received" (from). Since the firewall IP didn't have SIP ports open but the public IP did; I thought provider could be reading the VIA header and route some calls to our public IP, which then we could receive and route some other calls to the firewall IP, which are then dropped before reaching to us.

This is very reasonable BUT.. the provider sent me their sngrep screenshots and I saw that since our requests reach to them always from firewall IP, they actually route all calls to our firewall IP, which is NOT the RTP and SIP IP in our Fusion config. So how comes we receive half of the calls while we shouldn't be receiving any at all?

I don't understand how calls can flow through the IP which doesn't have SIP ports open and which is not the public IP defined in Fusion (and therefore FreeSWITCH).

I now copied open ports of our PBX public IP onto firewall IP too; meaning both IPs will route calls to the same local IP of the PBX instance. I will watch it for some time and see what happens. But to be honest, I don't find this workaround neat or even correct. Any ideas?

By the way, now I think we have understood that SQLite Busy shouldn't be having anything to do with this issue but the question about SQLite vs. PgSQL still stands.