Strange memory hog^H^H^Hbehaviour with v0.30.

Strange memory hog^H^H^Hbehaviour with v0.30.

[Per Persson]

I start up gnus and it connects to two servers and reads my mail with
nnfolder, I read some mails and misc.kids.breastfeeding. Emacs now
takes around 12MB of memory and I can live with that.

Then I see I got this new mail from an old friend which I REALLY want
to read so I hit 'g' to read it... then something strange happens...
Emacs decide to go from 14MB to 32MB memory usage...

 2648 pp         3   0 32608 24584 1600 R     2.3 62.5  0:29 emacs

I use linux-1.3.62 and emacs-19.30, had the same problems on a
solaris-2.3 machine... the problems was less evident on the sun (it
just used around 27MB and not 32MB). This 'memory leak' doesn't heal
itself but it doesn't leak anymore. Any ideas on what I should try?
(Don't tell me Solamis and linsux sucks because I already know it).

-- 
anum meum aperies, asperge me spermate tuo et inquinabor
url; http://pfawww.pp.se/~pp/   email; <pp@pfawww.pp.se>
phone#'s;  work/home/fax: +46 (0)18 100899/247473/103737

Re: Strange memory hog^H^H^Hbehaviour with v0.30.

[Steven L Baur]

>>>>> "Per" == Per Persson <pp@pfawww.pp.se> writes:

Per> I start up gnus and it connects to two servers and reads my mail with
Per> nnfolder, I read some mails and misc.kids.breastfeeding. Emacs now
Per> takes around 12MB of memory and I can live with that.

Per> Then I see I got this new mail from an old friend which I REALLY want
Per> to read so I hit 'g' to read it... then something strange happens...
Per> Emacs decide to go from 14MB to 32MB memory usage...

Per>  2648 pp         3   0 32608 24584 1600 R     2.3 62.5  0:29 emacs

Per> I use linux-1.3.62 and emacs-19.30, had the same problems on a
Per> solaris-2.3 machine... the problems was less evident on the sun (it
Per> just used around 27MB and not 32MB). This 'memory leak' doesn't heal
Per> itself but it doesn't leak anymore. Any ideas on what I should try?
Per> (Don't tell me Solamis and linsux sucks because I already know it).

Gnus virtual memory usage has been terrible (for me) with all versions
after v0.26, on both XEmacs 19.13 and Emacs 19.30.  I'm starting to
get better behavior from XEmacs with the most recent versions (it
grows to the unusable stage a bit slower).  This eliminates the only
thing I liked about running Gnus on GNU Emacs.

I was used to having a stable Emacs with Gnus at around 6MB virtual,
and XEmacs with Gnus at around 8MB virtual (measured from ps -ux
output).  This doesn't happen anymore.

Do you have 19.30 compiled to take advantage of the new mmapped malloc
on Linux?  I had hoped that along with the rewritten scheduler for the
1.3 kernels would clear up the thrashing that the 1.2.13 kernel so
readily goes into.

I wonder if it has something to do with nnfolder.  I haven't looked at
that code at all, and the bad behavior I've had did begin around the
time that the default ``Gcc: nnfolder:misc-(mail|news)'' was put in.
I've already verified that (on Linux anyway), the degraded virtual
memory behavior is independent of a.out -vs- ELF binary format.

Regards,
-- 
steve@miranova.com baur
Unsolicited commercial e-mail will be proofread for $250/hour.
Andrea Seastrand: For your vote on the Telecom bill, I will vote for anyone
except you in November.

Re: Strange memory hog^H^H^Hbehaviour with v0.30.

[Per Persson]

Steven L Baur <steve@miranova.com> writes:

>Gnus virtual memory usage has been terrible (for me) with all versions
>after v0.26, on both XEmacs 19.13 and Emacs 19.30.  I'm starting to
>get better behavior from XEmacs with the most recent versions (it
>grows to the unusable stage a bit slower).  This eliminates the only
>thing I liked about running Gnus on GNU Emacs.

It's the same thing for me, I use gnus because I get both mail and
news from the same memory cost... I though. Is older version of
september gnus archived somewhere?

>Do you have 19.30 compiled to take advantage of the new mmapped malloc
>on Linux?  I had hoped that along with the rewritten scheduler for the
>1.3 kernels would clear up the thrashing that the 1.2.13 kernel so
>readily goes into.

Actually, I don't know how I would take that advantage. I didn't like
Linux at all when I started working at Bahnhof and the machine I just
started to use had SlackWare installed on it so I just upgraded the
kernel to one with a swap daemon (1.3.57) and I haven't played around
much more with... just installed emacs-19.30 and gcc-2.7 (and 2.6.3)
and screen and all the elisp code I want to use. I don't ever run X as
I find it to be yet another unwanted memory hog, I do much better
without netrape and other such things. (I guess I'm ranting now).

The problems are similar on both Solaris and Linux so it isn't OS
dependent anyway.

/pp.

Re: Strange memory hog^H^H^Hbehaviour with v0.30.

[Lars Magne Ingebrigtsen]

pp@pfawww.pp.se (Per Persson) writes:

> Is older version of september gnus archived somewhere?

<URL:hhtp://www.ifi.uio.no/~larsi/ding-old> stores lots of old Gnus
versions all the way back to (ding) Gnus 0.5.  

Which reminds me -- does anybody happen to have a (ding) Gnus 0.1 tar
file hanging around?  I certainly don't, but it would be nice to have
a copy...  You know, for historical purposes.  :-)

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Strange memory hog^H^H^Hbehaviour with v0.30.

[Lars Magne Ingebrigtsen]

Steven L Baur <steve@miranova.com> writes:

> I wonder if it has something to do with nnfolder.  I haven't looked at
> that code at all, and the bad behavior I've had did begin around the
> time that the default ``Gcc: nnfolder:misc-(mail|news)'' was put in.
> I've already verified that (on Linux anyway), the degraded virtual
> memory behavior is independent of a.out -vs- ELF binary format.

I've seen some memory-hoggish behavior once in a while, but I have
been totally unable to pin-point what's going on.  I even hacked into
the Emacs sources to get a trace of memory allocations, but that
didn't yield any useful results. 

Gnus seems to be behaving itself lately (for me) -- I have noticed
nothing out of the ordinary.  There definitely is something odd going
on somewhere.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Strange memory hog^H^H^Hbehaviour with v0.30.

[Per Persson]

larsi@ifi.uio.no (Lars Magne Ingebrigtsen) writes:

>I've seen some memory-hoggish behavior once in a while, but I have
>been totally unable to pin-point what's going on.  I even hacked into
>the Emacs sources to get a trace of memory allocations, but that
>didn't yield any useful results. 

I've 'tracked down' the memory hog I've encountered. In releases
previous to v0.27 you would, eventually, see the same thing but with
v0.27 and after you're bound to hit the roof right away.

What causes this? Reading mail does. When you get new mail ALL
mailfolders will be read into emacs for some weirdo reason...  My
mailfolders are mighty big. They never get killed either so I have to
kill them by hand.

I think a little 'gnus-nnfolder-kill-folder-after-use' would come in
handy for people with less then 1GB RAM memory. I don't notice any big
difference in CPU cycles or wasted time if I kill all buffers by hand
and let gnus reread them when I need to have them.

Please mail the 'bug' patch to me as I can't upgrade to anything after
v0.30 yet. I still get the same weird mail lossage in anything after
v0.31. I'm sorry I don't have time to fix this myself but I just have
to much damn work. :I

--
anum meum aperies, asperge me spermate tuo et inquinabor
url; http://pfawww.pp.se/~pp/   email; <pp@pfawww.pp.se>
phone#'s;  work/home/fax: +46 (0)18 100899/247473/103737

Re: Strange memory hog^H^H^Hbehaviour with v0.30.

[Lars Magne Ingebrigtsen]

pp@pfawww.pp.se (Per Persson) writes:

> I've 'tracked down' the memory hog I've encountered. In releases
> previous to v0.27 you would, eventually, see the same thing but with
> v0.27 and after you're bound to hit the roof right away.
> 
> What causes this? Reading mail does. When you get new mail ALL
> mailfolders will be read into emacs for some weirdo reason...  My
> mailfolders are mighty big. They never get killed either so I have to
> kill them by hand.

Or you could say `(setq gnus-secondary-select-methods '((nnfolder "")))'.
Then this shouldn't happen, I think.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Strange memory hog^H^H^Hbehaviour with v0.30.

[Per Persson]

larsi@ifi.uio.no (Lars Magne Ingebrigtsen) writes:

>Or you could say `(setq gnus-secondary-select-methods '((nnfolder "")))'.

I do.

>Then this shouldn't happen, I think.

It does.

/pp, do be do be do.

Re: Strange memory hog^H^H^Hbehaviour with v0.30.

[Lars Magne Ingebrigtsen]

pp@pfawww.pp.se (Per Persson) writes:

> larsi@ifi.uio.no (Lars Magne Ingebrigtsen) writes:
> 
> >Or you could say `(setq gnus-secondary-select-methods '((nnfolder "")))'.
> 
> I do.
> 
> >Then this shouldn't happen, I think.
> 
> It does.

Hmn...  Is `gnus-read-active-file' set to nil?  If that's the case, I
think I've come up with a fix for 0.39.

-- 
  "Yes.  The journey through the human heart 
     would have to wait until some other time."

Re: Strange memory hog^H^H^Hbehaviour with v0.30.

[Per Persson]

larsi@ifi.uio.no (Lars Magne Ingebrigtsen) writes:

>Hmn...  Is `gnus-read-active-file' set to nil?  If that's the case, I
>think I've come up with a fix for 0.39.

Umm, no, sorry; it's 't'.

/pp.