[rt-users] RT Scalability

[Roy El-Hames]

Mark;

One thing I would recommend is to split the web from db and get them 
running on 2 different servers , we found that made huge difference to 
the front end usability.
Regards;
Roy


Mark Chappell wrote:
> ------------------------------------------------------------------------
>
> Subject:
> Re: [rt-users] RT Scalability
> From:
> Mark Chappell <m.d.chappell at bath.ac.uk>
> Date:
> Mon, 26 Nov 2007 16:50:33 +0000
> To:
> Jesse Vincent <jesse at bestpractical.com>
>
> To:
> Jesse Vincent <jesse at bestpractical.com>
> CC:
> rt-users at lists.bestpractical.com
>
>
>
> 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 
> right...
>
>
>
>
>
> Mark
>
>