Skip to Content
Author's profile photo Former Member

How to fix PXA_NO_SHARED_MEMORY Short Dump error in SAP – An error constrained by abap/buffersize settings.

How to fix PXA_NO_SHARED_MEMORY error in SAP – An error constrained by abap/buffersize settings.

When you get the error showing up in your dump stack ST22 of PXA_NO_SHARED_MEMORY in SAP basically this generally means that the setting of your abap/buffersize is set too low for your systems usage. In initial systems it is often set to between 400MB (400,000 KB) and 650MB however sometimes this is not enough and you end up with short dumps like PXA_NO_SHARED_MEMORY.

What exactly the impact this error has on running programs I am not exactly sure – perhaps someone could comment below and I can add it in, however I would assume that any program that short dumps during processing ends up being cancelled.

The purpose of the abap/buffersize setting is to prevent high swapping out to disk, this allows abap applications to run in memory.

SAP recommends a Program buffer size setting of 400 MB for a startup SAP system and can be increased based on the swapping observed in Program Buffer in ST02 transaction till you reach an optimum value based on the observations. It does not make sense to set the program buffer to a higher value without utilizing that part of the memory. You can also lead to other problems such as Operating System paging with too larger of a program buffer in some systems and therefore remove any performance advantages. As far as I can tell a maximum of 1.2Gig should be sufficient for all systems but someone else might have a better idea on this. It is also good to note It is often not possible to set the size of a buffer so that it never becomes full.

Some administrators mention to take note of the “swaps” for this purpose in the program buffer in transaction ST02. A few thousand swaps can be tolerated each day, but if you find more than 10000 swaps per day, you should enlarge the buffer also.

The process for increasing the abap/buffersize setting is as follows:

There are a few things to do before changing your settings.
Check abap buffer size with transaction RZ11


Get your RAM value

ST06 and look for Physical memory available. This will show you the amount of RAM on the server. Ignore the free value as this is not very valid under windows due to the way it works.

Check out some of the details for SAP memory and paging usage

Go to ST02 – Detailed Analysis – Storage (button at the bottom)
In here it will show you 2 of the three key values that add up to the SAP Memory.




You can view the abap buffer size Transaction ST02 (but not modify it)

Goto transaction ST02, Click on Current parameters then view Abap/buffersize

How-To: Steps to Alter ABAP/BufferSize setting

First things first – Take a backup of the directory (And all containing files) that hold your system settings.

These can be found (in windows) in the following path:
So in our case it was:

Goto Transaction RZ10

Sometimes you will have to import roles from all active servers in order to see the config files to adjust abap/buffersize.


Click on the drop down button for Profile.
RZ10 –> Utilities –> Import Profiles –> Of active server
Now you can select the profile you want to edit:


Select one of the system instance profiles (like in red box below) The Start profiles are not changed in this setting change.


Select Extended maintenance then change or display (Depending on if you want to just view the settings or change them)


Scroll down to find the setting abap/buffersize

Edit this setting to increase it – Note this setting is in KB so you will need to write in your settings in the hundreds of thousands to give you MB settings – ie 600000 is the same as 600MB – if you make it one zero less you will cause so many short dumps in your system you will wonder what an earth happened.

If the abap/buffersize setting does not exist in your system you will need to create a new profile if it does not exist in your system profile in rz10


Give it the parameter value that you think it should be (ie more than 400000 is a good start)

Now click the back arrow, save the changes, accept the new instance and check to see if any changes you have made have done any errors (should not be the case).

In Case of Emergency!:

If SAP does not start, backup your changed profile (in the file system \\<sapServer>\sapmnt\<sid>\sys\profile\ )by renaming it to <name>.bak and then copy back the original and see if it starts up alright. (Because you did do a backup as per below didn’t you?  )

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Thomas Michael
      Thomas Michael

      The above recommendations are mostly correct but some of the semantics is wrong. The swaps in ST02 are have nothing to do with disk. For ABAP for example, the swaps are about having to do an ABAP load  from the database and write to the abap buffer. If there's no space in the buffer, abaps not being used are overwritten in buffer by the abap being loaded and that's a swap.

      Tuning the buffers is mostly based on your infrastructure (Memory size and number of CPUs)  and how busy is the system (number of active users, load, number of work processes ). You can set the ABAP buffer larger than SAP recommendations if you need to and have enough resources for that.

      The number of swaps tolerated in ST02 is less important than the Hit Ratios. You want your users Transactions to find in the abaps needed in the buffers of the SAP Application Server Instanc as much as possible. Of course, swaps and hit ratios are correlated.

      You don't need to backup your profile directory every time you want to change the profile parameters in RZ10 since when you activate SAP renames the previous profile_file  and create a new one. You can always switch back to the renamed profile if your latest changes were wrong/bad!