Has anyone run into issues with ProcessFlow hogging a lot of the CPU. We are running ProcessFlow and even running one PF maxes out the CPU to the tune of 90%. Lawson says we need to hire a consultant for performance tuning which is absolutley insane. Anyone else seen this? :banned:

Hmmm, are they willing to garuntee that the consultant will make the difference? To side with Lawson though for a second, you issue could be very specific and require many hours of debugging. On the other hand, you're not the first person to complain about the amount of resources taken up by PFlow.

Our processflow installation is not really being used that much but I notice if I don't restart it every so often the Mem Usage continues to climb. That may or may not mean anything really when you think about how much is really involved in each process but I'd be curious to see what if anything a consultant ends up doing for you if he comes on site. Let us all know will ya

I keep a very close eye on CPU usage on our application server, and I've never seen ProcessFlow use consume much. DME calls (and their associated database drivers) can consume significant amounts of CPU, depending on how the queries were written, but ProcessFlow itself uses almost nothing.

We have not had serious memory constraints, so I have not looked closely at ProcessFlow's use of memory. You can at least be sure that it won't climb above the maximum amount of memory that you have allocated for the JVM, though.

What version are you using? I've seen issues with PF 8.0.2 with regards to this sort of thing. I've found PF 8.0.3 to be much more stable. You may want to consider giving the processes more memory to work with. If the JVM is constantly doing garbage collection, you'll certainly see performance degradation.

Also, for reference, what platform are you on?

Just found this on support:

Description:
My Lawson applications and Internet Object Services (IOS) server has a java process that is taking up all or most of the CPU. How do I troubleshoot this issue?
Resolution:
To troubleshoot this issue, follow the steps below:

1. Determine if the java process in question was spawned by the Lawson RMI server or your servlet container. Follow the steps outlined below to determine if the java process from RMI (not the servlet container) is consuming large amounts of memory.
a. Go to a command prompt on your application server.
b. If you are using the 8.0.2 version of IOS, type ps -ef |grep java.rmi | lashow and press Enter.
c. If you are using the 8.0.3 version of IOS, type ps -ef |grep "java -classpath" | lashow and press Enter.
d. Look for a process similar to "java -Djava.rmi" or "java -classpath" that contains the path for the environment you are working in. If you are using ProcessFlow (PF), you should be able to distinguish the PF RMI server process from the IOS RMI server process. Note the PID of the IOS RMI server process.
e. Monitor this process' CPU and memory consumption.
f. If this process is not consuming a large percentage of CPU and you are running a local IOS configuration (your Lawson applications and web server are running on the same machine), then monitor your servlet container java process. To find this process, type ps -ef | grep java | lashow and press Enter.
g. If you are using WebSphere, look for a process similar to "WEBSPHERE_HOME/AppServer/bin/java".
h. If you are using Tomcat, look for a process that contains "java -Dtomcat.home" for Tomcat 3.2.x or "catalina.home", "endorsed" or "Bootstrap" for Tomcat 4.x. The process should contain paths to the directories where your Tomcat instance is installed.
i. If you are using SunOne/iPlanet, look for a process that contains "ns-httpd". This is your web server process. If you find that it is using a large amount of CPU or memory, check the "Configure JRE/JDK Settings" screen under the Global Settings tab in your Admin Server and make sure you are using the JDK Path and that it points to your 1.3 installation of Java. See KB article 90201 for more information.

2. If you have determined that the RMI java process is consuming a lot of CPU, view the CGIDIR/rmi/IOS.log file on your application server. Look for messages similar to "Creating new transaction process for <DATA_AREA>" or "Creating new drill process for <DATA_AREA>". If you notice that the RMI PoolServer is creating new processes often, then your CGIDIR/rmi/PoolMgr.properties file may need to be tuned.

3. View the CGIDIR/rmi/PoolMgr.properties file.

4. If your users are accessing any data areas that are not declared in PoolMgr.properties (per the "Creating…" messages noted in step 2 above), add them to the data area list. When undeclared data areas are used in Portal, the PoolServer will create a new process for the transaction or drill requested by Portal, execute the process, and then destroy it. It will do this for every request made for that data area. This additional processing can consume large amounts of CPU and memory.

5. If you are have more than three data areas declared in PoolMgr.properties, consider decreasing the number of processes started at startup time by decreasing the initconns_ida, initconns_pts, and initconns_dme parameters. The delivered setting is 2.

> Our processflow installation is not really being used that much
> but I notice if I don't restart it every so often the Mem Usage
> continues to climb.

There's a known memory leak with Java on AIX - be sure you have all the OS patches that are in any way related to Java installed

We use processflows extensively for Personnel Actions. We're a windows box in loopback mode. Java is our main processor hog while a pflow is active and haven't had much help from Lawson. Java itself isn't a very efficient processing language anyway. You may need to throttle back the # of active flows processing concurrently.