nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OD Crashing on large deployments

bturns

TS 5.5.2
OD 6.0.1

Hi there,

We are running a really large comparison deployment (not transactional). Probably over 200,000 files are being compared but a small amout are actuall being deployed. we run this deployment every so often to make sure the entire site is in synch. OD appears to be crashing on the deployment. We've found a large core dump file. Has anyone experienced this? How does OD keep track of comparison deploys. Are all the file paths stored in memory during the deployment? Could memory be overloaded?

Any help would be great.

Thanks,

Brian

Find more posts tagged with

Comments

Migrateduser

OD does maintain manifest info in memory. It's not unusual to have deployments of this size, but perhaps the file paths are long and memory insufficient. You'll need to work with Tech Support to analyze cause of the dump.

If it's only large deployments that are failing, things to experiment with are to disable event reporting (should ease processing burden on OD server). With event reporting disabled, you could flip the in-memory manifest to the legacy and less verbose format (server config setting).

Another thought is to make sure you're not running out of disk space during the deployment due to log files getting too big.

Also make sure there's not a separate deployment running that's simultaneously attempting to update the same target area as your large deployment job.

Todd Scallan
Sr. Dir. Product Mgt.
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

bturns

Thanks!

You stated "Also make sure there's not a separate deployment running that's simultaneously attempting to update the same target area as your large deployment job."

How would this cause a crash? I think this may have happened. It was a different type of deployment. However, both deployments update the same directory.

Thanks,

Brian

jed

If it is memory, you can try increasing the heap size. On solaris, something like this:

$owdhome/processod
# -- for Solaris and Linux
JAVA_OPTS="-Xss2m -Xms32m -Xmx512m"

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

bturns

You stated "Also make sure there's not a separate deployment running that's simultaneously attempting to update the same target area as your large deployment job."

What are the repercussions of doing this?

Thanks,

Brian

Migrateduser

If two deployments attempt to update the same target area at the same time, there's a risk they will step on one another as they attempt to commit files. The commit operation entails renaming files, which can cause one deployment to interfere with the other. This has been known to cause hangs.

To avoid this problem, you can employ the concurrency management feature, which was introduced in OD 6. This is a way to queue up deployments on the target that might otherwise collide.

Todd Scallan
Sr. Dir. Product Mgt.
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com