Welcome to ProgressTalk! It would be helpful to know specifics of your Progress and operating system versions. It's a good idea to always provide those when posting a question.
The _mprosrv process serves more than one purpose. You are correct that it can be a database broker process. There will be at least one of these (the primary broker) per database running in multi-user mode, and perhaps a few others (secondary brokers). But likely not more than a handful.
But _mprosrv is also the process for 4GL remote servers, i.e. servers that act on behalf of Progress 4GL (aka ABL) clients. If your databases have remote clients, each database will likely have many more _mprosrv servers than brokers.
You can distinguish servers in the process list as they have "-m1" as part of their command line. All secondary brokers have "-m3" in their command lines. An _mprosrv that has neither of these parameters, but does have parameters like -n, -B, -Mn, etc. is the primary broker.
Each of these processes obviously uses some amount of memory for its code and data. But likely the majority of the memory consumed per database is in the shared memory segments allocated by the primary broker when it opened the database. This shared memory, which is mapped into the address space of all database processes running on the database server (except those connecting via TCP), consists of data structures like:
- the database buffer pool (the DB's memory cache); its size is specified by the value of the -B startup parameter, in units of database blocks;
- the lock table (specified by -L, in units of records);
- the transaction table (one record per user);
- the user connection table (one record per user);
- and various other data structures.
Most of shared memory is typically used by the buffer pool. Its size in bytes is given by the value of -B multiplied by the database block size. You can find both of these values with promon (the Progress database monitor). The syntax is: promon <database name> (where <database name> is the relative or absolute path of the database).
In promon you will see a menu like this:
Code:
OpenEdge MONITOR Release 10
Database: /home/robf/db/sports/s2k
1. User Control
2. Locking and Waiting Statistics
3. Block Access
4. Record Locking Table
5. Activity
6. Shared Resources
7. Database Status
8. Shut Down Database
R&D. Advanced options
T. 2PC Transactions Control
L. Resolve 2PC Limbo Transactions
C. 2PC Coordinator Information
J. Resolve JTA Transactions
M. Modify Defaults
Q. Quit
Enter your selection:
Select 6 (Shared Resources) to get the value of -B (as well as other startup parameters). Select 7 (Database Status) to get the database block size in bytes. You can also select 5 (Activity) to get the total size of Shared Memory. This will tell you how much virtual memory is consumed by all of shared memory in the database, including the buffer pool.
Another (more tedious) way to get information on database shared memory system-wide in Unix is with a pair of commands: proutil -C dbipcs (a Progress command) and ipcs -m (an OS command). The former shows a list of Progress-created shared memory segments and their IDs, for
all databases; the latter provides a similar list with IDs and sizes in bytes. Caveat: I don't know your Progress version and have never used Tru64, so you may or may not have access to these commands.
All of this and a lot more is documented in the Progress Database Administration manual for your version. Docs are available here:
https://community.progress.com/technicalusers/w/openedgegeneral/1329.openedge-product-documentation-overview.aspx.
