To Process or Not to Process that is the limitations?

[James Phetteplace]

So I am fairly new to Cloverleaf (1.5 years now) and this question comes up a lot. I searched on the forums before I posted this too but couldn’t really get a straight answer to my question (maybe there isn’t really a straight answer either). What are the limitations of a process? This seems more of a standard / preference than anything. I have heard all types of ideas of how to use processes in cloverleaf. Some from only have 6 process per site to 15 process per site. Or having 1 inbound thread per process and any amount of outbound as long as you stay under 16 threads for a process. Or having 1 process for inbound threads (splitting them up when there is a certain amount) and 1 process for outbound thread (splitting them up when there is a certain amount) that why you can control outbound messages from going out.

So I guess my question is, is there any documents of how to use processes in Cloverleaf? What is the standard rule for using processes per site? What is the standard rule for the amount of threads per process?

Any help would be greatly appreciated, sorry if this question is on the forums (I couldn’t find it).

Topic

[Robert Milfajt]

My experiences are this, all AIX using several Cloverleaf versions 3.3.0P through 6.0.1.

1.  It seems to be more volume and processing related vs. actual numbers of processes per side, or number of threads per process.

2.  There is a limitation (I know, I’ve seen it), where if you have too many threads/processes in a site, that the monitord doesn’t report the the GUI, showing things in incorrrect status or not allowing commands to be run.

Things to watch out for.

1. Cloverleaf can’t get messages out of state 5 fast enough for a particular process.  This means the process is doing too much and needs to be split.

2. Cloverleaf threads that route to other Cloverleaf threads backup up in state 7 or 11.  This means where your sending data is overloaded because it’s holding up the receipt of data.  Same could be said if the source system is reporting high queue depths to Cloverleaf.

3.  High volumes in recovery dB either because of #1, #2 or a destination system outage.  This will slow everything down, to the point where the monitord cannot report on things, the GUI freezes, and recycling processes takes and extremely long time.

There are no hard or fast rules, it’s like tuning an older car, you have to get the feel for it, and identify the trouble signs via vigilant monitoring to prevent catastrophic failure.

Hope this helps,

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Rob Lindsey]

The number of threads per process and processes per site are going to depend on a lot of different factors.  The more processes and fewer threads  per process, the faster the process stops and starts.  The same for the number of processes per site.  With our hardware the total number of threads that can exist in one of our processes is 34.  When we added a 35th thread, the process would crash.  You will need to figure out based upon your hardware and other software and operations what works best for your business.  It also depends on how many msgs are going to be going through the internal databases and how big they are.  So it takes a bit of playing around to get it to where things work best for your business and operations.

I wish there was a pat answer for all of this but there is not one.

I have been using CL for over 15 years and each company that I have worked for the setups have been different and I have had to change them over the years to keep up with the hardware and business.

Rob

[Author]

Replies