On 5/5/07, matthew sporleder <msporleder@gmail.com> wrote:
> On 5/5/07, Fredrik Carlsson <fredrik@netbsd.se> wrote:
> > Matthias Scheler wrote:
> > > On Sat, May 05, 2007 at 07:35:31PM +0000, Fredrik Carlsson wrote:
> > >
> > >> The ulimit values are high already and "ulimit -d `ulimit -d -H`" did
> > >> unfortunately not make any difference.
> > >>
> > >
> > > Looking at it again the program tries to allocate 2.2GB of memory.
> > > I guess this is a program bug in MySQL. If it isn't than you'll need
> > > a NetBSD-amd64 system with about 4GB of memory to do the dump.
> > >
> > >       Kind regards
> > >
> > >
> > The system is a NetBSD-amd64 with 4GB of memory, if I look at 'top' when
> > the dump is running it never shows memory usage beyond 15-20MB for the
> > dump process.
> >
> >   PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
> > 17436 root      57    0    18M   21M CPU/1      0:27 46.89% 45.41% mysqldump
> >   162 mysql     18    0  1950M 1672M sigwai/0 305:53 22.12% 22.12% <mysqld>
> >
> > NetBSD 4.0_BETA2 amd64 x86_64
> >
>
>
> I would be interested in a ktruss of this mysqldump to see what it's
> doing.  Have you tried dumping to stdout and just redirecting?
>

Sorry- Do this first:
Can you also try with options --quick?  The --skip-opt is causing
mysqldump to attempt dumping to memory first and then to disk (I
assume this minimizes the time tables are locked).

If you want dumping to memory and it's failing around 2GB, then maybe
you have a 32bit issue?