Re: Purchasing the correct hardware: dual-core intel? Big cache?
Bill start with looking the DB design - I;ve had batch runs go from 5 days down to 1/2 day purely by tuning the SQL. I'm not kidding, all the DB tuning quides say look at the SQL/design first, then look at hardware like disk/data layout, then finally the CPU. There's lots of info about tuning on Postgress, use this, you'll get more out of the app this way than spending money chucking hardware at it. -- martin On 4/25/06, Bill Moran <[EMAIL PROTECTED]> wrote: > > On Tue, 25 Apr 2006 13:28:50 +0100 > "Martin Hepworth" <[EMAIL PROTECTED]> wrote: > > Bill > > > > if the database is CPU dependant I'd look at tuning the queries/indexes > and > > that stuff...it really shouldn't be CPU bound. > > That's in progress, and it's going to be an ongoing process as the > application goes through versions. > > Fact is, with 4G of RAM most of the data sits in RAM, so reads incur > no or little IO. With high-end SCSI disks in RAID-10 and a battery- > backed cache, burst writes are cached, thus lightening fast, and > we've been unable to run the application hard enough to saturate > the SCSI bus so far. > > So ... the current bottleneck is CPU. > > > > > -- > > martin > > > > On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote: > > > > > > On Mon, 24 Apr 2006 23:03:59 +0100 > > > "Martin Hepworth" <[EMAIL PROTECTED]> wrote: > > > > > > > Bill > > > > > > > > depends on the application itself, but more RAM and the disk layout > > > (RAID) > > > > will be more important than the CPU. Also depends on how write-heavy > the > > > > apps are... > > > > > > Thanks for the feedback, Martin. > > > > > > I'm fully aware of the app-dependency - what I'm looking for is a way > > > to test the application. I've got 3 different clusters available for > > > testing, but I'm not sure how to tell if the cache is getting used > > > heavily or not. > > > > > > I've already determined that the database server is CPU-bound under > > > our test load. With high-speed SCSI disks and battery-backed RAID, > > > there's not enough IO to stress the disk subsystem. RAM is almost a > > > non-issue. With the machine stressed at full load, it's only using > > > 1/8 of the available RAM. > > > > > > So, my current bottleneck is CPU power. And the boss has asked me > > > for the best way to overcome this bottleneck. We're looking at either > > > the same CPUs we already have, but with _huge_ caches (8m) - or going > > > with more CPUs by getting true dual-core pentiums. > > > > > > The question this all pivots on is will 8M of cache be a significant > > > improvement? If not, then we're going with the dual-core CPUs. What > > > I'd like is some way to take an existing system and determine how > often > > > the cache is getting invalidated, so I can make some guesstemate as to > > > whether more cache will help or not. > > > > > > > > > > > -- > > > > martin > > > > > > > > On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > I've been asked to make some hardware recommendations, I'm hoping > some > > > > > folks on the list can make some suggestions. > > > > > > > > > > We're looking hard at getting either Intel dual-core procs, or > getting > > > > > hyperthreaded procs with huge (8M) caches. > > > > > > > > > > We currently have a few dual proc Intel HT machines that we can > test > > > > > out our workload on, and I'm trying to get a feel for how to > determine > > > > > if a larger cache size will generate better performance than > replacing > > > > > HT procs with full-blown dual-core procs. We're looking at the > 6850 > > > > > from Dell, which supports both processor families: > > > > > > > > > > > > > > http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850?c=us&cs=555&l=en&s=biz > > > > > > > > > > The goal for these machines is to serve out PosgreSQL databases to > as > > > > > many Apache+php front ends as we can hang off each one. So we're > > > trying > > > > > to purchase hardware that will create a DB server that can handle > a > > > lot > > > > > of web server front ends. > > > > > > > > > > I have a Dell 2850 (dual HT procs) here that I can use for > testing. > > > > > I'm a little fuzzy on determining how well the cache is working, > so > > > I'm > > > > > stuck on whether or not the 8M cache that's available on the HT > units > > > > > is worth the money or not. Can anyone suggest a testing > methodology > > > > > that will isolate this particular aspect? > > > > > > > > > > -- > > > > > Bill Moran > > > > > Collaborative Fusion Inc. > > > > > ___ > > > > > freebsd-questions@freebsd.org mailing list > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > > > > To unsubscribe, send any mail to " > > > > > [EMAIL PROTECTED]" > > > > > > > > > ___ > > > > freebsd-questions@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > > > To unsub
Re: Purchasing the correct hardware: dual-core intel? Big cache?
Bill Moran wrote: > > > > > > > > I've been asked to make some hardware recommendations, I'm hoping some > > > > folks on the list can make some suggestions. > > > > > > > > We're looking hard at getting either Intel dual-core procs, or getting > > > > hyperthreaded procs with huge (8M) caches. > > > > > > > > We currently have a few dual proc Intel HT machines that we can test > > > > out our workload on, and I'm trying to get a feel for how to determine > > > > if a larger cache size will generate better performance than replacing > > > > HT procs with full-blown dual-core procs. We're looking at the 6850 > > > > from Dell, which supports both processor families: I can't answer your question either but I'd like to raise a couple of questions. If I won't help you I would at least (I hope) learn a little from reactions :-). As far as I know Intel boxes scale quite badly to larger SMP configurations because of at least partially shared FSB which limits memory throughput and which is also consumed great deal by cache coherency maintenance traffic I believe. Dual core may help a little I suppose (I would expect that Intel engineers made memory snooping a little more efficient when accesses are going through one piece of silicon (e.g. the cache coherency traffic's pressure on FSB should be lower between the cores on the same die in comparison to separate cores)). As you may have guessed by now I think that there's some possibility that you would get better performance with AMD Opteron based solution (I know that Dell doesn't normally sell it though) which probably scaler better or even something more "exotic" (Sun Hardware - UltraSparc, T processors). Even when there isn't pressure on the I/O hardware in your case you may have suboptimally configured PostgreSQL. I believe that PostgreSQL processes do not tend to grow much (at least in comparison to other RDBMS engines). I think that the explanation by psql people is that the huge amounts of memory other engines are using is often used for caching the data and that they (psql) believe that the operating system should be doing that (otherwise you waste memory on caching both in the OS and in the application). With huge databases you should at the end become I/O bound (or at least there must be big I/O traffic) and then I would agree with psql people that there's not much point replicating OS caching in the DB engine. But if crucial parts of working data fit into the memory I would expect that storing them in process should be beneficial. I expect there must be at least a little data verification and shuffling before psql uses the pages from the DB files. Maybe the amount of this work is negligible with real disk I/O, but it may play some role when no real disk I/O is involved. Another explanation why PostgreSQL doesn't grow much may be that they use a lot of shared memory and this is in general probably rather scarce resource (at least the users have to configure something rather low-level to have it up and running). What are your needs regarding the SQL engine anyway? Can't the needs be fulfilled by something other than PostgreSQL? I hate to say that, but possibly MySQL? Or can Firebird be better? I don't know firebird much but I think that it is quite full-featured and although it isn't such widespread it has great performance at least in some benchmarks. What about the operating system? I haven't seen FreeBSD mentioned in your question but I suppose you are running it (because you write to a FreeBSD ML). What about Linux? (Open)Solaris? I think when you are in such big need for performance you shouldn't try just one solution. We (FreeBSDers) would of course like to help you to get the best performance from our favorite OS but maybe you will help make FreeBSD better if you find your application runs considerably better on something else and someone may later find the reason. Last I would like to only express my belief that bigger cache may in fact help you but that nobody can probably say it in advance. Regards Michal ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Purchasing the correct hardware: dual-core intel? Big cache?
On Tue, Apr 25, 2006 at 09:59:20AM -0400, Bill Moran wrote: > On Tue, 25 Apr 2006 09:48:21 -0400 > Chuck Swiger <[EMAIL PROTECTED]> wrote: > > > Bill Moran wrote: > > [ ... ] > > >> If you use well optimized applications, you see the larger performance > > >> gain. Poor optimization causes a CPU to chug along, flushing the CPU > > >> cache > > >> often, and slowing things down considerably. > > > > > > I know. That's why I'm so desperately trying to find a way to determine > > > how often the cache is being invalidated - so I can determine whether > > > larger cache sizes (such as 8M) are worthwhile. > > > > Guys, you're confusing two things: > > "flushing the pipeline" vs. "L2 cache hit ratio". > > > > The former happens when branch prediction/speculative execution goes awry > > and > > requires the CPU to clear the pipeline of partially-executed instructions > > and > > backtrack to follow the other path. It is related to optimization quality > > of > > compilers, but is not related at all to how big your L2 cache is. > > > > The size of your L2 cache affects how much data is more local to the CPU > > than > > main memory, and increasing it will improve the L2 cache hit ratio, or, > > equivalently, reduce L2 cache misses. This is affected by some specific > > compiler optimizations (cf "loop unrolling"), but tends to reflect the > > specifics > > of the workload and how much multitasking of different programs you do more > > than > > the compiler. > > Thanks, Chuck. > > What I'm looking for is a way to measure this on the current machines > we're using so I can make a prediction as to whether larger cache > sizes will improve performance. What I'm looking for is some sort of > counter or the like that I can use to tell what my current L2 cache > hit ratio _is_, so I can intelligently speculate as to whether another > 6M of cache is worth the outrageous price. The only way to be certain is to measure the performance of your particular application on the different pieces of hardware and see which one is fastest. There are various methods available to measure the cache behaviour on you current hardware, but none of them is exactly trivial use correctly, and even if you do get useful measurements it can be tricky to extrapolate them to a larger cachesize. If you want to try using the various internal counters most modern CPUs have you can try to read up on the hwpmc(4) or perfmon(4) virtual devices. You could also run the code under some kind of simulator that allows you to record the cache hits and misses for various simulated caches, but doing that can be quite slow. There are several other software based methods that have been proposed and analyzed in various academic papers, but I suspect that most of them (maybe even all) are currently a bit too complicated for an ordinary end-user to apply (and definitely too complicated for me to go into any details here and now.) Some general thoughts: If there are currently very few cache misses then increasing the cache size will not give any noticable performance increase (but I suspect you already knew that.) If you currently have a lot of cache misses the performance would likely be improved by a larger cache, but it is possible (though unlikely) that you would need to increase the cache to as large as 16MB (or even more) in order to see any improvement (it depends almost entirely on the memory access patterns of the application.) In general one usually reaches a point of dimnishing returns when increasing cache size, so unless your workload has an unusual memory access pattern I suspect that you would not see much improvement by moving to an 8MB cache. (But then again it might be that your particular workload would benefit enormously from the larger cache. Impossible to tell for certain without actually trying it.) It might also be worth noting that dual-core CPUs (as I believe was another alternative you were looking at) usually have twice the L2 cache of a corresponding single-core CPU so you will get larger cache this way too. (And the 8MB CPUs you were thinking of I believe has it as an extra L3 cache rather than as an larger L2 cache. L3 cache is almost always slower than L2 cache (but still faster than main memory.) How much your application would benefit from moving to a dual-core solution depends on how well it scales with the number of cores. If you are really lucky it may be that its performance will be almost linear (or perhaps even super-linear) in the number of cores (i.e. dual-core gives twice the performance of a single-core) but it may also be that due to threads contending for various resources performance will only improve marginally. Usually the result is somewhere in between, but again the only way to tell for certain is to actually try it. -- Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freeb
Re: Purchasing the correct hardware: dual-core intel? Big cache?
Bill Moran wrote: On Tue, 25 Apr 2006 09:48:21 -0400 Chuck Swiger <[EMAIL PROTECTED]> wrote: [ ...long explanation snipped for brevity... :-) ] Thanks, Chuck. Most welcome. What I'm looking for is a way to measure this on the current machines we're using so I can make a prediction as to whether larger cache sizes will improve performance. What I'm looking for is some sort of counter or the like that I can use to tell what my current L2 cache hit ratio _is_, so I can intelligently speculate as to whether another 6M of cache is worth the outrageous price. It's possible to write code which tests cache size and latency empirically, but I'm not sure how to obtain the ratio you're looking for directly for your particular workload. Previous experience suggests that large CPU cache helps heavily multithreaded or parallel multiprocess tasks by a lot, but does little to help something like a big database because the amount of data you have to traverse is much larger than will fit into any L2 cache, no matter how big. On the other hand, more L2 cache can provide more significant benefit to a well-tuned database if the indexes or particular frequently-used subqueries fit better into the larger cache... -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Purchasing the correct hardware: dual-core intel? Big cache?
On Tue, 25 Apr 2006 09:48:21 -0400 Chuck Swiger <[EMAIL PROTECTED]> wrote: > Bill Moran wrote: > [ ... ] > >> If you use well optimized applications, you see the larger performance > >> gain. Poor optimization causes a CPU to chug along, flushing the CPU > >> cache > >> often, and slowing things down considerably. > > > > I know. That's why I'm so desperately trying to find a way to determine > > how often the cache is being invalidated - so I can determine whether > > larger cache sizes (such as 8M) are worthwhile. > > Guys, you're confusing two things: > "flushing the pipeline" vs. "L2 cache hit ratio". > > The former happens when branch prediction/speculative execution goes awry and > requires the CPU to clear the pipeline of partially-executed instructions and > backtrack to follow the other path. It is related to optimization quality of > compilers, but is not related at all to how big your L2 cache is. > > The size of your L2 cache affects how much data is more local to the CPU than > main memory, and increasing it will improve the L2 cache hit ratio, or, > equivalently, reduce L2 cache misses. This is affected by some specific > compiler optimizations (cf "loop unrolling"), but tends to reflect the > specifics > of the workload and how much multitasking of different programs you do more > than > the compiler. Thanks, Chuck. What I'm looking for is a way to measure this on the current machines we're using so I can make a prediction as to whether larger cache sizes will improve performance. What I'm looking for is some sort of counter or the like that I can use to tell what my current L2 cache hit ratio _is_, so I can intelligently speculate as to whether another 6M of cache is worth the outrageous price. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Purchasing the correct hardware: dual-core intel? Big cache?
Bill Moran wrote: [ ... ] If you use well optimized applications, you see the larger performance gain. Poor optimization causes a CPU to chug along, flushing the CPU cache often, and slowing things down considerably. I know. That's why I'm so desperately trying to find a way to determine how often the cache is being invalidated - so I can determine whether larger cache sizes (such as 8M) are worthwhile. Guys, you're confusing two things: "flushing the pipeline" vs. "L2 cache hit ratio". The former happens when branch prediction/speculative execution goes awry and requires the CPU to clear the pipeline of partially-executed instructions and backtrack to follow the other path. It is related to optimization quality of compilers, but is not related at all to how big your L2 cache is. The size of your L2 cache affects how much data is more local to the CPU than main memory, and increasing it will improve the L2 cache hit ratio, or, equivalently, reduce L2 cache misses. This is affected by some specific compiler optimizations (cf "loop unrolling"), but tends to reflect the specifics of the workload and how much multitasking of different programs you do more than the compiler. -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Purchasing the correct hardware: dual-core intel? Big cache?
On Tue, 25 Apr 2006 07:59:29 -0500 Derek Ragona <[EMAIL PROTECTED]> wrote: > If your database application is CPU bound, you may need to re-architect the > database. You may need more indexes. You may be calculating values on > queries, rather than storing calculated values. I appreciate your concern about our re-architecting, but we've already got a group focusing on the data model. My current project is to analyze the performance of the app with regard to specific hardware and make recommendations as to what hardware should be purchased for new systems. All I want is a way to track CPU cache usage so I can determine whether larger caches are worth the $$$. > There are many ways to optimize a RDBMS performance, but the first thing to > do is analyze the data model, and how the data is used. Our current data model appears to be as optimized as is reasonable. With this carefully planned data model in use, we run our test framework to load the test server environment, and find that CPU on the database server is the current bottleneck. Thus I need to find a way to speed up _that_ bottleneck. And this boils down to: How can I tell if 2M cache is enough or if larger cache sizes will improve CPU throughput, without investing in the hardware? It may boil down to this being impossible. If that's the case, I'll recommend that we purchase one of the 8M cache systems to test it out. It's a bit of an investment: http://configure.us.dell.com/dellstore/config.aspx?c=us&cs=555&l=en&oc=pe6850pad&s=biz -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Purchasing the correct hardware: dual-core intel? Big cache?
Bill, Never assume . . . Depending on where you got the PostgreSQL, was it in binary form or source. Most binarys are NOT optimized for higher end, more current processors, rather they are optimized for the most common family of CPU's. But if your database application is really CPU bound, I would look at the data model and how your application is accessing and using the data. RDBMS's can be very effiicent, or terribly inefficient. In the worst case you can cause an RDBMS to serially go through every record searching for data or doing a calculation. While a bigger cache may help, as may dual core CPU's, or faster CPU's. In the end, you may only see marginal improvement if the application or database is really where you need to tune things. -Derek At 08:25 AM 4/25/2006, Bill Moran wrote: On Tue, 25 Apr 2006 07:56:03 -0500 Derek Ragona <[EMAIL PROTECTED]> wrote: > Yes, dual core is on average 20% faster than hyperthreaded CPU's. But that > is general benchmark. The range of performance difference is 10% - 30% > depending on the application mix. Thanks. > If you use well optimized applications, you see the larger performance > gain. Poor optimization causes a CPU to chug along, flushing the CPU cache > often, and slowing things down considerably. I know. That's why I'm so desperately trying to find a way to determine how often the cache is being invalidated - so I can determine whether larger cache sizes (such as 8M) are worthwhile. The database server is PostgreSQL. If we find optimization problems with it, we'll definitely work with the PostgreSQL folks to get those problems addressed, but I'm not expecting a lot of poorly-written code in something as mature as PostgreSQL. So, making a (reasonable) assumption that PostgreSQL is well-optimized, I need a way to tell if adding another 6M of cache will improve performance, _before_ we pay for it. That's my question. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Purchasing the correct hardware: dual-core intel? Big cache?
On Tue, 25 Apr 2006 07:56:03 -0500 Derek Ragona <[EMAIL PROTECTED]> wrote: > Yes, dual core is on average 20% faster than hyperthreaded CPU's. But that > is general benchmark. The range of performance difference is 10% - 30% > depending on the application mix. Thanks. > If you use well optimized applications, you see the larger performance > gain. Poor optimization causes a CPU to chug along, flushing the CPU cache > often, and slowing things down considerably. I know. That's why I'm so desperately trying to find a way to determine how often the cache is being invalidated - so I can determine whether larger cache sizes (such as 8M) are worthwhile. The database server is PostgreSQL. If we find optimization problems with it, we'll definitely work with the PostgreSQL folks to get those problems addressed, but I'm not expecting a lot of poorly-written code in something as mature as PostgreSQL. So, making a (reasonable) assumption that PostgreSQL is well-optimized, I need a way to tell if adding another 6M of cache will improve performance, _before_ we pay for it. That's my question. -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Purchasing the correct hardware: dual-core intel? Big cache?
If your database application is CPU bound, you may need to re-architect the database. You may need more indexes. You may be calculating values on queries, rather than storing calculated values. There are many ways to optimize a RDBMS performance, but the first thing to do is analyze the data model, and how the data is used. -Derek At 07:47 AM 4/25/2006, Bill Moran wrote: On Mon, 24 Apr 2006 18:31:46 -0500 Derek Ragona <[EMAIL PROTECTED]> wrote: > You can get better information directly from intel's website on > motherboards and CPU performance. Dual core is faster than hyperthreaded > CPU's usually about 20% if you use the larger CPU cache models. I don't follow you here. Are you saying that dual core is about 20% faster than hyperthreaded with larger cache? > However with a RDBMS as the primary usage, I would look for more ways to > optimize the system. I would look to use a RAID array with an add-on card > (or zero-chanel add-on) as this will provide better performance (with a > raid 0) or better performance with redundancy (raid 10, or RAID 0+1.) A > RAID adapter will offload the DISK I/O providing substantially better > performance. We are using Dell PERC controllers with SCSI 320 disks in a RAID-10 configuration, and battery-backed cache. As a result, disk IO is _not_ a bottleneck. All of our tests up till now have demonstrated that memory and disk usage are minimal, and that CPU usage is the current bottleneck. > At 02:46 PM 4/24/2006, you wrote: > > >I've been asked to make some hardware recommendations, I'm hoping some > >folks on the list can make some suggestions. > > > >We're looking hard at getting either Intel dual-core procs, or getting > >hyperthreaded procs with huge (8M) caches. > > > >We currently have a few dual proc Intel HT machines that we can test > >out our workload on, and I'm trying to get a feel for how to determine > >if a larger cache size will generate better performance than replacing > >HT procs with full-blown dual-core procs. We're looking at the 6850 > >from Dell, which supports both processor families: > >http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850 ?c=us&cs=555&l=en&s=biz > > > >The goal for these machines is to serve out PosgreSQL databases to as > >many Apache+php front ends as we can hang off each one. So we're trying > >to purchase hardware that will create a DB server that can handle a lot > >of web server front ends. > > > >I have a Dell 2850 (dual HT procs) here that I can use for testing. > >I'm a little fuzzy on determining how well the cache is working, so I'm > >stuck on whether or not the 8M cache that's available on the HT units > >is worth the money or not. Can anyone suggest a testing methodology > >that will isolate this particular aspect? > > > >-- > >Bill Moran > >Collaborative Fusion Inc. > >___ > >freebsd-questions@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-questions > >To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > >-- > >This message has been scanned for viruses and > >dangerous content by MailScanner, and is > >believed to be clean. > >MailScanner thanks transtec Computers for their support. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > MailScanner thanks transtec Computers for their support. > > -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support.
Re: Purchasing the correct hardware: dual-core intel? Big cache?
Yes, dual core is on average 20% faster than hyperthreaded CPU's. But that is general benchmark. The range of performance difference is 10% - 30% depending on the application mix. If you use well optimized applications, you see the larger performance gain. Poor optimization causes a CPU to chug along, flushing the CPU cache often, and slowing things down considerably. -Derek At 07:47 AM 4/25/2006, Bill Moran wrote: On Mon, 24 Apr 2006 18:31:46 -0500 Derek Ragona <[EMAIL PROTECTED]> wrote: > You can get better information directly from intel's website on > motherboards and CPU performance. Dual core is faster than hyperthreaded > CPU's usually about 20% if you use the larger CPU cache models. I don't follow you here. Are you saying that dual core is about 20% faster than hyperthreaded with larger cache? > However with a RDBMS as the primary usage, I would look for more ways to > optimize the system. I would look to use a RAID array with an add-on card > (or zero-chanel add-on) as this will provide better performance (with a > raid 0) or better performance with redundancy (raid 10, or RAID 0+1.) A > RAID adapter will offload the DISK I/O providing substantially better > performance. We are using Dell PERC controllers with SCSI 320 disks in a RAID-10 configuration, and battery-backed cache. As a result, disk IO is _not_ a bottleneck. All of our tests up till now have demonstrated that memory and disk usage are minimal, and that CPU usage is the current bottleneck. > At 02:46 PM 4/24/2006, you wrote: > > >I've been asked to make some hardware recommendations, I'm hoping some > >folks on the list can make some suggestions. > > > >We're looking hard at getting either Intel dual-core procs, or getting > >hyperthreaded procs with huge (8M) caches. > > > >We currently have a few dual proc Intel HT machines that we can test > >out our workload on, and I'm trying to get a feel for how to determine > >if a larger cache size will generate better performance than replacing > >HT procs with full-blown dual-core procs. We're looking at the 6850 > >from Dell, which supports both processor families: > >http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850 ?c=us&cs=555&l=en&s=biz > > > >The goal for these machines is to serve out PosgreSQL databases to as > >many Apache+php front ends as we can hang off each one. So we're trying > >to purchase hardware that will create a DB server that can handle a lot > >of web server front ends. > > > >I have a Dell 2850 (dual HT procs) here that I can use for testing. > >I'm a little fuzzy on determining how well the cache is working, so I'm > >stuck on whether or not the 8M cache that's available on the HT units > >is worth the money or not. Can anyone suggest a testing methodology > >that will isolate this particular aspect? > > > >-- > >Bill Moran > >Collaborative Fusion Inc. > >___ > >freebsd-questions@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-questions > >To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > >-- > >This message has been scanned for viruses and > >dangerous content by MailScanner, and is > >believed to be clean. > >MailScanner thanks transtec Computers for their support. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > MailScanner thanks transtec Computers for their support. > > -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscr
Re: Purchasing the correct hardware: dual-core intel? Big cache?
On Mon, 24 Apr 2006 18:31:46 -0500 Derek Ragona <[EMAIL PROTECTED]> wrote: > You can get better information directly from intel's website on > motherboards and CPU performance. Dual core is faster than hyperthreaded > CPU's usually about 20% if you use the larger CPU cache models. I don't follow you here. Are you saying that dual core is about 20% faster than hyperthreaded with larger cache? > However with a RDBMS as the primary usage, I would look for more ways to > optimize the system. I would look to use a RAID array with an add-on card > (or zero-chanel add-on) as this will provide better performance (with a > raid 0) or better performance with redundancy (raid 10, or RAID 0+1.) A > RAID adapter will offload the DISK I/O providing substantially better > performance. We are using Dell PERC controllers with SCSI 320 disks in a RAID-10 configuration, and battery-backed cache. As a result, disk IO is _not_ a bottleneck. All of our tests up till now have demonstrated that memory and disk usage are minimal, and that CPU usage is the current bottleneck. > At 02:46 PM 4/24/2006, you wrote: > > >I've been asked to make some hardware recommendations, I'm hoping some > >folks on the list can make some suggestions. > > > >We're looking hard at getting either Intel dual-core procs, or getting > >hyperthreaded procs with huge (8M) caches. > > > >We currently have a few dual proc Intel HT machines that we can test > >out our workload on, and I'm trying to get a feel for how to determine > >if a larger cache size will generate better performance than replacing > >HT procs with full-blown dual-core procs. We're looking at the 6850 > >from Dell, which supports both processor families: > >http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850?c=us&cs=555&l=en&s=biz > > > >The goal for these machines is to serve out PosgreSQL databases to as > >many Apache+php front ends as we can hang off each one. So we're trying > >to purchase hardware that will create a DB server that can handle a lot > >of web server front ends. > > > >I have a Dell 2850 (dual HT procs) here that I can use for testing. > >I'm a little fuzzy on determining how well the cache is working, so I'm > >stuck on whether or not the 8M cache that's available on the HT units > >is worth the money or not. Can anyone suggest a testing methodology > >that will isolate this particular aspect? > > > >-- > >Bill Moran > >Collaborative Fusion Inc. > >___ > >freebsd-questions@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-questions > >To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > >-- > >This message has been scanned for viruses and > >dangerous content by MailScanner, and is > >believed to be clean. > >MailScanner thanks transtec Computers for their support. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > MailScanner thanks transtec Computers for their support. > > -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Purchasing the correct hardware: dual-core intel? Big cache?
On Tue, 25 Apr 2006 13:28:50 +0100 "Martin Hepworth" <[EMAIL PROTECTED]> wrote: > Bill > > if the database is CPU dependant I'd look at tuning the queries/indexes and > that stuff...it really shouldn't be CPU bound. That's in progress, and it's going to be an ongoing process as the application goes through versions. Fact is, with 4G of RAM most of the data sits in RAM, so reads incur no or little IO. With high-end SCSI disks in RAID-10 and a battery- backed cache, burst writes are cached, thus lightening fast, and we've been unable to run the application hard enough to saturate the SCSI bus so far. So ... the current bottleneck is CPU. > > -- > martin > > On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote: > > > > On Mon, 24 Apr 2006 23:03:59 +0100 > > "Martin Hepworth" <[EMAIL PROTECTED]> wrote: > > > > > Bill > > > > > > depends on the application itself, but more RAM and the disk layout > > (RAID) > > > will be more important than the CPU. Also depends on how write-heavy the > > > apps are... > > > > Thanks for the feedback, Martin. > > > > I'm fully aware of the app-dependency - what I'm looking for is a way > > to test the application. I've got 3 different clusters available for > > testing, but I'm not sure how to tell if the cache is getting used > > heavily or not. > > > > I've already determined that the database server is CPU-bound under > > our test load. With high-speed SCSI disks and battery-backed RAID, > > there's not enough IO to stress the disk subsystem. RAM is almost a > > non-issue. With the machine stressed at full load, it's only using > > 1/8 of the available RAM. > > > > So, my current bottleneck is CPU power. And the boss has asked me > > for the best way to overcome this bottleneck. We're looking at either > > the same CPUs we already have, but with _huge_ caches (8m) - or going > > with more CPUs by getting true dual-core pentiums. > > > > The question this all pivots on is will 8M of cache be a significant > > improvement? If not, then we're going with the dual-core CPUs. What > > I'd like is some way to take an existing system and determine how often > > the cache is getting invalidated, so I can make some guesstemate as to > > whether more cache will help or not. > > > > > > > > -- > > > martin > > > > > > On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > I've been asked to make some hardware recommendations, I'm hoping some > > > > folks on the list can make some suggestions. > > > > > > > > We're looking hard at getting either Intel dual-core procs, or getting > > > > hyperthreaded procs with huge (8M) caches. > > > > > > > > We currently have a few dual proc Intel HT machines that we can test > > > > out our workload on, and I'm trying to get a feel for how to determine > > > > if a larger cache size will generate better performance than replacing > > > > HT procs with full-blown dual-core procs. We're looking at the 6850 > > > > from Dell, which supports both processor families: > > > > > > > > > > http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850?c=us&cs=555&l=en&s=biz > > > > > > > > The goal for these machines is to serve out PosgreSQL databases to as > > > > many Apache+php front ends as we can hang off each one. So we're > > trying > > > > to purchase hardware that will create a DB server that can handle a > > lot > > > > of web server front ends. > > > > > > > > I have a Dell 2850 (dual HT procs) here that I can use for testing. > > > > I'm a little fuzzy on determining how well the cache is working, so > > I'm > > > > stuck on whether or not the 8M cache that's available on the HT units > > > > is worth the money or not. Can anyone suggest a testing methodology > > > > that will isolate this particular aspect? > > > > > > > > -- > > > > Bill Moran > > > > Collaborative Fusion Inc. > > > > ___ > > > > freebsd-questions@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > > > To unsubscribe, send any mail to " > > > > [EMAIL PROTECTED]" > > > > > > > ___ > > > freebsd-questions@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > > To unsubscribe, send any mail to " > > [EMAIL PROTECTED]" > > > > > > * > > > > > > > > > > > > > > > > > > > > This footnote confirms that this email message has been scanned by > > > PineApp Mail-SeCure for the presence of malicious code, vandals & > > computer viruses. > > > > > > > > > > > > > > > > > -- > > Bill Moran > > Collaborative Fusion Inc. > > > > > > IMPORTANT: This message contains confidential information and is > > intended only for the individual named. If the
Re: Purchasing the correct hardware: dual-core intel? Big cache?
Bill if the database is CPU dependant I'd look at tuning the queries/indexes and that stuff...it really shouldn't be CPU bound. -- martin On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote: > > On Mon, 24 Apr 2006 23:03:59 +0100 > "Martin Hepworth" <[EMAIL PROTECTED]> wrote: > > > Bill > > > > depends on the application itself, but more RAM and the disk layout > (RAID) > > will be more important than the CPU. Also depends on how write-heavy the > > apps are... > > Thanks for the feedback, Martin. > > I'm fully aware of the app-dependency - what I'm looking for is a way > to test the application. I've got 3 different clusters available for > testing, but I'm not sure how to tell if the cache is getting used > heavily or not. > > I've already determined that the database server is CPU-bound under > our test load. With high-speed SCSI disks and battery-backed RAID, > there's not enough IO to stress the disk subsystem. RAM is almost a > non-issue. With the machine stressed at full load, it's only using > 1/8 of the available RAM. > > So, my current bottleneck is CPU power. And the boss has asked me > for the best way to overcome this bottleneck. We're looking at either > the same CPUs we already have, but with _huge_ caches (8m) - or going > with more CPUs by getting true dual-core pentiums. > > The question this all pivots on is will 8M of cache be a significant > improvement? If not, then we're going with the dual-core CPUs. What > I'd like is some way to take an existing system and determine how often > the cache is getting invalidated, so I can make some guesstemate as to > whether more cache will help or not. > > > > > -- > > martin > > > > On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote: > > > > > > > > > I've been asked to make some hardware recommendations, I'm hoping some > > > folks on the list can make some suggestions. > > > > > > We're looking hard at getting either Intel dual-core procs, or getting > > > hyperthreaded procs with huge (8M) caches. > > > > > > We currently have a few dual proc Intel HT machines that we can test > > > out our workload on, and I'm trying to get a feel for how to determine > > > if a larger cache size will generate better performance than replacing > > > HT procs with full-blown dual-core procs. We're looking at the 6850 > > > from Dell, which supports both processor families: > > > > > > > http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850?c=us&cs=555&l=en&s=biz > > > > > > The goal for these machines is to serve out PosgreSQL databases to as > > > many Apache+php front ends as we can hang off each one. So we're > trying > > > to purchase hardware that will create a DB server that can handle a > lot > > > of web server front ends. > > > > > > I have a Dell 2850 (dual HT procs) here that I can use for testing. > > > I'm a little fuzzy on determining how well the cache is working, so > I'm > > > stuck on whether or not the 8M cache that's available on the HT units > > > is worth the money or not. Can anyone suggest a testing methodology > > > that will isolate this particular aspect? > > > > > > -- > > > Bill Moran > > > Collaborative Fusion Inc. > > > ___ > > > freebsd-questions@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > > To unsubscribe, send any mail to " > > > [EMAIL PROTECTED]" > > > > > ___ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to " > [EMAIL PROTECTED]" > > > > * > > > > > > > > > > > > > This footnote confirms that this email message has been scanned by > > PineApp Mail-SeCure for the presence of malicious code, vandals & > computer viruses. > > > > > > > > > > -- > Bill Moran > Collaborative Fusion Inc. > > > IMPORTANT: This message contains confidential information and is > intended only for the individual named. If the reader of this > message is not an intended recipient (or the individual > responsible for the delivery of this message to an intended > recipient), please be advised that any re-use, dissemination, > distribution or copying of this message is prohibited. Please > notify the sender immediately by e-mail if you have received > this e-mail by mistake and delete this e-mail from your system. > E-mail transmission cannot be guaranteed to be secure or > error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. The > sender therefore does not accept liability for any errors or > omissions in the contents of this message, which arise as a > result of e-mail transmission. > **
Re: Purchasing the correct hardware: dual-core intel? Big cache?
On Mon, 24 Apr 2006 23:03:59 +0100 "Martin Hepworth" <[EMAIL PROTECTED]> wrote: > Bill > > depends on the application itself, but more RAM and the disk layout (RAID) > will be more important than the CPU. Also depends on how write-heavy the > apps are... Thanks for the feedback, Martin. I'm fully aware of the app-dependency - what I'm looking for is a way to test the application. I've got 3 different clusters available for testing, but I'm not sure how to tell if the cache is getting used heavily or not. I've already determined that the database server is CPU-bound under our test load. With high-speed SCSI disks and battery-backed RAID, there's not enough IO to stress the disk subsystem. RAM is almost a non-issue. With the machine stressed at full load, it's only using 1/8 of the available RAM. So, my current bottleneck is CPU power. And the boss has asked me for the best way to overcome this bottleneck. We're looking at either the same CPUs we already have, but with _huge_ caches (8m) - or going with more CPUs by getting true dual-core pentiums. The question this all pivots on is will 8M of cache be a significant improvement? If not, then we're going with the dual-core CPUs. What I'd like is some way to take an existing system and determine how often the cache is getting invalidated, so I can make some guesstemate as to whether more cache will help or not. > > -- > martin > > On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote: > > > > > > I've been asked to make some hardware recommendations, I'm hoping some > > folks on the list can make some suggestions. > > > > We're looking hard at getting either Intel dual-core procs, or getting > > hyperthreaded procs with huge (8M) caches. > > > > We currently have a few dual proc Intel HT machines that we can test > > out our workload on, and I'm trying to get a feel for how to determine > > if a larger cache size will generate better performance than replacing > > HT procs with full-blown dual-core procs. We're looking at the 6850 > > from Dell, which supports both processor families: > > > > http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850?c=us&cs=555&l=en&s=biz > > > > The goal for these machines is to serve out PosgreSQL databases to as > > many Apache+php front ends as we can hang off each one. So we're trying > > to purchase hardware that will create a DB server that can handle a lot > > of web server front ends. > > > > I have a Dell 2850 (dual HT procs) here that I can use for testing. > > I'm a little fuzzy on determining how well the cache is working, so I'm > > stuck on whether or not the 8M cache that's available on the HT units > > is worth the money or not. Can anyone suggest a testing methodology > > that will isolate this particular aspect? > > > > -- > > Bill Moran > > Collaborative Fusion Inc. > > ___ > > freebsd-questions@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > > To unsubscribe, send any mail to " > > [EMAIL PROTECTED]" > > > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > * > > > > > > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses. > > > -- Bill Moran Collaborative Fusion Inc. IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Purchasing the correct hardware: dual-core intel? Big cache?
Bill depends on the application itself, but more RAM and the disk layout (RAID) will be more important than the CPU. Also depends on how write-heavy the apps are... -- martin On 4/24/06, Bill Moran <[EMAIL PROTECTED]> wrote: > > > I've been asked to make some hardware recommendations, I'm hoping some > folks on the list can make some suggestions. > > We're looking hard at getting either Intel dual-core procs, or getting > hyperthreaded procs with huge (8M) caches. > > We currently have a few dual proc Intel HT machines that we can test > out our workload on, and I'm trying to get a feel for how to determine > if a larger cache size will generate better performance than replacing > HT procs with full-blown dual-core procs. We're looking at the 6850 > from Dell, which supports both processor families: > > http://www1.us.dell.com/content/products/productdetails.aspx/pedge_6850?c=us&cs=555&l=en&s=biz > > The goal for these machines is to serve out PosgreSQL databases to as > many Apache+php front ends as we can hang off each one. So we're trying > to purchase hardware that will create a DB server that can handle a lot > of web server front ends. > > I have a Dell 2850 (dual HT procs) here that I can use for testing. > I'm a little fuzzy on determining how well the cache is working, so I'm > stuck on whether or not the 8M cache that's available on the HT units > is worth the money or not. Can anyone suggest a testing methodology > that will isolate this particular aspect? > > -- > Bill Moran > Collaborative Fusion Inc. > ___ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > [EMAIL PROTECTED]" > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
