in reply to Sybase::BCP & iowait

Let me state upfront that I have no experience whatsoever with Sybase::BCP (or Sybase for that matter).

That said, if you are sure that the disk writes happen when you return from the sub (i.e. after your warning message), than I suspect that they are due to the destruction of one of your lexically scoped variables. $count is an unlikely candidate, so that leaves $bcp. Perhaps the destructor of Sybase:BCP is doing the spurious disk writes - it might be committing your changes. Is there no specific method to commit your changes to the DB? Then again, calling such a method would only move the disk writes a bit earlier in time, so that would not help much. BTW, can the amount of data you are entering into the DB justify the amount of disk activity you observe?

Not much help, I'm afraid, but perhaps this might point you in the right direction (in a vague, fuzzy kind of way :) ). Have a look at the Sybase::BCP destructor.

CU
Robartes-

Update: You might of course simply be experiencing a swapstorm, as fglock suggests, in which case you are probably out of luck.

Replies are listed 'Best First'.
Re: Re: Sybase::BCP & iowait
by Tanalis (Curate) on Nov 12, 2002 at 15:08 UTC
    The $bcp -> bcp_batch command commits the data - in this case every 100 rows.

    The amount of data could cause a block on a disk write - I've seen similar with Data::Dumper when trying to output a hash of similar size to disk.

    The memory usage doesn't seem to be excessive .. this was one of the first things I looked at, but it simply appears to block on a disk write.

    I'll do as you suggest and look at the BCP destructor; hopefully that'll shed a little light on the issue.

    Cheers for the help ..
    -- Foxcub

[reply]
[d/l]

In Section Seekers of Perl Wisdom