|
Hi I have SQL Anywhere 10 installed on an Arch Linux machine for development purposes. When I try to start a database server I now get an "out of memory" error. It worked fine up until a couple of days ago. What has changed since then is that I upgraded the linux kernel from version 2.6.* to 3.0. This is the command I run: This is the output I get: My SA version: 10.0.1.4239 I have tried to set the cache sizes manually with the -c and -ca directives without success. The size of the database file is only about 25MB and I have 3G free memory. |
|
We have not tested anything on the 3.0 kernel yet. We typically test on official releases of Linux distributions including Red Hat Enterprise, Suse, Ubuntu LTS, and Fedora. We probably will not officially support the 3.0 kernel until one of these distributions releases with it. We may never officially support the 3.0 kernel in SA 10.0.1, but we will try to be as helpful as we can. The "Not enough memory" error indicates that the server failed to allocate a piece of memory that it needed. There could be lots of reasons for that. Calculating the cache size incorrectly (as you attempted to work around by specifying the cache size manually) could be just one of those. SELinux, if that is enabled, could also cause such a problem. You could also check your I cannot enumerate all possible reasons for this error. If you run the server through strace -o trace.out /opt/sqlanywhere10/bin64/dbsrv10 -n my_serv /path/to/database.db Look in the resulting If that doesn't show you anything useful, I would recommend that you work with technical support to send us some more diagnostic information. 3
Update: I have tried this on the new Fedora 16 distro, which includes kernel 3.1.0, and it worked without an issue. So there is probably not a general problem with the 3.0 kernel. We will need the debugging information I mentioned earlier if we are going to figure out what's wrong.
(25 Nov '11, 08:26)
Phil Mitchell
2
Another update: I have tried this on another Fedora 16 machine. This time it wasn't a minimal VM with a mere 2 GB of RAM. It was my home desktop with 4 GB of RAM (which I managed to find time to upgrade thanks to the holidays). I have discovered a bug in how we compute the system's memory size which prevents the admin tools from launching if there is too much memory. There are some checks that are wrong, which may lead SA to believe you have much much less memory than you actually do. This will happen if mem_unit is greater than 1 when returned from sysinfo() and your kernel major version is greater than 2 and the minor version is less than 4. I will create a QTS for this on Tuesday. I am hesitant to guarantee that this is what you're seeing because SA launches for me just fine. However, it is possible that you're hitting the same bug but the numbers in your case end up causing a different error.
(31 Dec '11, 09:30)
Phil Mitchell
|
|
This was probably caused by a bug in the way we compute system memory, as I alluded to in a comment in my other answer. I confirmed similar (but not exactly equivalent) behaviour using Fedora 16 with greater than 4GB of system memory. I recorded this bug as CR 694479 and I have also fixed it. Since you are using version 10.0.1, you should look for a build number of at least 4311. Unfortunately, I don't know when the next 10.0.1 EBF is going to be released for Linux, but you can ask tech support if it's urgent. As a work-around, if it's possible, you could remove some memory from your system. Get it below 4 GB if you can. I know 2 GB works well enough. Phil, Has there been any progress on a "4311+" release for 10.0.1? Elliott
(19 Sep '12, 14:57)
elliottrscott
Replies hidden
10.0.1 went "end of life" on Jan 25th see http://www.sybase.com/detail?id=1091226 so it's most unlikely there will be any later ebf's. I think you'll have to look to upgrading to v 11 or v12 get get the benefit of that bug fix.
(19 Sep '12, 15:54)
Justin Willey
I've been working on a SLES 11 SP2 /OES 11 SP1 system (kernel 3.0.38) and tried the suggestions listed re: reducing physical memory to 2GB with no luck. The SLES 11 SP1 /OES 11 system (kernel 2.6.32) works without issue. FYI.
(19 Sep '12, 17:12)
elliottrscott
Replies hidden
@Justin: Is it known whether v11 or v12 is 100% backward compatible with v10?
(19 Sep '12, 17:19)
elliottrscott
Replies hidden
1
I doubt any system could be guaranteed to be 100% backwards compatible - there are numerous behaviour changes between the versions but they are detailed in the documents - you will need to look at the "behaviour changes" sections for each new version (ie v11.0.0, v 11.0.1, v12.0.0 and v12.0.1) for example here for v12.0.1: http://dcx.sybase.com/index.html#1201/en/sachanges/new1201-sectb-3789082.html, and see what might affect anything you are doing. With simpler implementations many people have found that little or nothing needs to be done, but if you are using a feature that has major changes or has been dropped, then of course you have have a lot to do. Nothing will substitute for proper testing of course :(
(19 Sep '12, 17:55)
Justin Willey
The trick is to get sysinfo() to return mem_unit as 1. This means that all fields within the sysinfo struct (see Unfortunately, I can't promise that the workaround will work at all on any particular distribution (my Fedora/RedHat seemed to work). There are too many factors involved.
(19 Sep '12, 18:12)
Phil Mitchell
1
You might be able to get around this by running as though you have an earlier kernel version. This can be done by using the setarch command: setarch $(arch) --uname-2.6
(19 Sep '12, 20:26)
Tyson Lewis
...although, depending on your support plan, you might dare to try to ask tech support if there is any chance to get a "private build" - I can't tell whether this could have success in any way.
(20 Sep '12, 03:37)
Volker Barth
|
|
anyone has a workaround for this issue in ASA 9? I have the same problem, but, ASA 9. Tanks.. How much memory do you have - Phil's answer suggests that it may work if you have less than 4GB or possibly 2 GB on the server.
(07 Aug '12, 15:46)
Justin Willey
In this machine 6 Gb. But I try in another machine with 2 Gb, and received the same error...
(07 Aug '12, 16:44)
DRauber
1
I cannot speak for my workaround in version 9 and earlier, though I do not think there's any reason why it would not work. Sorry if this gets way too technical, but the key is to get Another workaround is to upgrade to kernel 3.4 or higher (3.5 is the current stable version...wow that moved quickly). Sadly, this may be at least as hard as changing the memory in your system, depending on your Linux distribution. Unfortunately, since ASA 9 hit EOL long before anybody ever dreamed that Linux would reach version 3, there's no way for us to promise any workaround exists, let alone a fix.
(14 Aug '12, 23:21)
Phil Mitchell
Comment Text Removed
|
|
I note that this is still a problem for ASA10 with kernel 3.8 |
How much swap space do you have? Also try setting your max cache size with -ch.