On Thursday 11 July 2002 12:14 am, J C Lawrence wrote: > Tim Crouch <[EMAIL PROTECTED]> wrote: > > Obviously disk size will be number one on the priority, but I am > > looking for what you would run this on. OS will be RH Linux 7.3 the > > hardware will be from Dell. I am leaning towards the following: > > > > Dell PowerEdge 350 1u rack server 850MHz Celeron, 128KB L2 512 MB > > SDRAM 20 Gig IDE boot drive 120 GIG IDE data (for archiving, data, & > > web) RH Linux 7.3 > > Guessing at your numbers I'd be a tempted to: > > a) Add more RAM. Number of queue runners for your MTA
Here's a silly question: Is it worth considering *really* upping the RAM, say to two gigabytes, and then putting /var/spool/mqueue on a RAM disk? Downside: Lose any outbound mail in the event of a crash. Upside: Speed. Obviously something that Mr. Crouch will have to evaluate in light of how important it is not to lose outbound mail. You'd also have to make a "hook" in the SysVinit startup/shutdown scripts so that the RAM disk gets archived on normal shutdown and restored on startup. Another approach, much easier: Buy a lot of RAM, and rely on Linux using the excess as disk cache. This is probably a much better idea. I suspect my first paragraph above is not practical. I toss it out onto the list not so much in expectation of anyone trying it, but just to see if anyone thinks it's even worth experimentation. I would never even consider this for "regular" email service, but in many contexts lists are considered a lower priority with regard to reliability. And even if some outbound messages were lost in the (infrequent) crash scenario, they would still be available in the archives. > b) drop the CPU speed if it will save any money, though I suspect > that's as low as you can buy these days. With respect, I disagree. The price difference between CPU speeds below about 1 GHz is insignificant. It's nice to have some CPU headroom so that you can do things like compile the next version of Mailman on the same machine, in a test directory, without impacting production. And there will be peak CPU usage times, such as at night when the logrotate job runs. Speaking of which, disabling "locatedb" on this machine is probably a good idea. A second reason for not short-changing this machine's processor: Any server in this kind of heavy-duty production will be tricky to upgrade from a logistical standpoint. If you build in some headroom, you postpone for more years the need to migrate all of this to a new machine. > c) go SCSI with /var/spool/MTA, /var/log, and /var/www on different > spindles. Yes, definitely. Also, for a system that will have this many files on it, consider using a journaling filesystem rather than ext2. I have had superb success with Reiserfs, but there are also IBM's JFS, SGI's XFS, and the ext2-compatible ext3. Reiserfs has significant performance improvement over ext2 and ext3, especially on small files, and it might be a good choice for this system. If you have an abrupt shutdown, you will be very glad *not* to have to wait hours for fsck to run on a 120 gig drive array. Whatever you choose to do with regard to filesystems, J C Lawrence has given you good advice on the drives. Buy SCSI, not IDE, and go for the fastest RPM and seek times you can find. I/O throughput and I/O latency will be your bottleneck, not CPU speed. Don't short-change your network connectivity, either, and be sure to put in a second Ethernet adapter so that you can fail over to it if something happens to the primary adapter. Just out of curiosity, what are you planning to do for backup media? You may need a secondary SCSI controller channel to prevent contention for bus bandwidth during large backup runs. It could be a lower-cost SCSI board than the primary, probably. Scott -- -----------------------+------------------------------------------------------ Scott Courtney | "I don't mind Microsoft making money. I mind them [EMAIL PROTECTED] | having a bad operating system." -- Linus Torvalds http://4th.com/ | ("The Rebel Code," NY Times, 21 February 1999) | PGP Public Key at http://4th.com/keys/courtney.pubkey ------------------------------------------------------ Mailman-Users mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
