cancel
Showing results for 
Search instead for 
Did you mean: 

RTEMem - No more system pages for ... bytes

Former Member
0 Kudos

Hi all,

I am using MaxDB 7.6.05 Build 9.

And since a day I get such errors:

2009-09-29 10:49:49 7328 ERR 8 RTEMem No more system pages for 319488 bytes available,BYTE_SIZE=4096,DESCRIPTION=posix_memalign,ERRORTEXT=ENOMEM ? out of

2009-09-29 10:49:49 7328 ERR 8 RTEMem memory

2009-09-29 10:49:49 7328 ERR 11 RTEMem + Used 3006803968 bytes from system heap with a limit of system imposed limitation bytes,ALLOC_COUNT=3545,FREE_C

2009-09-29 10:49:49 7328 ERR 11 RTEMem + OUNT=119,ERROR_COUNT=29,BYTES_MAX_USED=3141021696

2009-09-29 10:49:49 7328 ERR 8 RTEMem No more system pages for 319488 bytes available,BYTE_SIZE=4096,DESCRIPTION=posix_memalign,ERRORTEXT=ENOMEM ? out of

2009-09-29 10:49:49 7328 ERR 8 RTEMem memory

2009-09-29 10:49:49 7328 ERR 11 RTEMem + Used 3006803968 bytes from system heap with a limit of system imposed limitation bytes,ALLOC_COUNT=3545,FREE_C

2009-09-29 10:49:49 7328 ERR 11 RTEMem + OUNT=119,ERROR_COUNT=30,BYTES_MAX_USED=3141021696

2009-09-29 10:49:55 7328 ERR 51080 SYSERROR -9407 unexpected error

Anybody how can explain them to me?

I do have a RAM of 4 GB and CACHE_SIZE is set to 170112 that means 1.3 GB.

Thank you.

Best regards

Christian

Accepted Solutions (1)

Accepted Solutions (1)

lbreddemann
Active Contributor
0 Kudos

Hello Christian,

although you've 4 GB in your machine, on a 32-Bit System 4GB is the total adressable memory space.

Since the OS (Linux?) is taking away 1 GB from that, this leaves 3GB for the executable image, all libraries, the tasks/threads/, the stacks and the heaps plus the cache.

Given the error message there were already 2936332 KB used - so obiously there cannot be much more memory be allocated.

Now what could be the reason for the increased memory usage?

Maybe you changed DB parameters like MAXUSERTASKS, MAXDATAVOLUMES etc.?

