[rt-users] RT Scalability

Mark Chappell m.d.chappell at bath.ac.uk
Mon Nov 26 11:50:33 EST 2007

Jesse Vincent wrote:
> Can you talk about what you've done to tune your MySQL server? MySQL
> performance tuning can take you a lot larger than you're currently at.
> Having enough RAM and _using_ it are both important for keeping mysql
> purring.

The bulk of the tuning was done before my time, it's mostly a stock RT 
with some minor my.conf changes

# Performance Tuning
key_buffer              = 384M
table_cache             = 512
sort_buffer_size        = 2M
read_buffer_size        = 2M
myisam_sort_buffer_size = 64M
thread_cache            = 8
# try number of CPU's*2 for thread_concurrency
thread_concurrency      = 8

query_cache_size        = 64M
#query_cache_type       = 1

innodb_data_home_dir = /var/lib/mysql/
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/lib/mysql/
innodb_log_arch_dir = /var/lib/mysql/
# You can set .._buffer_pool_size up to 50 - 80 %
# of RAM but beware of setting memory usage too high
innodb_buffer_pool_size = 384M
innodb_additional_mem_pool_size = 20M
# Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

MySQL seems to be munching on about 1/3rd of the available memory (2Gb), 
and splitting the CPU load about 50/50 with apache.  During the day load 
averages of >5 aren't that uncommon at the minute.

Last time I tried looking on a test server with just me, a sizable chunk 
of time seemed to be being eaten by ACL queries which we played with but 
couldn't seem to get optimised.

With a handful of us testing out the Postgres based cluster things seem 
to be moving much faster, but it's supposed to be able to tune its 
self...  With 3 sites, we can also now offer automatic failover, which 
management types seem to be interested in.

>> I'm pretty impressed with just how well RT has scaled, however, I'm 
>> curious as to how many other people have tried pushing RT this far.
> I know of a VOIP provider with (a locally hacked and improved) RT with
> 16 million tickets in it.

I was curious since most of the random RT databases I've seen appear to 
be handing out tickets in the tens on thousands range, and at peak times 
of the year we were churning through about 1000 tickets a day.

Database tuning, definately a black art, but pure magic when you get it 

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
  -- RFC 1925

More information about the rt-users mailing list