Slashdot Mirror

My slides relevant to this discussion can be found at http://www.shub-internet.org/brad/papers/dihses/ and http://www.shub-internet.org/brad/papers/sistpni/.

And yes, Nick Christenson has been a long-time friend and co-author of mine.

Feel free to contact me directly if you want some referrals.

My slides relevant to this discussion can be found at http://www.shub-internet.org/brad/papers/dihses/ and http://www.shub-internet.org/brad/papers/sistpni/.

And yes, Nick Christenson has been a long-time friend and co-author of mine.

Feel free to contact me directly if you want some referrals.

I've always preferred to call it shub-internet. I sacrifice my bits to it daily.

These numbers are great, but only tell us a little about reliability or "real world" performance. When I did testing on these file system I used all the benchmarks here, plus a benchmark called postmark. This benchmark utility was released into the public domain by Net App and has to be one of the better "real world" benchmark suites.

The problem that we had with JFS during testing is that we had kernel panic with very large files. Thus we chose XFS - which has done an excellent job. I'm sure glad that the XFS file system has been merged into the 2.6 kernel, no more patching the 2.4's!

For more benchmarks on other file systems using postmark check out This

I can't speak for what you had intercourse with, but the spongy jelly I had sex with last night was no inanimate jelly-in-a-cup from Japan!

My jellied pleasure trove was a shoggoth, and I swear, she said she was 18! (Oh, sure, it wasn't until after we were necking in the back of her 1657 Ford Thunderpseudopod overlooking a fungus garden on Yuggoth that I discovered she'd meant 18 aeons, but by then my brain had been eaten, and I didn't mind as much.

(Never trust a chick you meet through Shub-Internet :-)

Here are a few places to check.
The article describing how it was done. It's here as well.

The source and binaries are at http://arcade.kvinesdal.com/cyberpatrol.html.

These are all personal sites, so be gentle.

Share and enjoy.

{PS - the last link was reverting to /. - puzzling}

And my mirror can be found at http://www.shub-internet.org/cp4/cp4 break.html.
--
Brad Knowles

I have put up a mirror at http://www.shub-internet.org/cp4/cp4 break.html.
--
Brad Knowles

My mirror is at http://www.shub-internet.org/cp4/cp4 break.html.
--
Brad Knowles

My mirror is available at http://www.shub-internet.org/cp4/cp4 break.html.
--
Brad Knowles

Alternatively, go straight to http://www.shub-internet.org/eu/ and download them all for yourselves.

Please mirror these files widely, so that my poor little server isn't slashdotted out of existence!
--
Brad Knowles

Alternatively, go straight to http://www.shub-internet.org/eu/ and download them all for yourselves.

Please mirror these files widely, so that my poor little server isn't slashdotted out of existence!
--
Brad Knowles

I disagree. While for the vast majority of people, there is no technical reason why sendmail should be preferred over other MTAs, there are cases where more obscure things need to be done and sendmail is simply the only functional choice.

I can do things with sendmail rewrite rules that are simply impossible (or at least *extremely* difficult) in other MTAs. This is why postfix is only 99% sendmail-compatible, since that last 1% is a killer.


Of course, sendmail *is* the best documented MTA in the world (it actually has two books written on the subject, Sendmail: Theory and Practice by Avolio and Vixie, and the definitive reference sendmail (now in it's second edition) by Bryan Costales with Eric Allman.

Then there's the increased available online documentation, both the FAQ, and my own Sendmail Performance Tuning for Large Systems paper that I wrote and presented at SANE'98.

While perhaps not strictly a technical reason, available documentation (or the lack thereof) is a very strong motivating factor as to why many people choose to select particular products, SMTP MTAs included.

You are correct that you should be doing analysis of your system to identify bottlenecks and then work to eliminate them. However, this should also include the application level, as well.


I can't speak for how one would go about doing application-specific tuning for things specific to Exim, but I find that many MTAs share the same problems. I'd suggest going to the Sendmail Performance Tuning for Large Sites paper that I wrote and presented at SANE'98, and see what of those problems (and solutions) might be applicable to your situation.

It is entirely possible that you could end up tuning the system performance enough that you don't even need to buy any additional hardware at all, just change the configuration of the software and OS you already have.


That said, if you've done all this and you still have problems, you probably do need to buy some new hardware. If that new hardware you need to buy turns out to be disk storage, Sun will be glad to sell you a StorEdge system that will implement RAID levels 0, 1, and 5 in hardware.

This would probably be the simplest and easiest solution to implement on a Sun machine, since the people who sold and installed the machine originally can help you with the expansion. However, it's likely to be rather expensive from a price/performance perspective. Note that Sun OEMs their hardware from SymBios/LSI Logic, and you can buy higher-end equipment direct. See http://www.metastor.com/ for more info.

If even the MetaStor hardware isn't enough for you, then you might want to consider vendors such as EMC and comparable units from Hitachi Data Systems. For my part, the HDS equipment can have a larger cache (up to 16GB in some units), can segment the cache so that different hosts get their own dedicated slice (which EMC can't do), and overall seems to simply be more intelligently implemented.

If you were in Europe, I would suggest looking at Comparex, since they are the licensed HDS VAR for this region.