Hi, some more questions and observations:
does the problem suspected by you only occur when an autosave log file is written? If so it doesn't seem to be our problem (if I understood your explanations correctly). let me explain. currently on our production system top displays SIZE = 602M and RSS = 357 which is an indication for such a virtual memory leak (isn't that what you meant?). The database has been up for about 36 hours and no log has been autosaved during this period so the leak must be somewhere else or did I misinterprete something? Anything we can do to track this down? What do you think? 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
