|
Recently migrated one of our large customer from 7.04 to 12 on a Solaris Sparc box. About 100 or so users in the field all banging away on a dispatching web app that is highly transactional. Aside from outer join issues and having do rewrite some queries everything ran good for about 2 weeks. Yesterday we saw the dbsrv12 process disappear twice in a 2 hour period. We had to refire the DB and restart all of our client facing apps (webservers, app servers, etc.) to get it back up. Everything came back up but then it happened again. What is the best way to see what is causing this as their is nothing in any log files etc.? The last time I restarted it, I used the -oe command line switch to log the errors to a file. Is this the preferred method to capture fatal errors? Is there anything else we should have turned on? Any help is greatly appreciated. Bob |
|
One thing that comes to mind is to verify that you have sufficient swap space to cover the maximum cache size that may be used by the server. Solaris allows memory to be overcommitted which means that if the server grows the cache and accesses new memory when there is no swap available, it will die with a SIGBUS. The default maximum cache size in v12 is significantly larger than it was in v7. You can add more swap space or control the max cache size by using the "-ch" command line option on the server. If you are not already providing a "-ch" parameter, you can determine what the server chose for the max cache size by looking at the messages written during startup (use -o switch, use Sybase central, etc) or SELECT property('MaxCacheSize') in SQL. 2
In addition to the cache, the temp file on Solaris would also consume swap space because it is usually stored in /tmp, which is normally set up as TMPFS (an in-memory file system). You can Out-of-memory situations seem most likely since there's nothing in your log file (meaning the process died very suddenly). However, the server might be crashing for other reasons. You might want to enable core files and have a look at the crash dump that gets generated. If you can't make sense of it, you can open a case with tech support and we would be able to look at it for you. Another possibility is that the server is not crashing at all, but is being killed. We've seen cases where an unrelated process is running away in the background and "cleaning up" files and processes that it doesn't think should be there, thus causing the SA server to shut down unexpectedly. This is probably not what you're seeing, but we can't rule it out just yet.
(27 Apr '11, 11:17)
Phil Mitchell
|
