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:
/opt/sqlanywhere10/bin64/dbsrv10 -n my_serv /path/to/database.db

This is the output I get:
Running Linux 3.0-ARCH #1 SMP PREEMPT
Wed Oct 19 10:27:51 CEST 2011 on X86_64
Server built for X86_64 processor architecture
Not enough memory

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.

asked 31 Oct '11, 07:46

Sharagoz's gravatar image

Sharagoz
61126
accept rate: 0%

edited 14 Aug '12, 08:44

Volker%20Barth's gravatar image

Volker Barth
31.5k318461676

How much swap space do you have? Also try setting your max cache size with -ch.

(31 Oct '11, 08:37) John Smirnios

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 ulimit settings for data segment size, max memory size, stack size, virtual memory, ... anything related to memory.

I cannot enumerate all possible reasons for this error.

If you run the server through strace, you may be able to see the allocation that fails (unless it's a regular malloc, which I doubt):

strace -o trace.out /opt/sqlanywhere10/bin64/dbsrv10 -n my_serv /path/to/database.db

Look in the resulting trace.out file for suspicious error codes (such as ENOMEM) just before the error message.

If that doesn't show you anything useful, I would recommend that you work with technical support to send us some more diagnostic information.

permanent link

answered 31 Oct '11, 08:37

Phil%20Mitchell's gravatar image

Phil Mitchell
1.9k1831
accept rate: 27%

edited 31 Oct '11, 08:43

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.

permanent link

answered 09 Jan '12, 10:58

Phil%20Mitchell's gravatar image

Phil Mitchell
1.9k1831
accept rate: 27%

edited 17 Jan '12, 11:46

Jeff%20Albion's gravatar image

Jeff Albion
10.7k171174

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 man sysinfo) must be small enough that no scale factor needs to be applied. So if you have too much swap space, this could happen as well.

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

http://search.sybase.com/kbx/solvedcases?id_number=11742079

(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
showing 3 of 8 show all flat view

anyone has a workaround for this issue in ASA 9?

I have the same problem, but, ASA 9.

Tanks..

permanent link

answered 07 Aug '12, 15:19

DRauber's gravatar image

DRauber
21181219
accept rate: 0%

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 sysinfo() to return a 1 in the mem_unit field. I'm not certain if this depends on whether you are using a 32-bit or 64-bit server (or kernel). It may also depend on how much swap space you have, as there is only one mem_unit field for all types of memory, so if any one of them exceeds 4 GB (or 2 GB?), then a multiplier will be required. Check the man page for sysinfo for more information.

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

permanent link

answered 18 Dec '13, 10:31

alexlake's gravatar image

alexlake
16113
accept rate: 0%

edited 18 Dec '13, 10:31

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×114
×61

question asked: 31 Oct '11, 07:46

question was seen: 3,804 times

last updated: 18 Dec '13, 10:31