| Author |
Message
|
| ramires |
 Posted: Thu Oct 19, 2006 7:59 am Post subject: Cleanup server |
 |
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Hello,
I've the cleanup server running from 21:00 to 08:00 next day. At the end I still have thousands fmc.process_inst=128. I can start it manually, or increase the cleanup working time, does it have great impact with overall performance?
Also, is it possible do define more than one cycle for cleanup server work?
Like, during week days from 21:00 to 08:00, saturday and sunday from 01:00 to 24:00?
Thanks!
Joao Ramires |
|
| Back to top |
|
 |
| jmac |
| Posted: Thu Oct 19, 2006 9:20 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Joao:
Have a look at the Admin guide... there is a section on Improving the Performance of the Cleanup server in Chapter 1. This will probably help, once you resolve the current issue. You might want to just run the cleanup server all day over the weekend to cleanup all the excess
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| PisgahMan |
| Posted: Thu Oct 19, 2006 10:09 am Post subject: |
|
|
Voyager
Joined: 27 Jul 2004
Posts: 93
|
| We have seen some very strange behavior in our clean-up server since we upgraded to Version 3.6. Before clean-up server runs, if you query the process instance table for state=128, you will see ~70,000 records. As it runs that number goes down @ about 1000 a minute until it reaches 0. Then it sends a huge spike of messages to the RTSINPUTQ (30,000-60,000). After that spike clears, if you query the process instance table for state=128 you will see ~70,000 records. I don't know if is is updating the next days records or what exactly. |
|
| Back to top |
|
|
| ramires |
| Posted: Thu Oct 19, 2006 12:47 pm Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Thanks jmac and PisgahMan.
I'm with version 3.5.0.2 Its a no option to migrate now.
I'll follow your sugestions. I've to check maxdetpth on RTSINPUTQ. I don't have access to the system rigth now to check MAXDEPTH (I guess is 10000) , but what happens if RTSINPUTQ becomes full?
Joao |
|
| Back to top |
|
|
| PisgahMan |
| Posted: Fri Oct 20, 2006 5:41 am Post subject: |
|
|
Voyager
Joined: 27 Jul 2004
Posts: 93
|
| If RTSINPUTQ fills up Workflow will basically lock up. This happened to us in our PROD environment after we upgraded to 3.6. The Exe servers cannot send messages to itself so it is unable to do any work. The solution was to increase the queue depth and then restart WF. The RTSINPUTQ depth went up then came down. |
|
| Back to top |
|
|
| koko |
| Posted: Fri Oct 20, 2006 7:02 am Post subject: |
|
|
Master
Joined: 26 Sep 2003
Posts: 206
|
There was as a problem with clean up server not doing its job properly with particular level of MQWF 3.5 SP4. IBM released a specific APAR fix for the problem.
_________________
Thanks
Koko |
|
| Back to top |
|
|
| ramires |
| Posted: Fri Oct 20, 2006 7:35 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
Thanks to all,
it's time to plan a migration, a 25Gb db growing 1gb week can be a problem...
Can I estimate the time migration utility takes to migrate such a db?
joao |
|
| Back to top |
|
|
|
|
