- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- formula for SAP system work processes
Operating System - HP-UX
1819814
Members
3534
Online
109607
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-25-2004 06:15 AM
тАО06-25-2004 06:15 AM
Hi experts
I have hp-ux 11i server with SAP 3.0f /SAP 3.1I_com kernel and would like to get the formula that will count the number of work processes need to be on the system.
Any body have the formula related to this syste.
I would appreciate any help as it was very difficult to get those information from SAP Service marketplace.
Regards,
Ashraf
I have hp-ux 11i server with SAP 3.0f /SAP 3.1I_com kernel and would like to get the formula that will count the number of work processes need to be on the system.
Any body have the formula related to this syste.
I would appreciate any help as it was very difficult to get those information from SAP Service marketplace.
Regards,
Ashraf
ASHRAFM
Solved! Go to Solution.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-26-2004 07:49 PM
тАО06-26-2004 07:49 PM
Re: formula for SAP system work processes
There is not formula. However following may help.
R/3 Application Services: Each application server has dispatcher as well as work processes (DVEBS). The R/3 system provides two additional services for internal and external communication.
The message server (MS or M) communicates between the distributed dispatchers within R/3 system.
The gateway server (GW or G) for R/2 and external application systems.
Dialog (D): Every dispatcher requires at least 2 dialog WP.
Spool (S): At least 1 for each R/3 system (more than 1 allowed for each dispatcher).
Update (V): At least 1 for each R/3 system (more than 1 allowed for each dispatcher).
Background processing (B): At least 2 for each R/3 system (more than 1 allowed for each dispatcher).
Enqueue (E): Only one is needed for each R/3 system.
sks
R/3 Application Services: Each application server has dispatcher as well as work processes (DVEBS). The R/3 system provides two additional services for internal and external communication.
The message server (MS or M) communicates between the distributed dispatchers within R/3 system.
The gateway server (GW or G) for R/2 and external application systems.
Dialog (D): Every dispatcher requires at least 2 dialog WP.
Spool (S): At least 1 for each R/3 system (more than 1 allowed for each dispatcher).
Update (V): At least 1 for each R/3 system (more than 1 allowed for each dispatcher).
Background processing (B): At least 2 for each R/3 system (more than 1 allowed for each dispatcher).
Enqueue (E): Only one is needed for each R/3 system.
sks
A rigid mind is very sure, but often wrong. A flexible mind is generally unsure, but often right.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-26-2004 08:39 PM
тАО06-26-2004 08:39 PM
Solution
Hi,
basic calculation for a central instance with database on one single host, no application server is very RAM dependant.
If you have no idea about the application load, start with minimal approach. For release 3.x (!!) (assuming Oracle 8.0.x as the database below) this would be roughly:
200 MB DB-Buffers
150 MB Shared pool
~100 MB Spare for Oracle PGA and Oracle-stuff else.
150 MB (!! bare minimum !!) ABAP-programbuffer
~100 MB rest global buffers for the instance
~200-???? MB dynamic Memory for SAP Instance
Now as far as I remember, ~15MB was the amount of memory a single workprocess needed staticly with 3.x. As alread pointed out, the absolute minimum is to have 2 Dialog processes and one of the other types
2 DIA
1 BTC
1 UPD
1 ENQ
1 SPO
You do not need to configure additional Gateways if you have no SNA connection, the TCP/IP gateway ia always part of the instances as well as the message server for a central Instance.
OK, now you are ready to calculate what is left. In this config, you have 900 MB for global buffers of any kind plus 6 workprocesses (~ 90 MB) plus some spare for gateway and message server.
This means, you need ~ 1GB. It is possible to run a system with less memory (I have seen 3.X systems on 384MB boxes, but this was just for testing purposes of a handfull of users, and there was not so much fun with that). If you have more RAM available, there are various ways to spend it.
To scale on, you need to decide what your application load is like. If you have many users working in the same SAP modules, you will like to increase the number of dialog and update processes (1 UPD for 3-7 DIA, depending on module and dialog activity).
If you have just few users (< 15-20), but use 3+ modules from SAP, you would like to increase the programbuffer first.
This part is an ongoing process, which develops with the monitoring of the system.
Ensure that the background job RSCOLL00 is running hourly (Jobname usually COLLECTOR_FOR_PERFOMANCEMONITOR or SAP_COLLECTOR....). It gathers performance data to give you somthing to work with.
Check transaction ST04 for quality of DB-buffers (90%+ is ok as a starter) and shared pool (95%+) (if oracle).
Check transaction ST02 for quality of SAP Buffers.
Check transaction ST06 for CPU load and memory consumption. You should ensure that some memory is still free directly after the start of the instance. So the system should not do paging for global memory areas (this would be a real knock out). The bigger the reserve is, the less paging you will have for dynamic memory requirements.
Check transaction ST03 for load distribution of the workprocesses. A wait time higher than 10ms for dialog-task-type suggests to increase the nuber of dialog processes (this rule does not apply for batch:-)
All of the STxx data should be taken more serious the loger the uptime of the sap-instance is. Bufferqualities of 60% are not critical, if the instance has just started. 60% is inacceptable if the system is running for a few days. Some system activities destroy buffer-quality by design, I.e. client-copies. So do not anlyze DB-BUFFER needs after a client copy.... You will never have enugh RAM for that!
Again this is a basic start, and you will need to increase these values with either the number of users / number of used modules / sap-release.
How much RAM do you have ?
Hope this gives you something to work on.
Volker
basic calculation for a central instance with database on one single host, no application server is very RAM dependant.
If you have no idea about the application load, start with minimal approach. For release 3.x (!!) (assuming Oracle 8.0.x as the database below) this would be roughly:
200 MB DB-Buffers
150 MB Shared pool
~100 MB Spare for Oracle PGA and Oracle-stuff else.
150 MB (!! bare minimum !!) ABAP-programbuffer
~100 MB rest global buffers for the instance
~200-???? MB dynamic Memory for SAP Instance
Now as far as I remember, ~15MB was the amount of memory a single workprocess needed staticly with 3.x. As alread pointed out, the absolute minimum is to have 2 Dialog processes and one of the other types
2 DIA
1 BTC
1 UPD
1 ENQ
1 SPO
You do not need to configure additional Gateways if you have no SNA connection, the TCP/IP gateway ia always part of the instances as well as the message server for a central Instance.
OK, now you are ready to calculate what is left. In this config, you have 900 MB for global buffers of any kind plus 6 workprocesses (~ 90 MB) plus some spare for gateway and message server.
This means, you need ~ 1GB. It is possible to run a system with less memory (I have seen 3.X systems on 384MB boxes, but this was just for testing purposes of a handfull of users, and there was not so much fun with that). If you have more RAM available, there are various ways to spend it.
To scale on, you need to decide what your application load is like. If you have many users working in the same SAP modules, you will like to increase the number of dialog and update processes (1 UPD for 3-7 DIA, depending on module and dialog activity).
If you have just few users (< 15-20), but use 3+ modules from SAP, you would like to increase the programbuffer first.
This part is an ongoing process, which develops with the monitoring of the system.
Ensure that the background job RSCOLL00 is running hourly (Jobname usually COLLECTOR_FOR_PERFOMANCEMONITOR or SAP_COLLECTOR....). It gathers performance data to give you somthing to work with.
Check transaction ST04 for quality of DB-buffers (90%+ is ok as a starter) and shared pool (95%+) (if oracle).
Check transaction ST02 for quality of SAP Buffers.
Check transaction ST06 for CPU load and memory consumption. You should ensure that some memory is still free directly after the start of the instance. So the system should not do paging for global memory areas (this would be a real knock out). The bigger the reserve is, the less paging you will have for dynamic memory requirements.
Check transaction ST03 for load distribution of the workprocesses. A wait time higher than 10ms for dialog-task-type suggests to increase the nuber of dialog processes (this rule does not apply for batch:-)
All of the STxx data should be taken more serious the loger the uptime of the sap-instance is. Bufferqualities of 60% are not critical, if the instance has just started. 60% is inacceptable if the system is running for a few days. Some system activities destroy buffer-quality by design, I.e. client-copies. So do not anlyze DB-BUFFER needs after a client copy.... You will never have enugh RAM for that!
Again this is a basic start, and you will need to increase these values with either the number of users / number of used modules / sap-release.
How much RAM do you have ?
Hope this gives you something to work on.
Volker
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО06-26-2004 09:52 PM
тАО06-26-2004 09:52 PM
Re: formula for SAP system work processes
OK,
I just saw from your previous questions that you already dealt with application server(s).
Do NOT configure any ENQ on the APP-Servers !
... and keep in mind that an additional workprocess on the application server requires an Oracle shadow process on the database server.
Volker
I just saw from your previous questions that you already dealt with application server(s).
Do NOT configure any ENQ on the APP-Servers !
... and keep in mind that an additional workprocess on the application server requires an Oracle shadow process on the database server.
Volker
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Learn About
News and Events
Support
© Copyright 2025 Hewlett Packard Enterprise Development LP