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; } } }

Increasingly Slow Datadeployments

nickcolorado

HI,

We are running OD/DD 6.02 on solaris. While doing a datadeploy today to a sybase database the datadeployment started off at a normal pace and then gradualy became slower and slower until it was inserting only about one row every few minutes. This is the first time we have seen this issue. We validated that the database is available and has resources available and also validated that the datadeploy server had plenty of resources. We bounced the datadeploy server thinking this might solve the issue. Once the box was back up, we kicked off another datadeploy and things started out ok but again gradually got slower and slower until it was inserting a row every few minutes.

Has anyone seen this issue before?

Thanks for your assistance!

Nick

Find more posts tagged with

Comments

Migrateduser

I've seen performance degredations with DD before but this seems rather severe. Is the table or tables your inserting to wide? Also, how many rows are in them to begin with? Are they indexed? Are you using delete-tracker?

Dave

Environments:
(1,2) TS6.5, TS6.5SP1 on W2K3
(3) Vignette V7 Portal on Solaris 9

milind

Hii Nick,
I don't have any exp with DD or sybase, but in general i feel that you should check if there is any facility of "Auto-Commit".
If the transactions are not finalize then it may result in slow response.

Let me know if this solves ur issue !

Regards
Milind

nickcolorado

Hi, Thanks for your feedback.

- I do not beleive our tables are too wide.

- They have about 3000 rows of data in them to begin with. T

-They are indexed. Path is the primary key.

-We do have delete-tracker enabled. This has always been enabled for your deployments.

The datadeployments have always worked until recently. Perhaps it is something to do with our recent upgrade to 6.0.2? Maybe a missed configuration?

I'm totally stumped.

Thanks,
Nick

Migrateduser

I'm on OD/DD 6.0.1 so I can't say whether or not this issue is specific to 6.0.2, but are there any logs on the Sybase end that could tell you why this degradation occured?

I would also rope IW support into this. When you find out what the problem is, please post the solution here.

Dave

Environments:
(1,2) TS6.5, TS6.5SP1 on W2K3
(3) Vignette V7 Portal on Solaris 9

jed

Do you have issues with OD/DD crashing at all? We noticed a memory leak when running dbLoader deployments. This has been fixed in a recent patch or SP (I can't remember which.) This could be related if you have not upgraded. Anyway, as OD/DD was running out of memory, deploys would get very slow since the JVM would spend a lot of time trying to garbage collect. To try and debug this, you can set java options in $odhome/processod (line ~207) to print verbose GC information. Something like this:

JAVA_OPTS="-server -Xsqnopause -XX:+PrintClassHistogram -XX:+PrintGCDetails -verbose:gc -Xss2m -Xms32m -Xmx256m"

This will print out information to $odhome/od.log such as:
[Full GC [Tenured: 1137K->1137K(349568K), 0.1139142 secs] 1137K->1137K(519296K), [Perm : 9798K->9798K(16384K)], 0.1140466 secs]
[Full GC [Tenured: 1137K->1116K(349568K), 0.1149571 secs] 1153K->1116K(519296K), [Perm : 9798K->9796K(16384K)], 0.1150803 secs]
[Full GC [Tenured: 1116K->1116K(349568K), 0.1133578 secs] 1116K->1116K(519296K), [Perm : 9796K->9796K(16384K)], 0.1134792 secs]
[Full GC [Tenured: 1116K->1118K(349568K), 0.1123890 secs] 1244K->1118K(519296K), [Perm : 9796K->9796K(16384K)], 0.1125088 secs]

Additionally, you can increase the amount of memory given to the JVM. This may delay the issue. Example:
# take up to 2 gigs of memory
JAVA_OPTS="-server -Xsqnopause -XX:+PrintClassHistogram -XX:+PrintGCDetails -verbose:gc -Xss2m -Xms512m -Xmx2048m"

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

nickcolorado

Hi All,

I fixed the issue by modifying the memory allocated to the opendeploy/datadeploy java process. To allocate more memory we modified the file

opt/Opendeploy/OpenDeployNG/processod to now read:

#solaris or linux
JAVA_OPTS="-Xss4m -Xms512m -Xmx512m"

Thanks for everyones input!

jed

BTW: SP1 fixed the memory leak:

IWOVopendeploy.6.0.2.1.0.SP1.Build52162.SunOS.tar.gz
bug 61072: datadeploy memory leak occurs in OpenDeploy 6.0.2

If you have not installed that, you may just be delaying the issue.

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