The OpenEdge Hive

Progress uses the buffer pool which is the single largest memory usage by the database engine. Other than that, the 102B user each uses around 30M of memory. So for 1000 users, the system will use about 4G of memory and that is not a lot. The VST stats are part of the memory, they go away when you shutdown the database. VST has many parts, so if you are not careful, they might bite you when you least expected. When you get a -Mxs error in the database log and the database shutdown, it might look like a share memory lock shutdown, but in reality it is because the shared memory has run out and it has something to do with -L. Shared memory does run out in our mind because it is just a place holder for records, the old ones get evicted for the new ones, and the cycle continues, but that's not the case for VST numbers like -L where a bad piece piece of code could use up for thousands of -L records and that's not getting release untill the end of the transaction.
On the client side, -mmax is a big memory spender. You could easily use up to 20M of memory for each client for their r-code, temporary table and the sorting space. It's an important performance factor, where if you don't have enough -mmax, you will see a busy disk activity. You can monitor these by checking the -T directory and see if the files are growing.
For the WS and appservers, depending the activities, for each agent to have 300M of memory is not uncommon at all. If the code is not written to release those objects(widget-pool) properly, the WS agents will only consume even more memory. You can always choose to trim the agents to release the memory without shuting them down. The admin server which is the base of the architecture also consume more and more memory as the time goes on, so restarting adminserver becomes essential.