cancel
Showing results for 
Search instead for 
Did you mean: 

pool is configured too small for current demands

PeterSabry84
Explorer
0 Kudos

Dear experts,

We are facing the following error, accompanied by slow performance and full disk utilization:

06:00000:00620:2014/05/08 00:55:56.99 server  The 8K memory pool of named cache default data cache (cache id 0, cachelet id 1) is configured too small for current demands (state 1). Transaction progress may cease or response time may increase.

Case History:

This error was noticed with the standard 2K pool

We configured another 8K Pool, same error appeared for the 8K pool

Configured additional 16K pool, same error faced for the 16K pool

Removed the 16K pool

Increased the 8K pool

Error still appear for the 8K pool now and performance still very slow

No other programs are running on server except Sybase ASE

Disk utilization is monitored using "glance"

ASE version: 12.5.3

OS:     HP-UX 11.23

sp_cacheconfig now:

Cache Name                     Status    Type     Config Value Run Value   

----------                     ------    ----     ------------ ---------   

default data cache             Active    Default   15360.00 Mb  15360.00 Mb

IO Size       Wash Size    Config Size       Run Size          APF Percent

-------           ---------           -----------            --------               -----------

    2 Kb      245760 Kb     0.00 Mb            13312.00 Mb     10     

    8 Kb      245760 Kb     2048.00 Mb       2048.00 Mb      10     

PeterSabry84
Explorer
0 Kudos

Thanks Mark for the quick response.

I can confirm that the "default data cache" is not partitioned and it uses Strict LRU policy.

I meant by disk utilization that the "Hard Disk" is 100% busy from operating system point of view.

I attached the sp_sysmon output at the time of the problem

Mark_A_Parsons
Active Participant
0 Kudos

The errorlog entry in the OP shows the message showing up at just before 01:00 am this morning (2014/05/08 00:55:56.99), while the sp_sysmon appears to be from a 5min interval around noon today (May 08, 2014 11:57:01 - 12:02:01).  Were you seeing the same performance issues @ noon as @ 01:00?

Good number of APFs being denied (639.5/sec) due to hitting up against APF limits.  Most (92%) of large IO pages are being used.  I'd suggest bumping up the 8K pool by 2-3GB to see how much that helps; if you continue to see APFs being denied due to APF limits then you may also want to bump up the APF % on the 8K pool.

Transaction activity appears to be geared heavily towards inserts to APL heap tables (#temp tables perhaps?), with relatively little activity of any other sort (DOL insert/update/delete, APL delete/udpate).  So that would mean a lot of your cache activity is in support of read operations, which in turn are requiring a lot of disk IOs.

As for your disk activity ... tempdb 45K writes, auditing 6K writes, phoenix 80K reads, mosaic 154K reads, etc.

If most of your tempdb activity is in support of smallish #temp tables that have a short life span you could look at creating a separate cache for tempdb(s), bind the tempdb(s) to the cache, and disable the HK in the cache.  This could help eliminate a large chunk of the tempdb-related disk writes, which in turn should help reduce the load on your disk subsystem.

If the 'audit' disks are being used by the sybsecurity database ... have you considered pulling back on the amount of auditing, perhaps even disabling auditing, for a period of time to see if this helps improve performance? [High volumes of auditing can definitely degrade performance if simply because you're serializing all of your auditing activity against a single heap table in sybsecurity; also, reducing the volume of disk writes would reduce the load on your disk subsystem.]

As for the rest of the disk I/Os (reads) ... I'd want to find out what queries are requiring all of these disk reads (phoenix/mosaic/tradefin devices) and spend some effort on analyzing the queries to see if there's some room for improvement/tuning.

------------------

Adjusting cache/pool sizes and creating a tempdb cache are attempts at addressing your performance symptoms.

Spending some time analyzing the queries (requiring all the disk IOs) is an attempt at addressing the root cause of your performance symptoms.

PeterSabry84
Explorer
0 Kudos

Yes, the same problem exists almost all that time.

Now it is planned to increase the 8K pool to 3G and see the results, meanwhile, other alternatives you suggested will be analyzed.

Thanks for help, will keep you updated.

Accepted Solutions (0)

Answers (2)

Answers (2)

former_member207908
Participant
0 Kudos

Dear Peter,

I have come across similar error (The 128K memory pool of named cache default data cache  is configured too small for current demands... )

Acc to SAP the root cause of the error is:

97% Prefetch data Size is bigger than 128k pool size, So it can't use the Large I/Os  pool.
This cause the message in errorlog  "server  The 128K memory pool of named cache default data cache ...."

Suggestion was given to increase the "128 K" memory pool size to 5GB

sp_poolconfig "default data cache", "5G", "128K"
go

HTH

Rajesh

PeterSabry84
Explorer
0 Kudos

Dear Rajesh,

Thanks for the reply, actually I had to enlarge the large pool too, but also, we had other operating system issues that the O.S. support had to solve.

BR | Peter

former_member207908
Participant
0 Kudos

Dear Peter,

Could you please explain the OS issues you had and it would be great if you can brief the action taken by the OS support team.

Regards,

Rajesh

PeterSabry84
Explorer
0 Kudos

Dear Rajesh,

There was an operating system kernel parameter that was recommended to be changed by the O.S. support, when changed, performance got enhanced.

O.S. Unix [HP-UX]

Parameter:     hires_timeout_enable=1

Actually I'm not UNIX admin and I don't know exactly what this parameter does, but it enhanced the overall performance of the nightly batch that was taking much time.

BR | Peter

former_member182259
Contributor
0 Kudos

Peter -

hires_timeout_enable enables high resolution timers within HPUX.   Without this, certain OS functions that timeout have a minimum of 10 milliseconds (a pretty long time - think disk IO).    With this enabled, those same OS timeouts can be woken up much quicker (e.g. 2 ms)

PeterSabry84
Explorer
0 Kudos

Thanks Jeff for the info.

Former Member
0 Kudos

Hi Peter, Mark,

I'm fairly new to ASE. But we are seeing a very similar log. The output of sp_cacheconfig is below:

Cache Name         Status   Type     Config Value   Run Value   

------------------ -------- -------- -------------- ------------

default data cache Active   Default       8.00 Mb        8.00 Mb

(1 row affected)

                                   ------------ ------------

                            Total       8.00 Mb      8.00 Mb

==========================================================================

Cache: default data cache,   Status: Active,   Type: Default

      Config Size: 8.00 Mb,   Run Size: 8.00 Mb

      Config Replacement: strict LRU,   Run Replacement: strict LRU

      Config Partition:            1,   Run Partition:            1

IO Size  Wash Size     Config Size  Run Size     APF Percent

-------- ------------- ------------ ------------ -----------

    16 Kb       1632 Kb      8.00 Mb      8.00 Mb     10     

(return status = 0)

LRU is already set to strict.

What was the problem and how did you finally solve it?

Regards,

Roy