Skip to Content
0

RZ10 Parameters Inquiry

Apr 16 at 06:07 AM

72

avatar image

Hi Experts,

Good Day!

I would like to ask your guidance and inputs in regards in my scenario. Since I have upgraded our SAP System 2years ago, I didnt change these parameters that I set after the DB & Hardware upgrade.

In first and half year, the performance of our SAP system is in good shape. It's rare to encounter no_more_paging and timeout abap dump in ST22.

Currently, we are starting to encounter more timeout abap dump, reports that should be run in a short time takes longer time to be executed and now we encountered no_more_paging to some reports, at first we can run it with a filter of a year but now we can only run it using filter of a month.

I'm finding out the correct path/way to improve the performance and I have search that I need to increase some parameters, but in my view our SAP parameters are all already high and thinking that is it the right thing to increase these parameters? or we need some adjustment in oracle 12c parameters?

I have done my research and posting to clear some of my doubts. Please guide me.

Please see below details for your reference and advise what you think in these SAP paramaters. Thanks you!

OS: Windows 2012 R2

DB: Oracle 12c

RAM: 128GB

SAP Parameters:

sap-param.jpg (33.7 kB)
sap-param2.jpg (23.8 kB)
10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

3 Answers

Isaias Freitas
Apr 16 at 06:24 PM
1

Hello Tan,

We would need more details (like the transaction / report that is affected, maybe performance traces or indication of any database table that is presenting slow access) to be able to assist you.

About the no_more_paging dumps, you could set the parameters "rdisp/PG_MAXFS" and "rdisp/PG_SHM" to 250000.

This will setup SAP to use up to 2GB of SAP Paging memory and all of it will be allocated at the memory (RAM).

Regards,

Isaías

Show 5 Share
10 |10000 characters needed characters left characters exceeded

Hi Isaias,

As for the transactions, we encountered it more on FI tcodes(eg. FBL3N).

I have tried to increase that SAP parameters before and I observed that there's a time it consume more RAM like 30 - 50% consumed is that normal? it looks like not normal to me so I set it like above parameters.

As for performance traces, I follow it up later. Thank you very much.

0

Hello Tan,

The SAP Page Memory has two parts.

  • rdisp/PG_MAXFS configures the maximum size of the SAP Page area.
  • rdisp/PG_SHM configures how much of the SAP Page memory is stored in the main memory (RAM). The difference (PG_MAXFS - PG_SHM) is stored on disk (filesystem).

Setting both to the same value makes the entire SAP Page memory to be stored at the RAM only.

Sine you have enough RAM, that should not be an issue, and keeping the SAP Page memory only at the RAM ensures better performance when the SAP Page memory is used.

Both parameters are defined in "blocks of 8KB". Thus, setting them to 250000 (250 thousand) translates to 2GB.

I do not see how they would use 64GB (50% of the server's memory, which you informed is 128GB).

Regards,

Isaías

1

Hi,

Good Day! Please see below.

I'm thinking to increase the directories for export/import.

If I increase the directory, should I do the same in EXP/IMP SHM?

as for the tables-generic key, it seems than no more freespace im not sure which should I increase in below parameters:

zcsa/table_buffer_area = 30000128 Byte

zcsa/db_max_buftab = 5000

sap-buffer.jpg (81.0 kB)
0

I am not an "SAP performance expert", but it seems that your "generic key" buffer could be increased.

The little I know would be that having swaps is not so bad as long as the hit ratio is very high.

1

Please see below .

sap-memory.jpg (29.8 kB)
sap-query.jpg (29.5 kB)
0
Martin English Apr 16 at 11:02 PM
0

It's been two years ... what has changed in workload and the patterns of your workload ? What has changed in the business (more product liens, more warehouses, more sales etc ?) And don't say "Nothing", it's been two years.

A typical cause of ABAP memory short dumps is that too much data is being read, filling up internal tables beyond the capabilities of the ROLL Area, Shared Memory and paging area. This data is business data... For a simplistic example, the more sales the company does, the more sales records will be read into the internal tables in a sales report. Too many sales and the system runs out of capacity for the internal table.

BTW, if the problem is due to increased business data or workload, this is a good problem - this is generally associated with more work being done by the enterprise which (usually) equates to more revenue if not profit.

hth

Show 1 Share
10 |10000 characters needed characters left characters exceeded

Hi Martin,

Yes, we have more products and sales :) compared last two years since the upgrade we can process faster and more than before and the counterpart is more and fast increase of business data that's why I'm planning to increase it. I have also considered the querying of other customized report are now queued which needs some modification.

Thanks for your ABAP memory short dumps insights.

0
Martin English Apr 17 at 05:12 AM
0

Michael,

Just poking new numbers in the SAP Profile Parameters is unprofessional guesswork and will only cause confusion for you and anyone who has to support the system.

  • Read up on the memory model for your SAP release.
    The ABAP stack memory model changed in the transition from the 72x kernel to the 74x kernel; bear this in mind whenever you read anything that doesn't specify the release of SAP that it applies to. In other words, make sure you understand whether the memory model you're reading about / thinking of actually applies to your system.
  • Understand what the dumps and other symptoms are telling you.
    For example, memory dumps in dialog processes are different to memeory dumps in background processes because the memory model for background WPs is - by default, anyway - different to that for DIA WPs).
    Another example is using ST03 etc to determine whether poor response time or run time is caused by disk access (i..e database response time) or SAP resource contention.
  • Understand the resources that being used (or overused)

Only then can you determine whether the problem can be resolved by juggling resources in the one instance (i.e. Profile Parameters), across instances (i.e, load balancing), if the problem is SAP or Oracle related or if you need more resources.


And the screenshots you've shared are a bit meaningless without any other information. For example, over what period of time have those buffer swaps occurred ? (i.e. 756,000 buffer swaps is probably since you last restarted the system). You're probably more interested in the hour - by - hour or day - by -day changes in these figures.

hth

Show 1 Share
10 |10000 characters needed characters left characters exceeded

Hi Martin,

Thank you for inputs, I will take note on that.

0