Dumpfile-to-rt-3.0 (from 1.23) leaks memory whenimporting into Oracle 9.0.2.0.1 (and 9.0.2.0.4)

Fortunately, memory consumption stayed stable at 159MB for the duration of
the ticket stage of the import script. It seems to only grow during
user/group creation from the metadata.

-DarrenFrom: “Darren Nickerson” darren@dazza.org
To: rt-users@lists.fsck.com
Sent: Sunday, February 29, 2004 8:10 PM
Subject: [rt-users] dumpfile-to-rt-3.0 (from 1.23) leaks memory
whenimporting into Oracle 9.0.2.0.1 (and 9.0.2.0.4)

Folks,

I thought I’d give the Oracle support in the latest release from the
Bestpractical sweatshop a try :wink:

I’m seeing the dumpfile process grow at an alarming rate as it’s creating
users in our oracle instance. This is just a crude estimate, but I’d say
it’s consuming something like an additional 100k per user created. I’m at
a
44MB process, and I’m only on names beginning with ‘f’! Scratch that, …
65MB and I’m on ‘j’. 91 MB, … on ‘n’ now.

I’ve seen leaks in the OCI libraries of Oracle 9.0.2.0.1 before, so we
upgraded to 9.0.2.0.4 (latest from Metalink) this weekend to see if that
would fix the problem. Preliminary testing suggests an improvement:
whereas
we were somewhere around 600 MB when the import completed importing users
and moved on to tickets, we’re already on ‘r’ now and only at 101MB.

I also bit the bullet and updated to perl-5.8.3 to try to solve a separate
import problem (which I may post if I can’t work through it), so this may
have also affected the results we’re seeing now.

Notwithstanding the clear improvement, we’ve still got a problem - I don’t
think we’ll complete an import without exhausting swap and seriously
thrashing the box. Anyone else seeing this? Can anyone offer any
suggestions
on how to actually get a several-thousand ticket import done without
configuring multiple gigs of swap and letting it churn & grind for a few
weeks?

-Darren


rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users Archives

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm