Optimal value for -Ma

Maybe extreme but I always use -Ma 1. Any higher value  causes users to share a server and it is very difficult to see if a user who experiences performance issues is causing them him/herself are if another client sharing the same server is running a "bad" query.

Probably depends on how many users you have , I usually have to less than  200 users

We'll have 400 to 700 users (on two DBs), so I'd like to know if it's worth starting 1500 server processes. When you say it's very difficult to see why a performance issue is caused by another client on the same server, you mean that there's no metric to detect the contention between clients ?

AFAIK a server is single threaded (*)  like most Progress executables. If one ore more client connect to a single server, that server will only serve one client at a time.

Assume users A1, A2, A3 connected to server A. B1, B2 connected to server B, etc.

One client (A1) runs a slow  query will block the other clients (A2, A3) connected to the same server.

In a well tuned system the rest of the clients (B1, B2, C1, ....) won't notice a thing (unless its really bad) .

There might be metrics, but I don't know of a way to inform the user that has has to wait for another user's huge query.

-Ma 1 is probably the easy way out on smaller systems.

What are the costs for one server for every user? Where is the limit for servers?

BTW: Why I need to configure things like this if I can't know which query will be run on which server?

Will the performance decrease at some point when I have to many running servers?

Why this isn't handled in OE internally to move the clients around the available servers and not to lock them to one fixed , perhaps busy server by another client?

"Why this isn't handled in OE internally to move the clients around the available servers and not to lock them to one fixed , perhaps busy server by another client?"

It simply was designed that way a long time ago, I would say. The question why it is that way is not relevant...

A different question would be it that can be changed (optimized), how much work that is, and if Progress product management will think it's worth the effort etc...

I doubt it's a small effort. Sounds like re-implementing the client/server protocol or at least making large changes.

In a world where more and more customers move to AppServers with more flexible client/appserver agent/session assignments I am in doubt this would receive high priority. And most AppServers use a self-service connection.

Hi Mike,

"In a world where more and more customers move to AppServers with more flexible client/appserver agent/session "

do you mean the new "pacific" appservers or something else?

Just ran a quick test (for what it's worth), and wanted to see the behavior ; DB with a single 400 Mb table and 100 Mb index, started with :

proserve xx -Mn 20 -n 20 -B 150000 -prefetchDelay -prefetchNumRecs 100 -lruskips 100

proserve xx -m3 -Mpb 1 -Mi 1 -Ma 5 -S 30000 -minport 20000 -maxport 21000 -Mm 8192

proserve xx -m3 -Mpb 5 -Mi 1 -Ma 1 -S 30001 -minport 20000 -maxport 21000 -Mm 8192

Batch clients always running a for each table, then quitting. Connected with -db xx -H localhost -S 3000x -Mm 8192

First execution is shared-memory to load the entire table in -B, then a second one in shared memory to verify there are no more DB reads. 35 seconds to execute the procedure.

Then followed by one thread, first on first broker, then on second broker. Results are consistent on each run (20 seconds in my case, fun result as is twice as fast as shared-memory mode).

Then 5 parallel threads, also on first broker then on second one, and results are quite different :

* With 5 clients per server, each session run in around 1 minutes 40 seconds. Server is attached to one CPU, and this CPU is running at 100%. Promon shows 380k reads per second.

* With 1 client per server, each session run in around 1 minute and 25 second. Promon shows 450k reads per second. Only 2 CPU, and the process are usually running on different CPU (according to top)

--> 1 to 1.2 ratio

That was executed on a small server, with only 2 quick CPU. Client sessions were competing with server processes for CPU. The 5 servers were also competing for CPU.

When running client sessions on a different server :

* 1 minute 35 with 5 clients per server (and only one CPU working). 400k reads in promon

* 45 seconds with 1 client per server (and two CPU working). 750k records in promon

--> 1 to 2.1 ratio

I'll redo the test with the QA server, where I could leverage the 24 cores and run more sessions in parallel.

As with any bench done in less than an hour, that won't reflect reality. But at least it gives some figures.

Each _mprosrv -m1 consumes 10-20Mg RAM at start-up IIRC and the cost to the operating system is in kernel calls and context switches. If the CPUs are not busy then the cost is likely negligible and most modern boxes have more than enough RAM.

With that said, I typically put regular users on -Ma 5, AppServer agents on -Ma 1 (if they can't be shared mem) and any heavy batch (ex.: reporting queues) on -Ma 1.

As for Progress, I would think that one day soon they will make the _mprosrv multi-threaded as they have done for _sqlsrv and for the new multi-session AppServer agent in PASOE. This will give you the more-or-less equivalent of -Ma 1.

> On Sep 25, 2015, at 9:05 AM, Paul Koufalis wrote:

>

> Each _mprosrv -m1 consumes 10-20Mg RAM at start-up

where did you get that number from? it seems much, much too high.

svmon  -P <pid> on AIX and pmap on Linux, I'm looking at one right now and it has four work segments of about 250 Mg each (65K X 4K pages) plus a bunch of little things.

The "Real Size" column is my addition in Excel. 

Vsid Esid Type Description PSize Inuse Pin P gsp Virtual Real Size

e7b861 - work sm 65536 0 0 65536 262 144

533cd0 - work sm 65536 0 0 65536 262 144

83b405 - work sm 65536 0 0 65536 262 144

18259f - work sm 40032 0 0 40032 160 128

pmap -d on Linux gives me :

10919:   /opt/dlc-11.5/bin/_mprosrv ged -m1 -N TCP -Nd /dev/tcp -hs 0 -Mm 8192 -yy 1950 -cpinternal ISO8859-15 -cpstream ISO8859-15 -cpterm ISO8859-15 -cpcase Basic -cpcoll Basic -ipver IPV4 -S 30000 -H 0.0.0.0

Address           Kbytes Mode  Offset           Device    Mapping

0000000000400000    3456 r-x-- 0000000000000000 0ca:00090 _mprosrv

000000000095f000     340 rwx-- 000000000035f000 0ca:00090 _mprosrv

00000000009b4000     136 rwx-- 0000000000000000 000:00000   [ anon ]

0000000002789000     272 rwx-- 0000000000000000 000:00000   [ anon ]

00000000027cd000     268 rwx-- 0000000000000000 000:00000   [ anon ]

00007f64e1bd8000  651432 rwxs- 0000000000000000 000:00004   [ shmid=0xa0001 ]

00007f6509802000      44 r-x-- 0000000000000000 0ca:00001 libnss_files-2.17.so

.... skipped many lines ...

mapped: 673784K    writeable/private: 1432K    shared: 651432K

Given the shared part is the -B (150000 * 4k) and probably some other internal DB structures, this leaves 22Mb, but many of those lines come from .so.

Last line indicates 1432K private bytes. Gus, would that be a better estimate ?

I'm just looking at orders of magnitude, not detailed calculations by the way... And target platform will be Linux, so no idea about AIX.

IIRC on Linux you only need to count the [anon].

In this case, it would be 916kb (I also included 132kb of [stack] )

I am looking at a mature _mprosrv -m1 so it is 970 Mg is because of mem usage for queries.

I previously wrote 10Mg - because I'm obviously math challenged this morning. Previous post corrected.

I fired up a virgin _mprosrv on a sports DB and see 1.7 Mg initial memory usage (10.1C 64 bit AIX).