Help needed on memory parameter abap/buffersize

Question

Hello Basis Gurus,
One of the programs in CRM system is failing with dump LOAD_PROGRAM_LOST.
I checked note "1798524 - Runtime error "LOAD_PROGRAM_LOST" when using Segmentation in CRM WEBUI" which seems to be relevant to our situation and found that the parameter 'abap/buffersize' is already on higher side i.e. > 3GB. Please let us know if we need to increase more and if yes then what is the dependency on any other memory parameters?
PS: I always have this question in general on memory parameters due to their sensitive nature (system may not start or adverse impact on other memory parameters). Functional/abap team asks to always increase it but how to check what is the impact and any possible dependency on other memory parameters...!!!
Thanks & Regards,
Kunal.

Answer 1

Hi Kunal,
LOAD_PROGRAM_LOST can have multiple possible causes; a too-small program buffer is just one possibility. At 3 GB, yours does seem like it's probably big enough, but there's no way to tell that from the outside without a lot more information.
Does the same program always fail with this dump, or just sometimes? What else is going on in the system when the dump occurs? Are there transports going into the system around that time? Is it really busy at that time? What happens if you run the program by itself during a quiet time, with nothing else going on? Is this a PRD system? Or perhaps a DEV system?
What sort of statistics do you have on the program buffer when you look at it via ST02? Note that since it's practically impossible to buffer every program, you will inevitably have some swaps in this buffer. That's normal operation. What you might do is look at the history of swaps and get a sense of the average number per day. If you consistently get more than 1000 swaps per day (not 1000 swaps total -- that's not important), as an average, then you might want to consider increasing the size of the buffer. If you only occasionally get spikes higher than this, but typically the number of new swaps each day is less, then you probably don't need to increase the buffer.
The other thing you need to look at is available extended memory. Since the program buffer is quite large, you must make sure there is plenty of available memory for extending it, should you decide to do so. You can get a sense of this from various stats, like the ratio of MaxUse to In Mem for Extended Memory on the same ST02 page, and from OS07N (or ST06). Do you have plenty of free physical memory? Are you getting a lot of paging out? Things like that. If your free physical memory looks good, then you have room to expand.
But again, this may not even be the cause of your dumps.
Bear in mind, if you increase the parameter and have problems restarting the system, you can always fall back by decreasing it again, so other than the planned downtime for the restart you don't lose much by giving it a try. If you increase it and the system starts fine, you will need to keep an eye on those memory use statistics over the following days to ensure all is well, but likely if the system starts ok, then you'll be ok. The days of too-large program buffers causing startup problems were mostly associated with 32-bit systems.
Cheers,
Matt