Abyssmal DD performance with OD6.0

For some reason, my deployments in my dev environment are taking forever to finish, even when there is only one file attached. My QA environment, which has better hardware is somewhat better, but still not really acceptable. Memory and processor utilzation are very low (about 2% and 25% respectively), so I don't think I'm hammering the box. I would suspect the RDBMS, but the heavy lifting in the deployment is all going very quickly.

For instance, here's a log snippet. This particular deployment started at 18:45:38, and as you can see - it actually finishes in less than one third of a second, but for some reason it sits around for almost three minutes before the "Published leg event" message. Any clue what it's doing in the meantime? If I only have one file, it's not too painful, but when there are multiple files attached to a job, it waits 3 min between each file.

ENG: 2004-09-29 18:45:38 EDT GMT-04:00 Setting final state to TASKDONE
ENG: 2004-09-29 18:45:38 EDT GMT-04:00 Manifest path is

/WebApps/Internal/Interwoven/OpenDeployNG/log/tsg/src.tsg_ea_dd.tsg_ea_dd.prvdintwvncs1.to.database.log.mf
ENG: 2004-09-29 18:45:38 EDT GMT-04:00 Got Manifest object com.interwoven.od.adapter.delivery.base.IWODManifest@27ea69
ENG: 2004-09-29 18:45:38 EDT GMT-04:00 fHasFailedItems is set to false
ENG: 2004-09-29 18:48:16 EDT GMT-04:00 Published leg event depUuid=[488c7190-1269-11d9-853d-c56f35f4d914] legLabel=[database] nextUuid=[null] nextDep=[null]
ENG: 2004-09-29 18:48:16 EDT GMT-04:00 Job ID=m26 Deployment leg=database Elapsed Time=328 ms <<<
ENG: 2004-09-29 18:48:16 EDT GMT-04:00 End logfile [D:\WebApps\Internal\Interwoven\OpenDeployNG\log\tsg\src.tsg_ea_dd.tsg_ea_dd.prvdintwvncs1.to.database.log]

NOTE: The forum software munged the published leg event line. Here it is with some the [s removed in the hopes that the actual content will show;
Published leg event depUuid=488c7190-1269-11d9-853d-c56f35f4d914 legLabel=database nextUuid=null nextDep=null

Edited by robhuffstedtler on 09/29/04 04:09 PM (server time).

Find more posts tagged with

Comments

Migrateduser

Hi Rob,
A couple things come to mind.
Are you using the OOTB default Hsql database?
And has it been running a long time?

Try these things:
1) disable eventreporting
and if imrovement is observed, then
2) reset the hsql db files and recreate fresh new ones (i think there is a KB article that instructs how)

A 3rd option would be to configure OD's JMS to use a real RDBMS, but that procedure
has not been publicized/certified at this time.

Bill

Interwoven Engineering

Migrateduser

Just to clarify slightly, the HSQL being mentioned is the demo database that comes with OD for event reporting, which is not intended for production use. I believe the OD docs describe how to "reset" the demo database.

But, if this is the cause of the performance degradation, you should consider using a commercial database for event reporting. Again, the docs explain how to set that up.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

It looks like that may have been it. I disabled event reporting and I think I'm seeing a marked improvement. I need to test it somewhat more systematically, but that would appear to be it. Thanks for the tip.

Migrateduser

good to hear.

to clarify on Todd's clarifcation,
the OOTB database is the reporting database and can be swapped with a commercial RDBMS.
The OD admin server makes use of this db.

however the JMS event server database has not been officially exposed as swappable.
The OD server makes use of this db.
it uses the HSql database OOTB. This is the database that i think may be at issue.

Interwoven Engineering

anthonyl

Would it be technically possible to edit the jmsconfig.xml file to point to a different rdbms instance? We have been having problems with javaw.exe going rogue and consuming one processor on our dual processor machine. So far we have been able to trace it back to constant recreation of the openjms.db.script file. Recreating the db files does not solve the problem...