On Fri, 2005-02-11 at 13:23, Magnus Sundberg wrote: > > On Fri, 2005-02-11 at 11:01, Aaron Stone wrote: > >> On Fri, Feb 11, 2005, Hans Kristian Rosbach <[EMAIL PROTECTED]> said: > [snip] > >> > 2. We can use a tempfile > >> > Now, this would lead to more database calls depending on block size > >> > and it would probably lead to worse performance. > >> > >> So wait -- the MTA takes the message, puts it in a file to queue for > >> delivery. Then the MTA reads the file either into a pipe or tcp > >> connection > >> to dbmail. Then DBMail puts the message into a file to piece into the > >> database. So for every message, we put it on disk twice and into memory > >> three times... > > > > Well, actually the file can be opened with flags that hint to the OS > > that this is indeed a temporary file that might just be stored into > > memory cache and never even touch the disk (OS will decide depending > > on wether enough memory is free and how long it has lived in memory). > > > > Another option is to have the temporary files on a RAMFS file system
And that is guaranteed to give you problems. RamFS is _ONLY_ residing in RAM. Thus all the tempfiles use up your much needed ram, and can not be swapped out. Shmfs is much better for this usage since it can be swapped out. But there is often a ~128MB default limit on shm size on most distros, and if you are running postgresql it also want to use it. But both these solutions are less effective than using regular files in /tmp when giving the kernel info that this is indeed just a temporary file. It will then be treated appoximatly the same as in shmfs. Except it won't explicitly eat resources needed elsewhere. -HK
