[This is really OT for spamassassin, isn't it? Should we take it off-list?]
On 8 Aug 2009, Linda Walsh spake thusly: > That's w/8 hard disks inside (though not under load...just spinning). OK, you've out-RAIDed me. > Seems to be no way on my machine (Dell is so limiting sometimes), to > turn off unused hard drives, or only spin them up when I want to use > them -- Some are hot-spare or just unconfig'ed, yet they spinup. The disk controller chip would need to make this decision, I suspect, and non-laptop ones are unlikely to be able to. > I'd also prefer the my own *choice* of whether or not to use the > on-disk cache as well as the raid controller's cache. I virtually > never have unplanned shutdowns -- (its on a UPS that will run for > >1hour under its load). > > Maybe some of this control will get into the lk -- or does the bios have > to support everything? Well, you'll never get the option to turn off the Linux kernel's disk cache, because executables and shared libraries run out of it, and dirty pages sit in it before the disk gets to writing them out: but you can tune the balance between cache pages and other pages a bit with /proc/sys/vm/swappiness. Normally it is hugely beneficial to have a big cache, even if you have a caching hardware RAID controller: not only is it often a lot bigger than a hardware RAID controller, but it's at the page level, not the block-device level. Also it's closer to the CPU thus there's less protocol and bus overhead getting stuff out of it. (Of course the hardware RAID controller speeds things up as well.) > Supposedly it has temp and electrical monitoring 'galore', but I can' > even read the DIMM temps. I can on mine! Actually I can read it two different ways, via IPMI and via the temperature sensors directly. They give completely different readings :/ I'm inlined to trust the sensors more than IPMI: half its figures seem to be completely fictional. (Also the IPMI engine often locks up and refuses to do anything until you power the whole machine off and unplug it from the wall. Not what you want in a robust monitoring system.) > I went with the 'eco' power supplies at > 570W That's 'eco'?! > (vs. 870). That's not a power supply, that's an electric fire. > BTW, I'm running at 1333MHZ, so maybe it's a heat dissipation prob and not > power? Nah, that machine is hugely overequipped with cooling, and clocking it down to 1066 and slamming heat-inducing CPU-pounding stuff through it for 24 hours plus gives no problems whatsoever. I'm sure it got hotter in 24 hours of CPU churning than it did in one twenty-minute(!) GCC bootstrap, but the latter, with faster RAM, MCEd on me more than once. > I'm only pulling 157-160 to a max of 260 (didn't have disks How can you tell without specialized power monitoring hardware? > Oblig:sa-users -- I may finally have my 'dead -email' restart problem > solved. I had that too! Well, OK, my ISP broke my email entirely (by changing my static IP without warning, denying me access to my DNS to adjust it accordingly, and breaking the backup MX they provided so that it bounced all email to me with a relaying denied message). Google for 'zetnet breathe fiasco' for more than you could possibly want on the disaster. I got off lightly: other people have had no email or news for many months, and some people lost all their old email too (!) > I added the 'delay time' taken by spamd when running my email inputs (its' > actually my filter delay time, but the max diff between the two is about .01 > seconds, so it's mostly spamd delay -- my stats for today from ~9:30am > are: (n=#emails) > n=4513, min=3.27s, max=208.09s, ave=35.16s, mean=27.43s > > I suppose for RBL's, some of those results are cached in bind as well? Surely.
