memory pool too small for current demands

PDreyer

unread,

Jun 12, 2006, 5:03:01 PM6/12/06

to

Any suggestions on how to handle this warning?

07:00000:00263:2006/06/10 03:22:02.16 server The 4K memory
pool of named cache default data cache (cache id 0, cachelet
id 1) is configured too small for current demands (state 2).
Transaction progress may cease or response time may
increase.
07:00000:00075:2006/06/10 06:50:47.82 server The 32K memory
pool of named cache default data cache (cache id 0, cachelet
id 1) is configured too small for current demands (state 2).
Transaction progress may cease or response time may
increase.

Here are the current cache config

Cache Name Status Type Config
Value Run Value
------------------------------ --------- --------
------------ ------------
default data cache Active Default 13000.00
Mb 13000.00 Mb

------------ ------------
Total 13000.0
Mb 13000.0 Mb
==========================================================================
Cache: default data cache, Status: Active, Type: Default
Config Size: 13000.00 Mb, Run Size: 13000.00 Mb
Config Replacement: relaxed LRU, Run Replacement:
relaxed LRU
Config Partition: 1, Run Partition:
1
IO Size Wash Size Config Size Run Size APF Percent
-------- --------- ------------ ------------ -----------
4 Kb 921600 Kb 0.00 Mb 9000.00 Mb 10
32 Kb 921600 Kb 4000.00 Mb 4000.00 Mb 10
(return status = 0)

Version: ASE 12.5.3 on Solaris 8
Sun Fire 880
Memory size: 16384 Megabytes

Mark A. Parsons

unread,

Jun 12, 2006, 5:13:15 PM6/12/06

to

Found the following solved case at sybase.com:

=======================================
Case Number: 10981944
Open Date: 2003-11-10 14:35:22.0
Version/EBF: 1250/8942

Product: Adaptive Server Enterprise
OS: Solaris
Platform: Sun Solaris SPARC

Case Description

Getting message "Server 2k memory pool of name cache default data cache is
configured too small for current demands." Server is runniing very slow
during heavy utilization.

Key Words: cache configuration parameter memory pools

Tip or Workaround

The problem is not actually the size allocated for your default data cache,
but the way it is set up. I noticed that you are using 'relaxed LRU', this
method of reading cached pages allows for better performance in certain
servers, but is also problematic with its error handling. It may be that
you actually have an excess of dirty pages, and therefore the errors occur.

This replacement policy for LRU is not recommended for use with the default
data cache.

Resolution

Changed the LRU replacement policy for default data cache, use:
sp_cacheconfig 'default data cache',strict

Resolutions: cache configuration

Other Sources Related to Issue
TechNote
10981944
=======================================

Sherlock, Kevin

unread,

Jun 12, 2006, 5:17:23 PM6/12/06

to

Most likely caused by the fact that you are using "Relaxed LRU" cache policy for
"default data cache" which I believe isn't really a good thing to do. If you
have some tables/io that would benefit from Relaxed LRU policy, create a named
cache with that replacement policy and bind the tables/indexes to that named
cache. Leave "default data cache" as "strict LRU replacement".

I think there are a fair number of bugs related to Relaxed LRU policy as well.
What ESD level are you running?

<PDreyer> wrote in message news:448dd5af.69f...@sybase.com...

PDreyer

unread,

Jun 12, 2006, 8:29:14 PM6/12/06

to

Thank you, I'll change it to strict a few hours from now.

I am on
Adaptive Server Enterprise/12.5.3/EBF 13055
ESD#5/P/Sun_svr4/OS 5.8/ase1253/1939/64-bit/FBO/Tue Dec 6
09:13:20 2005

> Found the following solved case at sybase.com:
>
> =======================================
> Case Number: 10981944

-- snip, snip --