Excessive slowness in sapxpg tool, after SUSE updates.

This document (000021024) is provided subject to the disclaimer at the end of this document.


SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12


Some mutual SAP and SUSE customers have come to SUSE Support saying that after recent updates, the "sapxpg" tool takes a long time to finish simple operations such as batches of renaming, deleting, or moving files.

SUSE Support has investigated these complaints and they appear to be caused by the way sapxpg (or a parent program which calls it) is coded.  After every individual operation (such as deleting one file) the code calls "close" on nearly the entire range of possible file descriptors, one by one.  On a typical Linux system, this might not cause a noticeable impact, because often the limit on the number of file descriptors (the "nofile" value) is low, such as 1024.  However, SAP systems typically have higher "nofile" settings, at SAP's recommendation.

SAP updates it recommendations from time to time, and in SAP Note 1771258 v6, they recommended raising various nofile setting for their components to 1048576.  SUSE adopted that recommendation into our "sapconf" package in mid 2022.  The previous limit in sapconf was 65536.  After a system received the mid-2022 update to the sapconf package, the sapxpg tool now must cycle through "close" calls on 1 million+ invalid file descriptors after every operation.  This is causing delays, especially during large batches of work.


To SUSE's understanding, the root cause needs to be addressed within sapxpg code, which needs to adopt a more efficient practice.

But to offer a possible workaround:

If the launching of sapxpg (or its parent program) can be controlled, it may be possible to force it to launch with a lower limit for "nofile".  SUSE has had trouble getting timely feedback from SAP on this point, so the exact best method is unknown.  Hypothetically, if the command to be launched is "sapxpg" then possibly it can be launched as:

prlimit --nofile=65536 sapxpg

Or if a SAP utility is already up and you can identify it's PID, then you could change its nofile value on the fly with (assuming PID is 1234):

prlimit --nofile=65536 --pid 1234

You can learn the current limit of a process with:
prlimit --nofile --pid 1234

However, those examples are purely hypothetical.  These utilities come from SAP, so their precise usage and best practices may require input form SAP Support.

This TID is not necessarily expected to offer a final solution to customers.  It is mainly an initial discussion of the issue being encountered, and encouragement to pursue a final best solution with SAP.  If the ideal solution is identified, it can be included in this TID if reported to:    tidfeedback[at]suse.com


This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:000021024
  • Creation Date: 27-Mar-2023
  • Modified Date:27-Mar-2023
    • SUSE Linux Enterprise Server
    • SUSE Linux Enterprise Server for SAP Applications

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

Join Our Community

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

SUSE Customer Support Quick Reference Guide SUSE Technical Support Handbook Update Advisories
Support FAQ

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.

Go to Customer Center