Kbase P76339: How does the database broker determine the number of remote server processes to spawn
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
04/10/2010 |
|
Status: Verified
GOAL:
How to use -Mi parameter to limit the number of remote server processes being spawned by the login broker
GOAL:
How does Progress determine when to spawn remote server processes
GOAL:
How to save memory by only spawning remote servers when necessary
GOAL:
How to manage the creation of remote server processes
FACT(s) (Environment):
All Supported Operating Systems
Progress/OpenEdge Product Family
FIX:
When a database is started with ProControl, proserve or Progress Explorer (dbman), the database manager reads the startup parameters which are passed either from command line, a parameter file or the conmgr.properties file. If a parameter is not specified on startup, then our defaults for those parameters will be used.
Example:
1. Create a sports2000 database.
Command: prodb sports2000 sports2000
2. Then start the database from command line without any parameters.
Command: proserve sports2000
The database log file, sports2000.lg would list the following as the default parameters, which tell you how many servers and clients that can connect to this database:
BROKER 0: Maximum Number of Clients Per Server (-Ma): 5. (4257)
BROKER 0: Maximum Number of Servers (-Mn): 5. (4258)
BROKER 0: Minimum Clients Per Server (-Mi): 1. (4259)
BROKER 0: Maximum Number of Users (-n): 21. (4260)
Where:
The default for -n is 20, but internally we add another 1 specifically for the proshut command (_mprshut). This makes for a total of 21 users. These users can be local or remote, batch processes or server processes such as APW, BIW, AIW, WDOG, in other words /any/ connection to the database.
Remote users are clients that connect to a database via a port number or service name (-S) and a hostname (-H). The database would have also been started with the same -S parameter. The -Ma value, is maximum number of remote clients that can connect to this database. The default for the -Ma parameter is 5.
The -Mn is the maximum number of remote servers that would be spawned to support the remote clients. The default value for this is 5. The value 5 is comprised of 4 remote servers + 1 for the login broker process which was created when the database was started via proserve, procontrol, or dbman, in other words "BROKER 0". That leaves 4 remaining _mprosrv processes that can be spawned to handle remote clients connecting to this database.
The -Mi is the minimum number of clients connected to a remote server process prior to the broker spawning another remote server process for subsequent users. The default value for this parameter is 1. This means that for every remote client connecting to this database, the broker will look at the number of remote servers spawned. If the remote server has at least 1 user (-Mi 1), then the broker will spawn another remote server for each remote client until the maximum number of servers (-Mn) have been spawned. Once all remote servers have been spawned, then the broker will round robin users to the existing spawned remote servers, until -Ma is reached.
If the machine being used had memory limitations, the -Mi parameter could be adjusted to ensure that servers handle a certain amount of remote clients prior to spawning additional servers. Example: -Mi 5 would mean that a single remote server is spawned when the first remote client requests a database connection. After connecting the next 4 remote client processes to this remote broker (total=5), only then another remote server process would be spawned to handle the next 5 users (and so on). The diffence in this configuration, is that you only spawn the remote servers after a certain number of connections, rather than one per initial remote connection until -Mn is reached. Bear in mind, that this is a tuning exercise - it's all about memory vs perfomance. It there were (for example) a -Mi of 20, (and -Ma higher or equal to 20), that would be 20 remote client, each being "served" by ONE remote server. Remote clients may report performance degradation as this one remote server is handling all the requests of the 20 remote clients which produces resource contention.