St06/st02- Main memory\

[Link]

[Link]

1. High Paging Rate: OS Paging

Select the Memory from the SNAPSHOT menu

Is there a High Paging Rate? (Paging per hour > 20% of RAM)

 What you want to focus on here is the Page In of RAM (applicable only to windows)
and Page Out of RAM (applicable only to Unix Based OS). Is this value of 20%,

Paging Rate per Hour (Page In / Page Out):

Shows how much data the OS is moving between disk and RAM due to memory
pressure.

Example: Page In = 20% → 20% of reads are coming from disk (Windows), Page Out
= 20% → 20% of writes are going to disk (Unix).

there are a couple other parameters you want to check:

Check the parameters set for the file system in the operating system file
folder, this varies in each system.
refers to is checking how much system memory (RAM) is being reserved for
file system caching / buffers, Take note of the Current Use Percentage. If this
value is 20% or more, the system may have memory issues and at this
point,
Troubleshooting: Check the parameters set for the file system in the
operating system file folder, this varies in each system. If this number is more than
20% of RAM, consider reducing this down to 7-10% of the physical memory.

Check Current Memory Usage (including cache)

free -m

You’ll get output like:

total used free shared buff/cache available

Mem: 32000 25000 800 200 6200 4000

Swap: 2048 50 1998

👉 Here, the buff/cache column shows how much RAM is being used for filesystem
buffers and cache.

If buff/cache is > 20% of total RAM, the system is caching too aggressively.

Target is usually 7–10% of physical memory for SAP systems (to leave room for SAP
instance memory).

For example:

Total RAM = 32 GB

buff/cache = 6.2 GB → ~19% → borderline but OK.

If it were, say, 10 GB → >30% → too high → consider tuning.

short, practical way to resolve it ⬇️

🧭 1️⃣ Confirm the Cache Usage

 free -m

👉 Check the buff/cache column.

If it’s large (e.g. > 20% of total), proceed with tuning.

🧹 2️⃣ Drop Excess Cache (Safe Maintenance Step)

This clears page cache, dentries, and inodes — without killing processes:

sudo sync # flush file system buffers to disk

sudo sysctl -w vm.drop_caches=3

✅ This frees up RAM immediately.

⚠️Do this only during low activity periods (e.g., night or scheduled downtime) to
avoid I/O spikes.

 Whole system:

Is there enough free memory on other systems? This can be check by selecting the
corresponding computer in the system then selecting the Memory, is there free
memory?

Troubleshooting: Redistribute the Wps as discussed in high CPU case

 User specific: Is there an individual user that is consuming too much memory?
This can be found my following the next node on Mode List

Troubleshooting: Analysis of the Mode List

St02->From the Detailed Analysis menu -> SAP Memory -> Mode List, which

can be found at the top of the window, you will see a list of users and their

EM used, Heap, etc. You want to look for the user that is using the most

memory and some questions that could be asked are:

 Is it normal for this user to being consuming this much memory?

If not, look into the user role, changing up the user specifications may
change how it interacts with the system.

 Is it normal for any user to consume this much memory?

 For the current program/transaction/report that they are running, is it
normal for this program/transaction/report to consume this much
memory? If yes, you could do a STAD or ST12 trace on the program to search
for resource allocation for individual steps.

 Extended & Heap Memory:

There are three types of memory under the SAP scope and they are Roll
Memory, Extended Memory, and Heap Memory. Dialog work processes will
use up memory in this order: Roll Memory, Extended Memory, Heap Memory.
Non-Dialog work processes will consume memory in this order: Roll Memory,
Heap Memory, Extended Memory.
It is important to have enough extended memory, if there isn't, SAP Work
Processes would get memory from Heap Area based on SAP allocation
sequence for dialog tasks. Once a Dialog is using Heap Memory, the SAP
Dialog Process goes into Private Mode (PRIV mode), which means it that is
reserved memory and cannot be shared.

Take note of the Current Use Percentage. If this value is 80% or more, the system may

have memory issues and at this point,

Troubleshooting:

User specific: Is there an individual user that is consuming too much memory?

This can be found my following the next node on Mode List

