On Fri, 2003-11-07 at 15:49, XOR wrote:
> ...which leads me to what I was considering. What about mounting
> the "/var/spool/postfix/incoming" queue and "/var/spool/postfix/active"
> queue as tmpfs with a max filesystem size of about 500MB a piece. I would
> mount the filesystem on boot in "/etc/fstab" (obviously) and then make the
> subdirectories needed in the queues ("A" through "0" - hex - they remain
> static as far as I can tell) then "chown" and "chmod" them to the
> appropriate owner and permissions in the PostFix startup script before
> PostFix actually starts. All file access in these two directories would be
> in physical memory, would take the load completely off of the disks, and be
> blazingly fast... as long as tmpfs doesn't try to use swap space in case of
> a physical memory shortage (which there most likely wouldn't be since
> there's a ton of memory in these boxes). Hell, even if there was a physical
> memory shortage and tmpfs had to use swap space, it would probably still be
> faster than reading and writing from/to the normal ext3 filesystem -
> according to a whitepaper over @ IBM that I read concerning tmpfs
> performance. The only downside of this setup I can think of is that in the
> very unlikely event of a server crash, all of the mail that was stored in
> the PostFix "incoming" and "active" queues would be lost. Poof. This,
> however, is an acceptable risk according to management.
> Thoughts?
Sounds like a decent solution (if it works). We used to do similar
things with IO back when I worked at Cidera and had to maximize both
usenet (solid state disks) and caching (ramfs on FreeBSD) for
high-performance feeds over satellite. Our stuff could always be
retransmitted via peers, so loss/recovery wasn't a huge problem for us.
As long as your management thoroughly understands the risks involved, I
don't see a problem.
--
Jason Dixon, RHCE
DixonGroup Consulting
http://www.dixongroup.net
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
