We help IT Professionals succeed at work.

Sybase reorg running too slow

motioneye
motioneye asked
on
Medium Priority
2,789 Views
Last Modified: 2012-05-12
Some slow performance with our reorg comamnd when it running, when I check the log it says


01server  The 16K memory pool of named cache tempdbcache (cache id 1, cachelet id 2) is configured too small for current demands (state 1). Transaction progress may cease or response time may increase.
01server  The 16K memory pool of named cache tempdbcache (cache id 1, cachelet id 4) is configured too small for current demands (state 1). Transaction progress may cease or response time may increase.
01server  The 16K memory pool of named cache tempdbcache (cache id 1, cachelet id 1) is configured too small for current demands (state 1). Transaction progress may cease or response time may increase.
01server  The 16K memory pool of named cache tempdbcache (cache id 1, cachelet id 3) is configured too small for current demands (state 1). Transaction progress may cease or response time may increase.


I ran sp_helpcache which tell me a results below

1> sp_helpcache
2>
 Cache Name         Config Size   Run Size   Overhead
 ------------------ ------------- ---------- ----------
 default data cache 6000.00 Mb    6000.00 Mb  696.91 Mb
 tempdbcache         500.00 Mb     500.00 Mb   56.83 Mb

(2 rows affected)


Memory Available For      Memory Configured
Named Caches              To Named Caches
--------------------       ----------------
6500.01 Mb                  6500.00 Mb


****** Wil' the value above here is available cache allow to be use ?

------------------ Cache Binding Information: ------------------

Cache Name           Entity Name                Type               Index Name                    Status
----------           -----------                ----               ----------                    ------
tempdbcache          tempdb                     database                                           V
(return status = 0)

1> sp_cacheconfig 'tempdbcache'
2>
 Cache Name   Status   Type     Config Value   Run Value
 ------------ -------- -------- -------------- ------------
 tempdbcache  Active   Mixed       500.00 Mb      500.00 Mb
                          ------------ ------------
                     Total     500.00 Mb    500.00 Mb
==========================================================================
Cache: tempdbcache,   Status: Active,   Type: Mixed
      Config Size: 500.00 Mb,   Run Size: 500.00 Mb
      Config Replacement: strict LRU,   Run Replacement: strict LRU
      Config Partition:            4,   Run Partition:            4
 IO Size  Wash Size     Config Size  Run Size     APF Percent
 -------- ------------- ------------ ------------ -----------
     2 Kb      90112 Kb      0.00 Mb    440.00 Mb     10
     4 Kb       2048 Kb     10.00 Mb     10.00 Mb     10
    16 Kb      10240 Kb     50.00 Mb     50.00 Mb     10
(return status = 0)
1>


Should I know increase this cache ??? will it help to speed up query and reorg performance in my sybase server ?
Comment
Watch Question

Principal Consultant
CERTIFIED EXPERT
Most Valuable Expert 2012
Commented:
The error message is pretty clear - the 16K pool in the tempdb cache is too small. Reorg does work in tempdb, with a lot of sequential reads - hence wanting to use the 16K pool.

Remember any object can only use one cache. As soon as you use multiple caches you reduce the total amount of cache usable by any one object.

So you could increase the size of the tempdb cache but then everything else will have less, plus it still might not be enough.

You might want to test the results of temporarily not using the tempdb cache at all - unbinding tempdb and removing the cache. This would allow reorg to access your full data cache space without guaranteeing everything else suffers. They'll still all be competing for the same space but ASE does a pretty good job of sorting that out.

Author

Commented:
Hi,
Thanks for the explanation  I have tried with increasing Tempdbcache from 500MB to 1000MB  but I notice overhead also now has increased, why the overhead get increased ?


1> sp_helpcache tempdbcache

2>  Cache Name   Config Size   Run Size   Overhead
 ------------ ------------- ---------- ----------
 tempdbcache  1000.00 Mb    1000.00 Mb  113.56 Mb

(1 row affected)
Joe WoodhousePrincipal Consultant
CERTIFIED EXPERT
Most Valuable Expert 2012
Commented:
Overhead is proportional to size of the cache. Note the total overhead does not change if you split into two or more caches, i.e. the overhead of each of your two current data caches is the same as if you were only using one (the same size as the sum of your current two).

By increasing the tempdb cache you will have helped out anything using tempdb but hurt everything else. Keep a close eye on general performance.
alpmoonSybase DBA
CERTIFIED EXPERT
Commented:
I think you shoud run sp_sysmon to see the effectiveness of named cache. Otherwise it is better to unbind tempdb from tempdbcache and then remove tempdbcache as Joe suggested.

Named caches may be useful for certain jobs or daily transactions, but they may be a burden for some other jobs.

You can solve this situation follow two attempts:

1. Solve the error message
You must increase the 16K pool size and not tempdbcache size. Try to decrease the 2K pool size and increase the 16K pool size, like bellow:

 IO Size  Run Size
 -------- -------------
     2 Kb   = 50.00 Mb
     4 Kb   = 10.00 Mb
    16 Kb  = 440.00 Mb

2. Improve performance
After this, you may set the parallelism in your environment, before to run reorg.

sp_configure 'number of worker',500 go
sp_configure 'max parallel degree',4 go
sp_configure 'max scan parallel degree',4 go

Try to do this and notice us.

Joe WoodhousePrincipal Consultant
CERTIFIED EXPERT
Most Valuable Expert 2012

Commented:
I disagree with my learned colleague jlsilva01. Increasing parallelism will increase how much work reorg is trying to do at once... which will increase demands on cache. There is no point do this when there is already not enough space in this tempdb cache.

Author

Commented:
Hi,
I have now increase the tempdbcache to 1000 and allocate 250MB for 16k pool, we will again run the same cronjob during the weekend and monitor it status.
Joe WoodhousePrincipal Consultant
CERTIFIED EXPERT
Most Valuable Expert 2012

Commented:
250 out of 1000 is probably not enough. We can't say exactly what the right number is without knowing how fragmented your table(s) is/are, but 400 or even 500 is probably about right.
Joe,

I said the "question 1" to solve this problem (change amount of 16K pool size). Just this to solve the problem. That's right ?


So, the "question 2" may be used AFTER question 1. It'll help to improve performance with his reorg.
Joe WoodhousePrincipal Consultant
CERTIFIED EXPERT
Most Valuable Expert 2012
Commented:
jlsilva01 - yes, ok, I see what you mean. Upping the pool size (either by increasing it in tempdb_cache, or by not using tempdb_cache anymore) will fix the immediate problem of that error.

I agree when all other bottlenecks have been removed there can sometimes be performance increases for reorg in making sure proper parallelism is enabled, but the whole point of parallelism is to make any one job use more resources. The basic problem here is that the reorg is under-resourced.

But sure, if/when that's fixed, parallelism would be something to try. I find though concurrency tends to work better... i.e. running two reorgs at once, rather than trying to push parallelism for single-threaded one reorg at a time.

Joe, thanks...

"But sure, if/when that's fixed, parallelism would be something to try..."

Let me repeat what I said in my question 2...

"Try to do this and notice us."
Joe WoodhousePrincipal Consultant
CERTIFIED EXPERT
Most Valuable Expert 2012

Commented:
:)