Troubleshooting: Analysis of the Mode List

St02->From the Detailed Analysis menu -> SAP Memory -> Mode List, which

can be found at the top of the window, you will see a list of users and their

EM used, Heap, etc. You want to look for the user that is using the most

memory and some questions that could be asked are:

 Is it normal for this user to being consuming this much memory?

 If not, look into the user role, changing up the user specifications may
change how it interacts with the system.

 Is it normal for any user to consume this much memory?

For the current program/transaction/report that they are running, is it
normal for this program/transaction/report to consume this much
memory? If yes, you could do a STAD or ST12 trace on the program to search
for resource allocation for individual steps.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 SAP Paging:
Page memory> 80%
To resolve high ST02 – Page Area usage (e.g., ~80%+):
 🛠 Increase paging area size (via profile parameter rdisp/PG_MAXFS → restart
required).
 🧹 Optimize ABAP programs to reduce use of large internal tables.
 📊 Check for long-running/background jobs consuming page area and tune or
reschedule them.
 🔍 Monitor users/programs causing high paging via ST02/ST03N and address them.

The SAP Paging Area is a separate memory area made of:

 SAP Paging Buffer (in memory)
 SAP Paging File (on disk, if buffer overflows)
It’s used to store large, temporary data sets generated during ABAP program
execution that are not stored in roll or extended memory. It’s especially used in
classical reporting and inter-program communication.
👉 Specifically, it’s used by certain ABAP statements:
 EXTRACT
 EXPORT TO MEMORY
 IMPORT FROM MEMORY
 CALL TRANSACTION

✅ Yes — here’s a clear real-life scenario that shows how SAP Paging Area can impact
system performance and how to resolve it 👇

📌 Scenario: Large Classical ABAP Report Using EXTRACT

System: SAP ECC (ABAP stack)
Program: A custom Z-report (ZMM_STOCK_ANALYSIS)
Functionality:
 Reads millions of material stock records from MARC/MARD
 Uses EXTRACT statements to collect and process data before generating an ALV list
Symptoms Observed:
 Multiple users running the report simultaneously experience:
o 📈 High SAP Paging usage in ST02 (Page Area near 90–100%)
o 📉 Overall dialog performance slows down
o ❌ Dumps (TSV_TNEW_PAGE_ALLOC_FAILED) for some users
o OS level: High swapping/paging activity
o ST06 shows paging increasing per hour
 In ST02:
o “Page area” shows high utilization (Peak close to max)
o “Swaps” and “Page alloc fails” increasing

📌 Root Cause
 EXTRACT statements temporarily store large internal datasets in the SAP Paging area
(buffer + file).
 The paging buffer in memory fills up, and the system starts using the paging file on
disk, which is slower.
 Multiple users running the same heavy report = simultaneous large EXTRACT
datasets = paging area exhaustion.
 Once exhausted, further users can’t allocate paging memory → system either slows
down heavily or dumps.

🛠 Resolution Steps
1. Short-Term (Immediate Relief):
o 🚫 Restrict parallel execution — temporarily schedule the report in
background one at a time (SM37).
 o 🔄 Clear old sessions holding paging memory (SM04 → end inactive sessions
carefully).
o 🧠 Inform users to rerun reports during low usage hours.
2. Technical Tuning:
o Increase SAP Paging area size
 Adjust profile parameters (RZ10 / RZ11):
 rdisp/PG_MAXFS → max size of paging file (in bytes)
 rdisp/PG_SHM → paging buffer size (in KB)
 Restart system if done in RZ10 (instance parameters).
o Check sizing guidelines: typically 50,000–200,000 KB depending on report
volume.
3. Long-Term Solution:
o 📝 Optimize the ABAP program:
 Avoid unnecessary EXTRACT usage; process data in smaller chunks.
 Use temporary DB tables or internal tables instead of paging for
massive data sets.
o Migrate to modern ABAP (e.g., CDS views) for reporting, reducing reliance on
paging.

📊 Result After Fixing

 ST02 → Page area utilization dropped to normal range (30–50%)
 No more dumps during report execution
 Dialog performance stabilized
 Paging file I/O reduced significantly at OS level

