Reply to thread

Message

<blockquote data-quote="IronWolf" data-source="post: 1838376" data-attributes="member: 21076">First, let it be said you guys are doing a great job!&nbsp; It is much easier to sit outside and offer ideas and thoughts than be the one that has to make the final decision and put it all together.But, I have to agree with Psionicist.&nbsp; Why not go dual server class CPU's (with fat cache) and make the move to SCSI drives?&nbsp; Your dual CPUs will help distribute your load caused by mysql and apache across two processors.&nbsp; One really fast CPU is still going to only be able to handle so many threads a millisecond.&nbsp; With two CPU's you can spread the load across the two of them a bit.As for the SCSI drives, you'll get faster RPM and faster seek times.&nbsp; Seagate shows their SATA drives with an 8.5ms seek time while Seagates 15k SCSI drives 3.6ms seek times.&nbsp; While you say disk I/O is not an issue now, for future growth and performance I would be very concious of making sure my I/O system does NOT become a bottleneck in the future.In addition, moving to SCSI drives will help move more processor load to the SCSI controller to handle locating various blocks of data.&nbsp; When the CPU does need to send requests for data from the disks it can take advantage of SCSI's TCQ to send multiple requests at the same time freeing itself up for other tasks.&nbsp; With the IDE drives, the CPU's processor is having to handle requests for blocks of data on the disks from start to finish with no help from the &quot;smarter&quot; SCSI controller.So the SCSI drives will insure future needs for growth are met and most likely result in less CPU time than the IDE disks currently.And finally, there are some really good troublshooting tips in the O'Reilly book 'High Performance MySQL'.&nbsp; This could help you folks track down which queries are especially problematic and causing spikes in CPU usage and disk usage.Just my 2 cents!&nbsp; Again, you folks are doing a great job and it is much easier for me to sit on the outside and make suggestions than be the one that has to implement!</blockquote>

[QUOTE="IronWolf, post: 1838376, member: 21076"] First, let it be said you guys are doing a great job! It is much easier to sit outside and offer ideas and thoughts than be the one that has to make the final decision and put it all together. But, I have to agree with Psionicist. Why not go dual server class CPU's (with fat cache) and make the move to SCSI drives? Your dual CPUs will help distribute your load caused by mysql and apache across two processors. One really fast CPU is still going to only be able to handle so many threads a millisecond. With two CPU's you can spread the load across the two of them a bit. As for the SCSI drives, you'll get faster RPM and faster seek times. Seagate shows their SATA drives with an 8.5ms seek time while Seagates 15k SCSI drives 3.6ms seek times. While you say disk I/O is not an issue now, for future growth and performance I would be very concious of making sure my I/O system does NOT become a bottleneck in the future. In addition, moving to SCSI drives will help move more processor load to the SCSI controller to handle locating various blocks of data. When the CPU does need to send requests for data from the disks it can take advantage of SCSI's TCQ to send multiple requests at the same time freeing itself up for other tasks. With the IDE drives, the CPU's processor is having to handle requests for blocks of data on the disks from start to finish with no help from the "smarter" SCSI controller. So the SCSI drives will insure future needs for growth are met and most likely result in less CPU time than the IDE disks currently. And finally, there are some really good troublshooting tips in the O'Reilly book 'High Performance MySQL'. This could help you folks track down which queries are especially problematic and causing spikes in CPU usage and disk usage. Just my 2 cents! Again, you folks are doing a great job and it is much easier for me to sit on the outside and make suggestions than be the one that has to implement! [/QUOTE]

Verification