Re: /tmp getting full after upgrade

Tommi Lätti wrote:
> On Tue, Jul 24, 2007 at 09:53:00PM +0200, Paul J
Stevens wrote:
>> Tommi,
>>
>> I'm pretty sure it's something subtle between gmime
and libc. As a work
>> around, please tune MAXCONNECTS to something like
10 or 100, whatever it
>> takes to prevent the file descriptor leakage
overflowing your tmp
>> filesystem.
> 
> Setting it to 50 did the trick, 100 was still a bit too
much. Will this affect people who have loads of directories
under the Inbox?

One thing has nothing to do with the other. We are using a
filesystem based 
stream when parsing messages, so everytime a message is
stored or retrieved a 
filehandle is opened in /tmp, the message is streamed onto
it, read from it, etc...

The MAXCONNECTS setting will make sure that a dbmail daemon
is restarted after 
handling that many client sessions (login, command, command,
logout). A new 
daemon will be forked immediately when such a daemon is
reaped.

> 
> There seems to be a new gmime version available, I'll
try it tonight after the people leave work.

First try changing the size of your /tmp

> 
> libc comes with the freebsd base system (which I
upgraded earlier with no problems with imapd) so hopefully
it's the gmime side of things.
> 
>> Just for the record, what kind of tmp are you
running (filesystem and size)?
> 
> /tmp is bit over 200 megs and is UFS.
> 

That's way too small. That means /tmp will overflow if
dbmail is processing 200 
megs of email at a time (lmtp+pop3+imap).

The whole idea of using a filebased stream, rather than a
memory based stream 
was that we want to be able to handle very large messages
with running out of 
memory too fast. Disks are cheaper than RAM, and I assume
you have more than 
200M ram, right?

Of course the price to pay is speed, so I think we'll end up
making the 
selection of the type of gmimestream a config option.

-- 
  
____________________________________________________________
____
   Paul Stevens                                      paul at
nfg.nl
   NET FACILITIES GROUP                     GPG/PGP:
1024D/11F8CD31
   The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail

Paul J Stevens wrote:

>> /tmp is bit over 200 megs and is UFS.
>>
> 
> That's way too small. That means /tmp will overflow if
dbmail is 
> processing 200 megs of email at a time
(lmtp+pop3+imap).

Well, it has worked on multiple servers for over 5 years
now, some of 
them web server, some do very nasty java stuff. I've never
ran out of 
/tmp space before.

200+ megs was also freebsd's 'default' years back if I
remember 
correctly. Now it's something like 1 gig.

> The whole idea of using a filebased stream, rather than
a memory based 
> stream was that we want to be able to handle very large
messages with 
> running out of memory too fast. Disks are cheaper than
RAM, and I assume 
> you have more than 200M ram, right?
> 
> Of course the price to pay is speed, so I think we'll
end up making the 
> selection of the type of gmimestream a config option.

Would be very nice. I'd like to re-locate the temp files
dbmail makes to 
another area since increasing the /tmp is pretty much out of
the 
question. Unless I rebuild the server.

Maybe not so bad idea, I've been itching to try out the new
ZFS 
implementation.

Aaron:

The tmpfs is also a very very very nice thing, works
wonderfully on my 
Solaris boxes  The only
catch after that is to have 4G+ of memory for 
it to be really useful.
_______________________________________________
DBmail mailing list
DBmaildbmail.org
htt
ps://mailman.fastxs.nl/mailman/listinfo/dbmail