Shared Memory Problems on Linux with 12.5.0.3

[Mike Smith]

Hi All,

I am having a nasty problem with ASE 12.5.0.3 on linux (Suse 8.0). I hope
someone can help

<INFO ABOUT MY SYSTEM>

ase-rba:~ # cat /etc/issue
Welcome to SuSE Linux 8.0 (i386) - Kernel \r (\l).

ase-rba:~ # uname -a
Linux ase-rba 2.4.18-64GB-SMP #1 SMP Wed May 29 15:37:15 UTC 2002 i686
unknown

ase-rba:~ # rpm -qa |grep glibc
glibc-devel-2.2.5-158
glibc-2.2.5-26
glibc-locale-2.2.5-158

ase-rba:~ # free
total used free shared buffers cached
Mem: 4850424 4719176 131248 0 134344 4473604
-/+ buffers/cache: 111228 4739196
Swap: 2000084 12308 1987776

ase-rba:~ # df -Tk
Filesystem Type 1k-blocks Used Available Use% Mounted on
/dev/sda2 ext3 15527908 7461476 7277644 51% /
/dev/sdb1 ext2 17496684 15744056 863836 95% /ase/tempdb
/dev/sdc ext2 70553648 40117392 26852328 60% /ase/log
/dev/sdd ext3 141107320 58820736 75118728 44% /ase/data1
/dev/sde ext3 141107320 67514796 66424668 51% /ase/data2
/dev/sdf ext3 69974736 12909200 53510964 20% /ase/data3
shmfs shm 2425212 0 2425212 0% /dev/shm

ase-rba:~ # cat /proc/sys/kernel/shmmax
3221225472
@@version= Adaptive Server Enterprise/12.5.0.3/EBF 10696 IR/P/Linux
Intel/Linux 2.4.7-10smp i686/rel12503/1915/32-bit/OPT/Thu Jan 23 22:56:39
2003
</INFO>

Memory Related Parameters from my .cfg

max memory = 1046000
lock shared memory = DEFAULT
procedure cache size = 131072
[Named Cache:default data cache]
cache size = 900M
[Named Cache:log_cache]
cache size = 150M
[Named Cache:temp_cache]
cache size = 400M

My problem is the following. I bring the Database server down (after its
been running a day or 2), to change a parameter (or whatver reason), and
then the database server WONT
restart - it fails with the following error:

00:00000:00000:2003/03/01 11:15:56.66 kernel os_create_region:
shmat(98306): Cannot allocate memory
00:00000:00000:2003/03/01 11:15:56.66 kernel kbcreate: couldn't create
kernel region.
00:00000:00000:2003/03/01 11:15:56.66 kernel kistartup: could not create
shared memory

If I check my sshmax value - its fine, an ipcs -a doesnt show anything, (and
yes, I have deleted the .krg file).

The amount that sybase is trying to allocate is well below the 3GB's
specified for the shmmax parameter (about 2.1GB if my calculations serve me
correct)

Below is the output from Top:

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
891 sybase 0 0 1919M 1.9G 1918M S 99.9 40.5 143:44 dataserver
892 sybase 20 0 1919M 1.9G 1918M S 0.0 40.5 0:30 dataserver
27851 sybase 20 0 1919M 1.9G 1918M S 0.0 40.5 0:00 dataserver
915 sybase 20 0 1491M 1.5G 1490M S 0.3 31.4 127:01 dataserver
916 sybase 20 0 1491M 1.5G 1490M S 0.0 31.4 0:26 dataserver
27850 sybase 20 0 1491M 1.5G 1490M S 0.0 31.4 0:00 dataserver

The ONLY way to get the Database server back up is to reboot the
machine.(This was suggested by Sybase). Its almost like the shared memory
becomes polluted, and wont let me re-use it.

This didnt happen in 12.5.0.1 (before my upgrade).

I am running backup server, and monitor server (I am aware that they also
use shared memory to connect to the dataserver)

Any help, or suggestions would be greatly appreciated.

Thanks

Mike

[Mike Smith]

I also used strace to debug, and the following is what I got:

