Hi, sounds you are running into a virtual memory leak. I currently can imagine only one source for such a problem in 7.3: Creating and joining of pthreads. The LINUX pthread library is still not beyond version 0.9 and is dynamically linked (the used version depends on your installed LINUX version...). Both RedHat and IBM are working on a new more posix compliant version, but are developing these together with the kernel support patches needed for POSIX compliance...
Why do i suspect it in your case? SAPDB dynamically creates and joins threads for backup purpose (i.e. during autosave log). The AUTOSAVE is triggered by amount of log written only. So all the modifications you did, never changed the real reason... There are no other 'mmap()' calls which dynamically allocate memory in 7.3. If the mmap() calls will use higher virtual addresses for each thread created, the memory is released during join, but the virtual memory range is increasing until it collides with the 'malloc()' border. In such a case the next malloc() could fail. We had a similar phaenomenon on Tru64 (alias DEC/OSF1), where a single mmap() is enaugh to limit the amount of memory allocatable by malloc() dramatically... I asked Daniel to setup a long running multi user test. If we cannot reproduce your effect here, i try to prepare a test program for your pthread library that simulates what we do with pthreads in SAPDB kernel. But if that locates the problem, i see only a solution in creating the pthreads for backup in advance. This is not a bad idea, but needs a time slot... CU jrg > -----Original Message----- > From: Robert Kr�ger [mailto:krueger@;signal7.de] > Sent: Mittwoch, 6. November 2002 09:28 > To: [EMAIL PROTECTED] > Subject: more on memory-related crashes > > > > Hi, > > it seems to be a never-ending story but I'll keep sharing our > experiences on > this odyssee with you. > > We can now rule out connections being used for a long time as > a reason for > running out of memory. We set a low session timeout and > together with the > reconnect feature of the JDBC driver achieved that > connections were never > older than a few minutes (we monitored that). In addition to > that we adjusted > the database configuration in terms of MAXUSERTASKS and cache > settings in > such a way that memory use was reduced drastically just to > rule out that the > system doesn't have enough memory (the total mem is 2GB, 1GB > of which is used > by the application server and apart from a little system > overhead the rest is > available to sapdb). > > however, it did crash again a few days later (same symptoms, > malloc failing)! > what is strange is how memory use of the sapdb kernel is > displayed by the top > utility. we monitored the following values: > > SIZE (manpage: The size of the task's code plus data plus > stack space, in > kilobytes, is shown here) > > RSS (manpage: The total amount of physical memory used by the > task, in > kilobytes, is shown here. For ELF processes used library > pages are counted > here, for a.out processes not.) > > After a few hours of running RSS stabilized at around 130M. > However SIZE never > stopped growing becoming several times larger than RSS until > the kernel > crashed. Now it is a bit embarrassing as I don't really know > under which > circumstances these values should diverge so much. At all > times the 'free' > command showed enough memory in the system (we did occasional > checks for a > few days and there always were a few hundred M left in adding > free, cache and > buffers). > > Does this give any of you sap kernel developers a clue? Now > just to repeat the > basics of the system, we're using Linux Kernel 2.4. and SAPDB > kernel version > X32|LINUX 7.3.0 Build 025-000-085-912, for details see the archive. > > I hope this is one more piece in the puzzle to solve this mystery. > > Thanks in advance, > > Robert > > > _______________________________________________ > sapdb.general mailing list > [EMAIL PROTECTED] > http://listserv.sap.com/mailman/listinfo/sapdb.general > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
