Help needed on memory parameter abap/buffersize

[former_member705654]

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.

[Reagan · Accepted solution]

>>One of the programs in CRM system is failing with dump LOAD_PROGRAM_LOST.<<

As you have multiple app servers have you tried running the same transaction on another app server or CI node and see if you get the same error? if yes, are you observing this issue across all nodes or specifically on one node? If yes then the issue is global and if not I would review the configuration of the app server with the one where I didn't observe the issue.

>>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?<<

You can increase the program buffer parameter if you have memory on the machine and if you believe that will fix the issue but what is the point if you don't know what the real reason behind the issue is? What system is this? 3 GB is quite a lot of memory I would say based on what I have seen until now. For development systems (OK, test systems as well) the program buffer with huge allocations is understandable. For production systems with huge program buffers, I would dig deep in to understand why such an allocation is required.

>>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...!!!<<

No point in increasing memory parameters when you don't have sufficient memory in the box.

Always create a test profile (copy the instance profile from the OS level) and modify the parameters in the test profile. Run sappfpar against the test profile and check for errors before you implement them in the real profile.

RB

[Former Member]

Hello Kunal,

Firstly, I tilt my hat towards Matt. A well thought out and well formulated reply.

I think you're almost there with your analysis as I'd be leaning towards "Option 2" of the note you have looked at. SQ02 (the Basis Admin widow maker transaction). 3GB abap buffer doesn't jump out as being insufficient.

I've had situations similar to yours on ERP systems and pretty much had to go down the "option 2" road as well. Usual caveat of trying this out on your QA/Test system first.

As for memory parameters in general, schedule a "Health Check" in SolMan for your CRM system.

The usual suspects from this report will be:

ntab entries/buffer.

ftab buffer

Table Buffer

exp/imp buffer

presentation buffer

Kindest Regards,

Amerjit

[Matt_Fraser]

SQ02 the "Basis Admin widow maker" transaction. Lol!

[former_member705654]

Hi Matt/Amerjit,

Thanks a lot for your valuable suggestions. I did analysis using ST02 and found that one app server out of 3 was having lot of swaps (> 1000) per day. Hence, suggested to increase the memory parameter in the system (all app servers).

Surprisingly most of the times the job was running on the same app server. I checked the SMLG, RZ12, SM61 and all the servers are added there. Not sure why this job is only running on this server. No target server selected also in the job. Any suggestions?

PS: I checked SQ02 but this seems to be tcode for functional guys...Could not find anything there...

Thanks & Regards,

Kunal.

[Matt_Fraser]

Hmm, that makes me wonder if you're having buffer synchronization problems between the app servers, then. LOAD_PROGRAM_LOST can be caused when the version of a program in the app server's program buffer doesn't match the version in the data dictionary, in the database, or when the buffer is sync'ing or resetting while the program is in use.

[former_member705654]

Hi Matt,

Yes I think this could be the issue. How to resolve this or troubleshoot further?

Thanks & Regards,

Kunal.

[former_member705654]

To add: I saw that value of parameter rdisp/bufrefmode is sendon and not sendon,exeauto. Shouldnt it be set to this?

**************************************************************************

Parameter

rdisp/bufrefmode

Short text

Buffer Refresh Mode

Parameter Description

The default setting sendon, exeauto means that the buffer synchronization is activated.

• sendon means that changes to buffered objects are logged in the table DDLOG
• exeauto means that the local buffer is brought up to the newest state by cyclical processing of the new DDLOG records.
• sendoff,exeoff deactivates the buffer synchronization.

*************************************************************************************

[Matt_Fraser]

sendon,exeauto is the default. I'm not sure what happens if you set the parameter specifically to sendon and leave out the exeauto. It probably still defaults to that. However, if in doubt, set the parameter specifically.

[Former Member]

Hi Kunal,

rdisp/bufrefmode should be set in the DEFAULT.PFL and should be sendon,exeauto when you have application servers (as you have remarked).

Please check your profiles to ensure that the value is set only in the DEFAULT.PFL. Remove it from the instance profiles if it is there.

Kind Regards,

Amerjit

[Former Member]

hehehe ....

Guns and Alcohol

ABAP Query and End Users.

I rest my case m'lud.

[Former Member]

Time overlap ... Matt had already replied ....

Special offer just for today .... two replies for the price of one .....

mea culpa.

[Matt_Fraser]

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

[former_member705654]

Thanks Matt for guidance and lot of useful information. I will check in this direction.

[former_member185954]

Wow, that's quite a bit to ponder over, I think this dump is only observed typically when you import a transport or a patch while the program is in use.

And I have seen live occurrences in our production system whenever a transport goes in modifying central function modules.

In our case we have noticed that a certain user started sales order screen VAXX, while he/she was feeding data (screen being idle). A transport went in modifying a function module. At the next dialog step when the function module was access, he/she got an ABAP dump saying LOAD_PROGRAM_LOST.

if you were importing transports during the maintenance hour, you forget about the user , if not the user might turn up at your desk with a shotgun

Kunal,

Observe the ST22 dump timings and program name etc (from call stack provided in st22 dump) and compare it with transport import history, if you find a related program/function module being changed, you have isolated the issue.

if you have recent versions of SAP, the sendon,exeauto has correct default values and application server sync shouldn't cause this, unless you(or your predecessors)  have intentionally set it.

Regards,

Siddhesh