Re: [Pan-users] Re: Feature request: CLI operation

[Paul Crawford]

On 29/03/11 09:09, Ron Johnson wrote:
> On 03/29/2011 02:12 AM, Paul Crawford wrote:
> > On 29/03/11 07:33, Ron Johnson wrote:
> > <snip>
> > > 5 hours...
> > >
> > > $ date && pan --no-gui headers:alt.binaries.dvd ; date
> > > Mon Mar 28 20:25:33 CDT 2011
> > > terminate called after throwing an instance of 'std::bad_alloc'
> > > what(): std::bad_alloc
> > > Aborted
> > > Tue Mar 29 01:27:17 CDT 2011
> >
> > That sounds like it ran out of memory.
>
> Exactly.
>
> > Are you running 32-bit or 64-bit,
> > and what are your machine's limits (RAM & swap space)?
>
> It's 32-bit. Running "top" clearly shows pan's memory usage (RES)
> growing and growing. At about 3GB (a processes' address space in x86) it
> barfs.

Well we know now what it is!

Do you have a 64-bit CPU machine (e.g. I do, but run 32-bit Linux for 
greater compatibility and due to only have 2GB RAM)?

If so you could boot off a 64-bit live CD, set enough swap space and 
just let it crunch away.

> > Of course it might be a bug/design flaw where a list grows
> > larger/quicker than it really needs to for the element size & number of
> > elements.
>
> Not a bug per se, but a consequence of the design decision to fetch all
> of a group's headers into RAM before flushing them to disk. Never
> occurred to them that a News provider would retain all messages.

Yes, what seemed like a good enough idea at the time.

Funny how a decade ago it seemed like virtually nothing would need more 
than 32-bit address space, and now we can find something like reading a 
news group where the only _simple_ solution is to use the 64-bit address 
version.

Paul