You may want to check the memory allocation via the system table [MEMORYALLOCATORSTATISTICS|http://maxdb.sap.com/doc/7_6/82/26e4518de62b499478c32aa87e01ba/content.htm] or you check the DBAnalyzer detail log file DBAN_SYS_ALLOCATION.csv.

regards,

Lars

Answers (3)

Answers (3)

Former Member
0 Kudos

Hi Lars,

this is not a helpful answer, this is worth points for a very helpfull answer...

Maybe until later..

Thank you.

Best regards

Christian

Former Member
0 Kudos

Hi Lars,

I did a param_checkall only a ok was the response ... so they should be ok.

The query I am using is no raly that big, it wants to create an aggregat for BI and just the select crashes the DB. The explain shows that only a few page are used for the query (it's a demo system).

Attached you can find the memoryallocatorstatistics it does not tell me a lot ...

ALLOCATORNAME;USEDSIZE;MAXUSEDSIZE;ALLOCATEDSIZE;ALLOCATECOUNT;DEALLOCATECOUNT;FAILEDALLOCATECOUNT;FOUNDERRORCOUNT;BASEALLOCATORNAME;BASEALLOCATECOUNT;BASEDEALLOCATECOUNT SystemHeap;2996367360;3008950272;0;12232;7856;13;0;;0;0 RTEMem_BlockAllocator;1867681792;2744340480;1867681792;119794;119115;0;0;SystemPageCache;119794;119115 RTEMem_Allocator;110518416;113552040;113246208;166502;36109;0;0;RTEMem_BlockAllocator;155;47 SAPDBMem_RawEmergencyAllocator;0;768;262144;11;11;0;0;RTEMem_BlockAllocator;1;0 SystemPageCache;1867857920;2744516608;2743283712;119827;119115;3;0;SystemHeap;12126;0 RTEMem_RteAllocator;429752;5705312;1048576;416344;413462;0;0;RTEMem_BlockAllocator;19;18 MsgList_EmergencyAllocator;0;0;65536;0;0;0;0;;0;0 StackSpace;251179008;251179008;252133376;69;0;0;0;SystemHeap;69;0 LVCMem_BlockAllocator;11542528;11542528;11542528;4;0;0;0;RTEMem_BlockAllocator;4;0 LVCMem_Allocator_001;2136;2136;1048576;1;0;0;0;LVCMem_BlockAllocator;1;0 DataCache;6630960;6630960;6630960;129;0;0;0;RTEMem_Allocator;129;0 DataCache::UKTStorage;504;504;131072;9;0;0;0;RTEMem_BlockAllocator;1;0 DataCache::ControlBlockPool;25042944;25042944;25165824;195648;0;0;0;RTEMem_BlockAllocator;192;0 IOMan_Manager;1256;1392;1256;12;8;0;0;RTEMem_Allocator;12;8 IOMan_Manager;0;524288;0;8;8;0;0;RTEMem_BlockAllocator;8;8 FBM_Manager;7505456;7505616;7505456;83;9;0;0;RTEMem_Allocator;83;9 Converter_Manager;725840;782584;725840;344;268;0;0;RTEMem_Allocator;344;268 Kernel_Administration;0;0;0;0;0;0;0;RTEMem_Allocator;0;0 RTE_RawAllocator;42024;42024;167936;32;0;0;0;SystemHeap;32;0 Join_HashAccessAllocator;0;0;0;0;0;0;0;RTEMem_BlockAllocator;0;0 CommandCacheAllocator;1015824;1015824;16777216;8193;0;0;0;RTEMem_BlockAllocator;1;0 TransContext T002;0;0;0;0;0;0;0;RTEMem_BlockAllocator;0;0 Log_FrameAllocator;3293184;3358720;3293184;5;1;0;0;RTEMem_BlockAllocator;5;1 Log_Volume;45696;45720;45696;699;86;0;0;RTEMem_Allocator;699;86 Log_Writer::WriteLogPages;240;240;240;3;0;0;0;Log_Volume;3;0 Log_Writer::WriteLogPages;240;240;240;3;0;0;0;Log_Volume;3;0 Log_Volume::WriteLogPages;240;240;240;3;0;0;0;Log_Volume;3;0 Log_SaveIterator::PageCollection;0;0;0;0;0;0;0;RTEMem_Allocator;0;0 TransContext T004;3120;3120;8192;3;0;0;0;RTEMem_BlockAllocator;1;0

I had to cut, because of message length...

Best regards

Christian

lbreddemann
Active Contributor
0 Kudos

hmm... sorry but this does not lead to anything here ...

the forum is not suited for this kind of analysis.

Please open a support message on BC-DB-SDB and we'll see what is causing the issues, ok?

regards,

Lars

Former Member
0 Kudos

Hi Lars,

yes, it is a 32Bit Linux system, and I am running Netweaver on it. Some days ago I changed the buffer parameters for PXA, I did no changes in database parameters.

So I did not understand why the database gets such an error now. There were no such errors before.

If only maxdb is running I get a free space of nearly 2 GB (using free comand) or 2.6 GB including the cached value.

So for me there shoud be enought RAM to execute the statement. But the error still occures!

Should I raise or lower the CACHE_SIZE?

Would it help?

Thank you,

best regards

Christian

lbreddemann
Active Contributor
0 Kudos

There could be several reasons for that.

Your database parameter setup could be wrong - use the parameter check to correct it! (there had been memory leaks in the past).

Or, it's just that now certain queries take a lot of memory (heap and stack) that didn't occur before.

Without a look into the mentioned system table I can only guess. So if you want to know, accept the hint I offered and check what's in this table.

regards,

Lars