Database Resource Concern

D

dlangschied

Member
Hello,
In our recently upgraded Progress Environment (V9 to OE10.1C) I am noticing that the database process _mprosrv is taking a lot of resources. We did a load test with a subset of users during our testing phase and did not see this occur.

Is there a known issue here with the progress server app and resources?

Is this something that is going to worsen until it causes me issues with the databases?

Specs:
OS (Old; I know!)
Red Hat Enterprise Linux AS release 3 (Taroon Update 9)
Kernel 2.4.21-51.ELsmp on an i686Red Hat Enterprise Linux AS release 3 (Taroon Update 9)
Kernel 2.4.21-51.ELsmp on an i686

Hardware
2 - CPUs
8 - GB RAM

Database Startup
-B 160000
-L 120000
-Mf 10
-bibufs 135
-aibufs 135
-spin 20000
-S prod_01
-N TCP
-bistall
-aistall
-n 200

An investigation of the database performance is very good. It is humming along quite well. My concern is the apparent resource usage. Below is my top output:

10:17:54 up 4 days, 23:15, 60 users, load average: 4.23, 3.32, 3.23
538 processes: 534 sleeping, 4 running, 0 zombie, 0 stopped

CPU states: cpu user nice system irq softirq iowait idle
total 82.6% 0.0% 9.1% 0.0% 0.2% 0.1% 7.7%
cpu00 81.9% 0.0% 11.0% 0.0% 0.3% 0.1% 6.3%
cpu01 83.3% 0.0% 7.1% 0.0% 0.1% 0.1% 9.1%

Mem: 8208388k av, 8118500k used, 89888k free, 0k shrd, 84812k buff
5879208k actv, 1091052k in_d, 177380k in_c
Swap: 6291416k av, 266160k used, 6025256k free 6378336k cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND
22165 root 25 0 1203M 1.2G 1203M R 45.4 15.0 3993m 1 _mprosrv
22353 root 25 0 1188M 1.2G 1187M R 43.8 14.8 4692m 0 _mprosrv
 
What is your complaint about the top output? Does it differ in some interesting way from what you saw with v9?

In general 10.1C prefers lower -spin settings than v9 did.

It will also use more RAM.

It is a client parameter so may not be relevant here but -tmpbsize has quite an impact on RAM use as well. The default value has changed several times. For many people -tmpbsize 1 makes the most sense.

Did you go to 64 bit Progress executables?
 
Actually, in Version 9, we had average idle% of around 40%, with consistently low user% (around 20%).

The spin is interesting. I have always found the setting to be difficult to determine in my performance tuning. The setting that is use is pretty much 10000 per CPU, but that is just my making it simple. Is there a reliable formula that can be used in the OE environment?

The client parameter looks like no brainer. I can introduce it and just let the users take the new setting as they login.

Unfortunately, we are on 32-bit. This system is old and we could not make the switch on hardware. Which is just fine with me. I hate changing two things at once. Upgrade to OE first, then get a new server and migrate the databases over later.

Thanks for the support!
 
There is no formula for -spin. N x #of CPUs is, IMHO, a crock. Gus tossed that out as an idea way back when and almost immediately retracted it as not very good. Ask him, he'll confirm it. It has, however, been unfortunately enshrined in several kbase articles and Professional Services whitepapers so it is very hard to kill. It keeps crawling out from under another rock every time you think it is finally dead and gone. Sort of like Jason or Freddie.

Rich Banville did some experiments when 10.1C was new and and presented them in his talk at Exchange 2008 (Paris, back when we had real-live Exchange). He found that fairly low values worked best -- 2,000 or so as I recall.

I would try setting it lower. You can do it online via PROMON or the _StartUp VST. If it lowers CPU consumption without hurting performance then it is good.

You could also try setting it stupidly high -- sometimes that is good for performance (one example is when you have a single process doing all the work -- not your situation I know). But doing that is unlikely to improve your CPU useage % ;)
 
Okay!
I did go in and change the spin to a good result. I now have a new question, but I will do it in a new thread.

Thank you sooooo much!
 
You must log in or register to reply here.
Back
Top