📝 Key Learning
SAP Paging area issues typically affect classical ABAP reports that use EXTRACT or
EXPORT/IMPORT heavily.
When paging memory is overused, it spills to disk, causing performance degradation
system-wide (not just for one user) because of the slower I/O.
Proper paging area sizing + program optimization is essential to prevent
performance impacts.

✅ In short:
Scenario: A large classical report uses too much EXTRACT → fills SAP paging area →
spills to disk → slows down system.
Fix: Increase paging area, restrict heavy jobs, optimize ABAP code to use less paging.
 Good question ✅
When there’s a bottleneck in the SAP Paging area, the impact depends on the
nature and extent of the issue, but here’s how it typically works:

🧠 1. SAP Paging Area is a Shared Resource

 The SAP Paging buffer and SAP Paging file are shared across all users and all work
processes in an application server.

 If the paging area becomes full, slow, or misconfigured, any user or program
executing ABAP statements that rely on this area (e.g., EXTRACT, EXPORT TO
MEMORY, IMPORT FROM MEMORY, CALL TRANSACTION) can be affected.

🌐 2. Impact Scenarios

Scenario A – Localized Impact (Specific Users)

Suppose a single background job or a few users run programs that use heavy paging
operations, for example:

 A BW data extraction process that uses EXTRACT to build internal datasets before
transferring.

 A custom report that performs multiple EXPORT TO MEMORY/IMPORT FROM

MEMORY calls with large datasets.

👉 In this case:

 These specific jobs or users may face ABAP short dumps (PAGING_SHORTDUMP) or
performance degradation, because they consume a large portion of the SAP Paging
area.

 Other users not using paging may continue working normally.

Scenario B – System-Wide Impact

If the overall paging area (buffer + file) is undersized relative to the workload, or if
many users simultaneously run paging-heavy transactions:

 The entire paging buffer may get exhausted.

 Work processes trying to use paging will wait, resulting in dialog response time
degradation, queueing, or short dumps for many users.
 Eventually, multiple users and background jobs across ECC, BW, CRM, etc., can get
impacted because paging is shared.

🛠 3. Resolution / Prevention

Depending on whether it’s a localized or system-wide issue:

 ✅ Tune SAP Paging parameters in RZ10 / RZ11:

o rdisp/PG_MAXFS → Size of the SAP paging file

o rdisp/PG_SHM → Size of the SAP paging buffer

Increase them if consistently hitting the limit (based on monitoring in ST02).

 📝 Optimize ABAP code:

o Avoid unnecessary large EXPORT TO MEMORY or EXTRACT operations.

o Split large data sets into smaller chunks.

 📊 Monitor in ST02 (Tune Summary):

o Look at SAP Paging hit ratio and allocated/free stats.

o Watch for “EMERGENCY PAGING” situations or swap to file frequently.

⚡ Summary Table

Situation Who is impacted

One job/user uses too much paging Mostly that user/job

Paging area undersized globally Multiple users / system-wide degradation

So, to answer your question directly:

👉 If the paging area issue is caused by a specific program, the impact is usually
limited to that user/job.
👉 If the paging area is too small or overloaded by multiple users, it can affect the
entire system's performance.

Would you like me to give a real BW example where paging area caused system
slowdown during data extraction? (It’s a classic scenario.)
 Table buffer Memory
If Table Buffer in ST02 is consuming high memory 👇
✅ Resolution steps (short):
1. Check buffer hit ratio → If good (>95%), no action needed.
2. If low hit ratio + high memory, then:
o Review abap/buffersize (total buffer size) and rsdb/tabl_buffer_size (table
buffer).
o Identify large buffered tables via ST10 → see which tables consume most.
o For huge or rarely used tables, change buffering strategy (e.g., from “full” to
“generic” or deactivate if not needed).
3. If memory pressure exists, reduce table buffer size in RZ10 (→ restart needed).
4. Regularly run SAP_REORG_BUFFER to clean invalid/obsolete entries.
👉 High table buffer usage usually points to too many / too large tables buffered or
oversized buffer settings.