Knowledge Management

Question:
Hi all,
We have 1 DB server and 2 apps servers of 6GB memory each and also each one is configured with 20gb of swap space. However, in ST02, we keep getting very high program swappings (i.e ranging from 6000+ on the first working day to 40000+ at the end of the 5th working day). The value for my abap/buffersize is 600,000kb. Would appreciate if someone could tell us what is wrong and how to go abt rectifying this situation.
Thx in advance.
Answer:
We have 1 DB server and 2 apps servers of 6GB memory each and also each one is configured with 20gb of swap space. However, in ST02, we keep getting very high program swappings (i.e ranging from 6000+ on the first working day to 40000+ at the end of the 5th working day). The value for my abap/buffersize is 600,000kb
This depends on the many factors: OS, SAP Version and whether its 32 or 64 bit, system use -- whether its dev, staging or prod, number of users, # of transports per day and what's the frequency, SAP modules being used, etc). Hope you can share those things to us ...
Regards,
Answer:
Thx Bubu for yr reply. My problem is on my PRD instance. We are running 4.6C on Solaris 8 and Oracle 8.1.7.4 (64bit) and on ave 300 conc. users. We are running FI, CO, MM, PS and IS/U. Our system has gone live for abt 1 yr and this past few weeks there's very low transport to PRD - only 2 to 4 per wk, which we only do after 10pm on the day of req.
I've searched the forum and found that I may need to change some parameters but I'm worried as am not sure how much to change. I don't want to cause downtime as this is our PRD instance and I can't test the changes on my QA system becos of diff h/w config.
Rgds,
iad
Answer:
Hi,
Please post the values of all Buffer and its Swaps ..RED onces, then we can take a look and can suggest.
Tks
AA
Answer:
Hi, Thx for the reply.
Ok here goes, the values below are from Apps1 - Program buffers
Date & time of snapshot: 08.07.2003 10:31:22 Startup: 05.07.2003 22:57:18
Efficiency Hitratio % 99.68
Hits 16,294,040
Requests 16,345,698
DB access quality % 99.64
DB accesses 80,505
DB accesses saved 22,192,678
Reorgs 0
Size Allocated kB 619,868
Available kB 600,000
Used kB 578,935
Free kB 21,065
Gaps kB 21,065
Directory entries Available 150,000
Used 11,357
Free 138,643
Swaps Objects swapped 14,248
Frames swapped 0
Resets Total 0
And these are from Apps2
Date & time of snapshot: 08.07.2003 10:30:07 Startup: 05.07.2003 22:57:50
Efficiency Hitratio % 99.55
Hits 8,818,453
Requests 8,858,640
DB access quality % 99.46
DB accesses 65,892
DB accesses saved 12,045,769
Reorgs 0
Size Allocated kB 619,575
Available kB 600,000
Used kB 575,295
Free kB 24,705
Gaps kB 24,705
Directory entries Available 150,000
Used 11,180
Free 138,820
Swaps Objects swapped 9,479
Frames swapped 0
Resets Total 0
FYI, also there was no transports done during the startup period.
Rgds,
iad
Answer:
What is your user type profile? ie: 50% FI/CO - 40% MM/PS - 10% IS/U ?
Depending on your answer to the above, you could get your FI/CO users to logon to one server, your MM/PS users to the other and load balance your IS/U users.
Answer:
Hi Machiavellian,
Thx for yr reply. Our user distribution on ave. is as follows i.e. 30% FI/CO, 30% MM/PS, 25% IS/U and 15% across FI/CO, MM & PS. However, the heaviest load is from IS/U whereby it's on ave. is 50% while the others are only abt 10% each.
Awaiting yr reponse....
Rgds.
Answer:
Some things which may hel.
1 - can you do a quick stopsap r3 then startsap r3 on your apps sometime during the night as this will remove gaps in the buffer at the end of each day although looking at your stats above doesnt really look like a fragmentation problem but were the stats taken in terms of the last startup? I am assuming you have 1 sap instance on each sap app server, you could either, forget load balancing and force users of the different modules onto different apps via the logon pad. i.e fi/co point to on box and the rest the other, or you could increase the number of app instances on each box to 2 and have more seperation and a bit of load balancing. i.e we do this and it keeps the buffers quite clean despite them being smaller but user education is needed so that they know what to loginto via the logon pad.
Answer:
In 40B we do this,
we use a parameter abap/buffersize_part1 along with parameter abap/buffersize and define it to be 66% of abap/buffersize so what happens is that SAP uses the part1 parameter for bigger programs and uses the left over portion i.e. (abap/buffersize - abap/buffersize_part1) for smaller programs ...this results into less amount of swaps...
I don't know whether this parameter is valid in later versions
hope that helps
cryptosid
Answer:
Thx guys for yr replies.
were the stats taken in terms of the last startup?
We do offline backup every Sat. evening and those stats were taken on tue morning.
you could increase the number of app instances on each box to 2.
How do you do this? And would this help in terms of performance as it is still the same h/w config.
we use a parameter abap/buffersize_part1
Unfortunately this param is not available in 4.6C
Rgds,
iad
Answer:
Some things which may hel.
1 - can you do a quick stopsap r3 then startsap r3 on your apps sometime during the night as this will remove gaps in the buffer at the end of each day although looking at your stats above doesnt really look like a fragmentation problem but were the stats taken in terms of the last startup? I am assuming you have 1 sap instance on each sap app server, you could either, forget load balancing and force users of the different modules onto different apps via the logon pad. i.e fi/co point to on box and the rest the other, or you could increase the number of app instances on each box to 2 and have more seperation and a bit of load balancing. i.e we do this and it keeps the buffers quite clean despite them being smaller but user education is needed so that they know what to loginto via the logon pad.
1) restarting the instances will lose the speed of reading from the buffers.
2)yup, about delegating specific users to each instance is a better option then load balancing... (from the perspective and understanding of my knowledge)