After a migration from WFA 4.0 to a different server on WFA 4.2 we started to see slowness up to the point where the application was unusable.
The execution log was taking minutes to populate, and when it was populating for one user, the rest could do nothing, get timeout errors and messages about "server busy".
We saw that every time someone hit on the execution logs, the database was bringing the table to memory, and seems that happened every time, causing 140MB/s throughput and around 10k iops
Another observation was that the services were using ways less memory, even if we went from a 8GB system to a 16GB system.
After some troubleshooting, did the following:
Browse in "regedit" to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software
Foundation\Procrun 2.0\NA_WFA_SRV\Parameters\Java
And change the “option” key with new values for XMS and XMX to :
-Xms1536m
-Xmx3072m
And change the “option” key with new values for XMS and XMX to :
-Xms1536m
-Xmx3072m
Change the option in "my.ini":
Innodb_buffer_pool_size = 8M
to
Innodb_buffer_pool_size = 8192M
The application is fast again and no more IO to disk.
Resources
I would recommend (if WFA becomes a big part of your automation) to give 4 cores and 16GB of ram.
Limits
Regarding WFA's limits. It's know that perl scripts are way faster than PowerShell, remember that PowerShell has signed code that might check Revocation Lists (see previous posts on CRL).
The WFA planning phase is a single thread (to handle reservations properly), but once planned, it can run 100 workflows simultaneously (depending on the resources ofcourse). The rest gets just queued.
No comments :
Post a Comment