I have a linux machine that runs 50 instances of the same 50Mb database. cmd for each looks like this:
With NN starting at 01 up to 50 These databases are presently all just idling. No workload. But between 2-5 hours, a random one would just stop running. Upon inspecting the /var/log folder in my Ubuntu server, I came across the following in the apport.log file:
Any idea what could cause this, or where I should start looking? What is the maximum number of databases I can run on a single machine? I don't want to run a single server with multiple databases as each should listen on a different port. asked 05 Feb '15, 22:52 Liam |
This is indicating that the database server process (pid 2985) received a signal 6 (SIGABRT). SQL Anywhere will typically issue a SIGABRT during a database assertion. (See KBA 1958942 - Error: "Assertion failed: 123456" / SQLCODE -301 "Internal Database Error" - Handling an Assertion Failure)
Just to confirm the scenario: so for two hours, the database server was running, checkpointing, etc. and then crashed with no message in the console log ( Typically when SQL Anywhere crashes, we have a signal handler that attempts to write out a core file to the current working directory of the database server (using the default Under these situations to generate a core file you must either:
In this case (Ubuntu), For more information about SQL Anywhere and core files, and to understand which files we will need to collect in technical support to analyze the core files for more information, see the following KBAs:
answered 06 Feb '15, 11:26 Jeff Albion Thank you Jeff. Will go through this and revert back to you.
(06 Feb '15, 20:22)
Liam
Jeff I have located the core files in /var/crash /var/crash/_opt_sqlanywhere16_bin64_dbsrv16.1002.crash Is this what you're referring to? Could this be submitted to SAP for analysis?
(11 Feb '15, 15:15)
Liam
Replies hidden
Yes, that sounds like the core file we would need to collect, generated from apport.
Yes, for sure. But as mentioned above, we will also need to collect the system libraries from the crashing system in order to open the core file for a detailed analysis - can you open an incident with SAP Support? Also depending on how big the core file is, you may have to upload it to us via FTP - we can provide the details on how to do this via the incident.
(11 Feb '15, 16:37)
Jeff Albion
|
To cite a Jeff Albion answer from a comment on that other FAQ:
I can't tell on the reported error, however, running 50 instances will certainly have a deep impact on resource using/sharing compared to one instance with 50 databases in total as the latter would apparently share resources between the databases "by design". Nevertheless, as you say, that would not allow different TCP/IP ports for each database.
I assume there's nothing helpful in either diagnostic log file -oe /peopleweb/dbNN/errors.txt -o /peopleweb/dbNN/console.txt
I also assume you know the implications of -m (and it probably has nothing to do with this symptom)
Generally speaking, -tl 0 is a very bad idea (unlike -ti 0 which is often a requirement). The -tl 0 option essentially tells the server to never drop dead/defunct connections, and I've never seen a situation where that is desirable... but again, it probably has nothing to do with this symptom.
When you say "stop running" do you mean "crashes" or do you mean "stops responding to requests"?
You may want to call SAP Tech Support... AFAIK there's not a lot of Ubuntu apport debugging expertise on this forum.
Thank you Breck. The -tl0 is a relic from our Client/Server application. Will take that out.
The database simply crashes. Dies. Nothing in the two files either.
Thanks for the advice.