The application is an interfacing application (Healthvision Cloverleaf) that receives Helathcare HL7 transactions via TCP/IP from various applications and routes them to the appropriate destination application(s). From the time the transaction is received until it is sent out of the interface engine, it could be translated (via Tcl programs) several times. Translation consists of transaction re-formatting, field reformatting, table maps, transaction filtering logic and other types of data massaging.

While being routed and translated, the transactions are stored temporarily in a Raima database (Healthvision's 3rd party Db agreement) for disaster recovery purposes. If someting dies or is stopped, the undelivered messages are read from the database and the engine continues where it left off. There are 15 points at which the transactions are saved to the database during their journey from the source to the destination.

So, the application is pretty I/O intensive. Each transaction is betweeen 1k and 2k and its written to the Raima Db at least 15 times. Our production environment processes about 1.2 million of these transactions per day on average. We are expecting our volume of transactions to roughly double in the next four years (hence the new server).

We changed our min and max to the values suggested by the vendor, Healthvision.

Thanks!!

Here is the output of the vmstat -v command:

Code:

/>uptime
  9:03am  up 12 days,  13:38,  3 users,  load average:  1.16, 1.07, 0.93
/>vmstat -v
              6291456 memory pages
              6080336 lruable pages
               225542 free pages
                    1 memory pools
              1007176 pinned pages
                 80.0 maxpin percentage
                  3.0 minperm percentage
                 90.0 maxperm percentage
                 48.1 numperm percentage
              2930676 file pages
                  0.0 compressed percentage
                    0 compressed pages
                 48.1 numclient percentage
                 90.0 maxclient percentage
              2930676 client pages
                    0 remote pageouts scheduled
                   13 pending disk I/Os blocked with no pbuf
                    0 paging space I/Os blocked with no psbuf
                 2484 filesystem I/Os blocked with no fsbuf
                    0 client filesystem I/Os blocked with no fsbuf
                28690 external pager filesystem I/Os blocked with no fsbuf

---------- Post updated at 09:09 AM ---------- Previous update was at 09:05 AM ----------

I'm not sure if our Admins will allow us to run our CPU in a pool, with LPARs uncapped.

I think the concern is that if there is resource intensive processing on the TEST node it might steal too much resources from the PROD node. We do, on occasion, perform large production transaction re-sends from our TEST node. We have to do this when a destination application didn't process the transactions correctly for an extended period of time or if the application was down for an extended period and we couldn't allow the transactions to queue in our engine that long.

However, I will discuss this option with admins and let you know their feedback.

Thanks again.