thread / process slow to start

One thing – but not the only thing – is a Recovery DB which has a lot of Active messages in it.

A couple of things could be the database files have grown large or there are a lot of queued messages on the thread.

You can use the db init command (hcidbinit) to re-initialize the database files – BE VERY CAREFUL WITH THIS COMMAND – it will wipe out all queued messages in the recovery and error databases for that site.  When I need to issue this command, I do the following steps:

1. do a setsite command if you are doing this from a text session
2. shut down all incoming threads in the site
3. wait for all the messages to clear out.  The alternative to this is to use the hcidbdump command to offload all the messages, but this is cumbersome if there are a lot of messages and/or threads since they need to be offloaded by each destination and state.
4. once all messages have cleared out, shut down all other threads and processes for that site.
5. Stop the Lock Manager and Monitor Daemon for that site
6. Issue the db init command (hcidbinit).  I use the “-ACf” flags with it – look in help for explanations.
7. Start the Lock Manager and Monitor Daemons up
8. Start up your processes and threads.

By clearing them out, do you mean you just deleted them or did you do the database initialization?  If you didn’t do the initialization, the database file is still at the same size it was with the 830K messages and will take a while to load up even if it is empty.

Limit the size of the DB?  No.  If we did that then data could potentially be lost.

If you are really worried about space and speed, you can turn off recovery DB in your test environment if you don’t need to worry about persisting the messages when you stop and start things.  This is a setting on each thread’s properties.

Note that the database file size will reach a “high water mark”, that is if messages are deleted from the database, the space will be re-used as new messages are added.

Another thing you can do to shrink the size of the database non-destructively is run the following commands (lock manager, all processes need to be shut down first)

hcidbinit -i -C -f

dbdefrag rlog

Is this a Test environment or the Production Environment?

Are the Test and Prod Environment on different servers?

If I understand correctly there are 2 Cloverleaf versions on the same server.

Could it be the server is not properly sized for the workload? Don’t forget about I/O.

I think you have some detective work to do.

Consider over committed processes or sites if platform is properly sized. But make sure the platform is properly sized for the workload.

It is also possible Tcl code used at thread startup is less than efficient.