Thanks for the explanation. It would be great to be able to verify that. Please contact me as soon as you have something we can test. Just knowing the cause would help because we have invested so much manpower in trial and error (hardware, system-upgarde, testing, testing, testing) and would be happy to be able to finally stop that and wait for a fix (while restarting the db from time to time).
Best regards, Robert On Wednesday 06 November 2002 14:57, Mensing, Joerg wrote: > 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 > _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