open("/opt/sybase-12.5/ASE/GSS.krg", O_RDWR|O_LARGEFILE) = 7
read(7, "0xfb02f014\n24180\n", 31) = 17
getuid32() = 507
stat64("/opt/sybase-12.5/ASE/GSS.krg", {st_mode=S_IFREG|0600, st_size=17,
...}) = 0
shmget(4211273748, 0, 0) = -1 ENOENT (No such file or
directory)
kill(-24180, SIG_0) = -1 ESRCH (No such process)
unlink("/opt/sybase-12.5/ASE/GSS.krg") = 0
open("/opt/sybase-12.5/ASE/GSS.krg", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE,
0600) = 8
getuid32() = 507
stat64("/opt/sybase-12.5/ASE/GSS.krg", {st_mode=S_IFREG|0600, st_size=0,
...}) = 0
shmget(4211273983, 0, 0) = -1 ENOENT (No such file or
directory)
close(7) = 0
getpid() = 24206
write(8, "0xfb02f0ff\n24206\n", 17) = 17
close(8) = 0
getrlimit(0x7, 0xbfffb55c) = 0
getrlimit(0x7, 0xbfffb554) = 0
shmget(4211273983, 2146304000, IPC_CREAT|IPC_EXCL|0x180|0600) = 1245184
shmat(1245184, 0, 0) = -1 ENOMEM (Cannot allocate memory)
gettimeofday({1046470909, 961200}, NULL) = 0

(I only pasted the relevent section here);

Mike

"Mike Smith" <mi...@is.co.za> wrote in message
news:KSJY79W...@forums.sybase.com...

[Aryeh Silverberg]

Did you shut down Monitor Server before restarting the Database?

[David Owen]

Mike Smith wrote:

Did you see Bernd Dulfer's message on comp.databases.sybase? Didn't see it
here, so thought that I would forward it.

dowen

---------------------------------------------------------8<-------------------
There were a lot of problems in the last time running the latest version
of ASE on Linux with a new version of glibc.

That has ended! (At least on SuSE :-)

I just installed the latest version of glibc (2.2.5-165) from the SuSE
ftp server and ASE 12.5.0.3 runs like a charm.

So there is no need to run old and dangerous versions of glibc
any longer!

You can get the glibc here:

ftp.suse.com/pub/suse/i386/update/8.1/rpm/i686/glibc-2.2.5-165.i686.rpm

rgds

Bernd

--
David Owen Midsomer Consultants Inc. do...@midsomer.org
Maintainer of the Sybase FAQ: http://www.isug.com/Sybase_FAQ

[Mike Smith]

Very interesting.

Now, the one thing I notice about that glibc, is that its an .i686 glibc.

I logged a call with Sybase to query whether ASE 12.5.0.3 was certified
against and i386 or an i686 glibc, and they
came back with the answer that it was certified against an i686 glibc,
hence, any glibc that wasnt i686 would/could break ASE.

Apparently an i686 glibc has some advanced pthread stuff that cannot be done
on i386 - check the url below

ftp://ftp.is.co.za/linux/distributions/suse/8.0/unsorted/glibc-i686/README

The Current GLIBC I am using is an i686 - glibc-2.2.5-26.i686.rpm for Suse
8.0, as that was the only SuSe glibc I could get ASE 12.5.0.3 to come up on

So the Suse issue for 12.5.0.2/3 is that an i686 glibc is required...

I will try this .i686 one for Suse 8.1, and see if it solves my shared
memory issue, although, it appears that the problem is resolved by CLEANLY
taking down the backup server, before shutting down the ASE.(and not
whacking it with a kill -9 after the ASE has been shut down). (I have only
tested twice, but due to the infrequent nature of the problem, I am not
totally convinced that this is the solution - time will tell)

Mike

"David Owen" <do...@midsomer.org> wrote in message
news:LpPOkMB...@forums.sybase.com...

[Mike Smith]

The monitor server shuts itself down as soon as the connection to the ASE is
lost

Mike

"Aryeh Silverberg" <aryehls@yahoo_nospam_.com> wrote in message
news:3E6E3758.7E00CC7A@yahoo_nospam_.com...