Curtis Bruneau wrote: > Jesse Vincent wrote: >> >>> I agree completely with the above, but more important to me than just RAM >>> and processing power is the speed of disk access. He mentioned using RAID >>> 5 in a follow-up post. That's fine, but are these IDE or 15k SCSI drives? >>> Faster drives should always speed up database performance. >>> >> At 8 gigs of RAM on a well-tuned system, most of what RT is pulling out >> of the database should always be cached in memory. If MySQL is going to >> disk on every query, the game's over and you're better off sobbing >> quietly into a stiff drink than getting faster disks. >> >> -j >> > Yeah agreed, It should rarely go to disc. The iowait on my server is > very low. If it is there's either missing indexes or not enough memory > pool for innodb to keep it cached, you can see that with the hit rate. > > He can adjust that with the 'innodb_buffer_pool_size' , I've also set > 'innodb_flush_log_at_trx_commit' to 0 which isn't as safe but it makes > writes really fast. There are other settings also. > > The one area that is prone to issues is the Search due to all the fields > it can search and a lot of them aren't indexed so it's doing a lot of > row scans. >
Writes aren't an issue. It doesn't take long to write one transaction compared to reading every transaction on a ticket before displaying it. I still need to take a look-see at the config file to see what I've got going on there before I can say it isn't the buffer pool size. Additionally, we do have about six or seven custom fields which wouldn't be indexed. -- Keep up with my goings on at http://feeds.feedburner.com/theillien_atom _______________________________________________ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [email protected] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
