on 06-14-2007 1:40 PM
hi sapgurus,
in st02 ,i checked that the hit ratio of the program buffer is 73%
in st06 my current swap size is 34,830,140 30,414,708 25,600,000
the parameter abap/buffersize has certain values
parmeter value 700000
unsubstited standard value-150000
substituted value -150000
comment
#old_value :550000
i want to increase the hit ratio up 99%
what is change i have to do,and which value i have to change and how much.
please it is bit urgent
the windows 64bit machine and the sap release 700
please do help to get result
regards
rahul
I raise it up to 1.000.000 on non-unicode systems and to 1.800.000 on unicode systems.
--
Markus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Based on what logic do you raise it to these values?
You have no idea as to the modules used within the system.
You have no idea as to the number of users on the system.
You have no idea as to the number of app servers.
You have no idea as to how load balancing is happening (SMLG).
You have no idea as to the amount of memory in the server.
Before changing anything we need to understand why we have a hit rate of only 73% in the first place, Then and only then do we take the most appropriate action, which may, or may not be changing the value stated.
This is from a app server thats part of a SAP system for 11,000 users on Z-OS
abap/heap_area_dia 10000000
abap/heaplimit 10000000
abap/heap_area_nondia 10000000
<b>abap/buffersize 900000</b>
rsdb/cua/buffersize 30000
sap/bufdir_entries 9000
zcsa/presentation_buffer_area 120000000
zcsa/table_buffer_area 280000000
zcsa/db_max_buftab 60000
My point is dont just change it, correct the problem! it doesnt need to be the bigest number you can think of or get away with. it needs to be balanced.
My hit ratio is 99.96 and i wager with 1000s more users.
Buffer Hitratio Allocated Free space Dir. size Free directory Swaps
[%] [kB] [kB] [%] Entries Entries [%]
Program 99.96 927,192 24,194 2.69 225,000 206,972 91.99 11,796
The hit ratio is of what has been provided by the buffer rather than by direct DB access. However the buffer could well have been paged out to disk millions of times and still indicate a 99.9% rate.
Ask yourself are you doing new things, are you doing them for the first time since a reboot?
> Based on what logic do you raise it to these values?
Experience on OUR systems
> You have no idea as to the modules used within the
> system.
> You have no idea as to the number of users on the
> system.
> You have no idea as to the number of app servers.
> You have no idea as to how load balancing is
> happening (SMLG).
> You have no idea as to the amount of memory in the
> server.
That's true indeed. He asked for a number and I posted mine, that's pretty all.
> Before changing anything we need to understand why we
> have a hit rate of only 73% in the first place, Then
> and only then do we take the most appropriate action,
> which may, or may not be changing the value stated.
yes - I'm fully with you.
>
> This is from a app server thats part of a SAP system
> for 11,000 users on Z-OS
>
> abap/heap_area_dia 10000000
> abap/heaplimit 10000000
> abap/heap_area_nondia 10000000
> <b>abap/buffersize
> 900000</b>
[...]
900 MB - that is too less for us (Unicode, 12 languages, almost every module in production, SLA of avg. reponse time below 450 ms)
> My point is dont just change it, correct the problem!
> it doesnt need to be the bigest number you can think
> of or get away with. it needs to be balanced.
>
yes - but it's too much and too complicated to explain here, he wanted to have experiences and I gave mine, I didn't assume anything (just the fact, that he's on 64bit).
--
Markus
But the point was and is it is different for all as you agreed. Im sure yours is correct based on your needs. So im saying don't just change to a value that you have no reason to change to or no understanding of why you have it. I have 20 app servers and can balance load based on application or site, or language or x, or y or z.
The low hit rate % wont be increased by adding or changing the number/value, the buffer is paged to disk IF its not big enough. The paging DOES NOT reduce the hit rate as the system % is measured by what comes from the buffer (be it direct memory of swap - being disk) against what comes by direct reads from the DB.
User | Count |
---|---|
101 | |
13 | |
13 | |
11 | |
11 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.