And that's a good point. You should, at a minimum, have sysstat (the Linux sar package) installed on all of your servers and monitor that. Also, do some remote SNMP performance monitoring to start seeing where your bottlenecks are. Keep in mind that IO issues may appear as CPU issues at times.
For a database server, the most important element is memory. I would rather a single CPU database server with 8 GB of RAM than a quad-CPU system with 4 GB of RAM. I'm not sure where we are at on multicore vs. SMP when it comes to databases. That would be interesting research for someone here. The O'Reilly book on performance tuning is still my favorite. I have a Linux-specific text somewhere that I keep meaning to read, but that requires a bit more time.. Anyway, if you don't have numbers when tuning for "performance", you are going to just be guessing. :-) Oh, and finally, do realize that there is a difference between local performance counters and end-to-end performance testing. An important baseline is to see the min, max, and average for each SQL op (using a large testset) while your server is at rest, maxed out, and operating normally with clients. Local performance counters should help you tune your system based on your end-to-end testing. The local counters have no real significance otherwise. I could care less if my machine is tagging the CPU at times if my client applications don't notice a performance issue, but if you cared only about the local counters, you may spend your time working on that needlessly. --- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/publications.htm Sunday, January 14, 2007, 10:58:58 PM, you wrote: > What's it for? Why do you think you need more than one machine to meet the > load? > On Sunday 14 January 2007 20:24, Brad Bendily wrote: >> cluster mysql for high-availability and possibly load-balancing. > _______________________________________________ > General mailing list > General at brlug.net > http://mail.brlug.net/mailman/listinfo/general_brlug.net
