Process for optimizing software components for an enterprise resource planning (erp) application sap on multiprocessor servers

Abstract

In a three-tier ERP implementation, multiple servers are interconnected through one or more network infrastructure. Users may observe poor performance due to the complexity and the number of interconnected components in the implementation. Herein is devised a process for tuning the software component by applying tuning techniques to the OS, SAP application and Database Management System software. For each component, the process identifies potential tuning opportunities of various subcomponents. The process is iterated numerous times through all software components while applying the tuning techniques to derive the most optimal performance for the ERP implementation.

1 . In a three-tier client/server SAP Sales and Distribution (SD) implementation where multiple servers are connected with one or more network infrastructure, and wherein a database server operates with a storage system to provide database management services, a process for optimizing software components for performance improvement in Enterprise Resource Planning (ERP) application SAP comprising the steps of:
 (a) evaluating each software component in said network infrastructure;   (b) identifying tuning opportunities for each software component;   (c) applying tuning techniques to each software component to achieve best system performance and avoid poor performance and bottlenecks.   
     
     
         2 . The method of  claim 1  where step (a) includes the steps of:
 (a1) evaluating the Operating System (OS);   (a2) evaluating the SAP application;   (a3) evaluating the Database Management System (DBMS) software.   
     
     
         3 . The method of  claim 1  wherein step (b) includes the steps of:
 (b1) identifying tuning opportunities in said Operating System (OS);   (b2) identifying tuning opportunities in said SAP application;   (b3) identifying tuning opportunities in said DBMS software.   
     
     
         4 . The method of  claim 1  wherein step (c) includes the steps of:
 (c1) applying the said tuning technique to said Operating System (OS);   (c2) applying the said tuning technique to said SAP application;   (c3) applying the said tuning technique to said database server which runs DBMS software.   
     
     
         5 . The method of  claim 3  wherein step (b1) includes the steps of:
 (b1a) selecting the appropriate Operating System (OS);   (b1b) selecting the proper device driver;   (b1c) configuring the OS memory for 32-bit technology;   (b1d) implementing Direct I/O Bridge (DIB) to subpod mapping.   
     
     
         6 . The method of  claim 4  wherein step (c1) includes the steps of:
 (c1a) selecting a version of the OS that supports 32-bit or 64-bit technology;   (c1b) selecting an appropriate device driver for allowing the Operating System to manage hardware devices;   (c1c) managing memory in the 32-bit technology to address memory limitation and to allow said Operating System to extend memory space for user applications and/or to take advantage of memory larger than four gigabytes if physical memory is available;   (c1d) mapping Direct I/O Bridges (DIB) to specific subpods to keep a process and its I/O interrupts together within the same subpod to reduce latency.   
     
     
         7 . The method of  claim 6  wherein step (c1a) includes the step of:
 (c1a-1) selecting an Operating System version that the hardware can support, given the type of processors, number of processors, and the amount of physical memory in each type of server utilized.   
     
     
         8 . The method of  claim 6  wherein step (c1c) includes the steps of:
 (c1c-1) extending addressable memory beyond four gigabytes by utilizing Physical Address Extension (PAE) if said database server has more than four gigabytes of physical memory;   (c1c-2) utilizing /3 GB switch to allow the Operating System to increase the user mode addressable space from 2 GB to 3 GB;   (c1c-3) eliminating the use of /3 GB switch if a database server has more than sixteen gigabytes of physical memory.   
     
     
         9 . The method of  claim 6  wherein step (c1d) includes the steps of:
 (c1d-1) mapping every DIB to its subpod to keep a process and its corresponding I/O interrupts together onto the same subpod if every DIB is filled with at least one Host Bus Adapter (HBA) and if all processors in the database server are evenly utilized.   
     
     
         10 . The method of  claim 4  wherein step (c2) includes the steps of:
 (c2a) configuring SAP memory management;   (c2b) configuring the SAP work process type and amount;   (c2c) setting SAP processor affinity;   (c2d) choosing the appropriate table buffering scheme;   (c2e) choosing the appropriate type of number range buffering techniques.   
     
     
         11 . The method of  claim 10  wherein step (c2a) further includes the steps of:
 (c2a-1) allocating sufficient memory to each SAP process without starving other processes running on the same server;   (c2a-2) reducing the number of SAP instances or SAP work processes if memory is insufficient;   (c2a-3) increasing virtual memory by adding paging files if there is not sufficient memory to allow SAP instances to run;   (c2a-4) using Physical Address Extension (PAE) technology on 32-bit technology to address memory beyond 4 GB if more than 4 GB of physical memory is available;   (c2a-5) allocating sufficient memory to SAP and the other applications when running on the same server.   
     
     
         12 . The method of  claim 10  wherein step (c2b) further includes the steps:
 (c2b-1) configuring the right type of SAP work processes to serve the user workload;   (c2b-2) configuring the right amount of SAP work processes to perform tasks based on the amount of workload and available system resources.   
     
     
         13 . The method of  claim 10  wherein step (c2c) further includes the steps of:
 (c2c-1) grouping SAP work processes of the same instance together, when more than one instance is running, so that these processes can access and share the same memory area;   (c2c-2) assigning SAP work processes of an SAP instance to a processor in the same submodule (subpod), when running on a 32-bit system, to allow work processes from the same instance to access the same shared cache on each subpod to minimize memory latency;   (c2c-3) assigning SAP work processes of an SAP instance to processors in the same processor/memory module, when running on a 64-bit system, to minimize memory latency;   (c2c-4) balancing the SAP work processes so as to spread the workload evenly across all processors.   
     
     
         14 . The method of  claim 10  wherein step (c2d) further includes the steps of:
 (c2d-1) enabling table buffering for frequently read tables with a small amount of updates in order to improve the database access time by storing and accessing data from local memory of an application server instead of going to the database.   
     
     
         15 . The method of  claim 10  wherein step (c2e) further includes the steps of:
 (c2e-1) configuring the number range buffering techniques in an SAP system to improve performance by avoiding lock wait at database level during parallel processing;   (c2e-2) choosing “no buffering” technique for number ranges when it is essential to have no gaps in number allocation of documents and where very low system throughput is needed;   (c2e-3) choosing “main memory” buffering technique for number ranges when it is desirable to have high performance but allowing it to have some gaps in number allocation and the number can be assigned in a non-consecutive sequence;   (c2e-4) choosing “local”, or on instance level buffering only technique, to temporarily store number range on a database table NRIV_LOKAL and have almost gap-free in number allocation, but allowing the drawback that locks still occur within an instance;   (c2e-5) choosing “local”, or on instance level and work process level buffering technique, to temporarily store number range on a database table NRIV_LOKAL and have it almost gap-free in number allocation, as well as eliminating a lock/wait problem.   
     
     
         16 . The method of  claim 4  wherein step (c3) includes the steps of:
 (c3a) configuring SQL Server memory;   (c3b) setting SQL Server threads affinity to run on specific processors;   (c3c) enabling lightweight threads or fibers;   (c3d) configuring the Windows threads;   (c3e) configuring the scheduling priority;   (c3f) configuring parallel queries where appropriate;   (c3g) setting network connection affinity;   (c3h) disabling SQL Server statistic creation and update;   (c3i) disabling SQL Server statistic collection and selecting the appropriate database lock granularity.   
     
     
         17 . The method of  claim 16  wherein step (c3a) further includes the steps of:
 (c3a-1) configuring SQL Server memory specifically for the 32-bit technology to take advantage of the addressable memory space beyond 4 GB;   (c3a-2) using Address Window-ing Extension (AWE) to manipulate memory beyond 4 GB;   (c3a-3) setting PAE at the OS level prior to using AWE;   (c3a-4) making a determination whether to use static or dynamic memory based on the implementation;   (c3a-5) setting the set working set size to reserve physical memory space for said SQL Server.   
     
     
         18 . The method of  claim 16  wherein step (c3b) further includes the step of:
 (c3b-1) setting an affinity mask to specify the processors on which SQL Server threads can run in a multiprocessor environment.   
     
     
         19 . The method of  claim 16  wherein step (c3c) further includes the step of:
 (c3c-1) setting lightweight pooling to reduce context switches by enabling said SQL Server, rather than the OS scheduler, to handle scheduling.   
     
     
         20 . The method of  claim 16  wherein step (c3d) further includes the step of:
 (c3d-1) configuring the maximum number of Windows threads that said SQL Server can use.   
     
     
         21 . The method of  claim 16  wherein step (c3e) further includes the step of:
 (c3e-1) setting priority boost option to specify that said SQL Server runs at a higher OS scheduling priority than it otherwise would.   
     
     
         22 . The method of  claim 16  wherein step (c3f) further includes the step of:
 (c3f-1) setting parallel query to allow queries to be executed in parallel for performance improvement.   
     
     
         23 . The method of  claim 16  wherein step (c3g) further includes the steps of:
 (c3g-1) setting network connection affinity to improve performance through workload balancing and data locality;   (c3g-2) configuring the Virtual Interface Architecture (VIA) network protocol;   (c3g-3) configuring the network threads to run on a specific set of processors.   
     
     
         24 . The method of  claim 16  wherein step (c3h) further includes the steps of:
 (c3h −1 ) reducing intrusive database activities that interfere with overall system performance;   (c3h-2) disabling SQL Server automatic statistics creation and update.   
     
     
         25 . The method of  claim 16  wherein step (c3i) further includes the steps of:
 (c3i-1) reducing intrusive database activities that interfere with overall system performance;   (c3i-2) disabling the SQL Server statistical maintenance function;   (c3i-3) using less intrusive row-level or table-level lock as opposed to page-level lock.