Older setup:<br><br>RT 3.4.5 with mysql 4.0.24 and Perl 5.8.6 on V20z with 2 1.8Ghz and 4G mem<br><br>mysql> select count(*) from Tickets;<br>+----------+<br>| count(*) |<br>+----------+<br>|   406311 |<br>+----------+<br>
1 row in set (0.25 sec)<br><br>Newer setup:<br><br>RT 3.8.2 with mysql 5.0.75 and Perl 5.8.8 on T1000 with 24 1Ghz cpu threads and 16GB mem<br><br>mysql> select count(*) from Tickets;<br>+----------+<br>| count(*) |<br>
+----------+<br>|   401576 | <br>+----------+<br>1 row in set (2.02 sec)<br><br><br>As you can see it is really slow<br><br>Here is my my.cnf file <br><br>[client]<br>port            = 3306<br>socket          = /tmp/mysql.sock<br>
[mysqld]<br>port            = 3306<br>socket          = /tmp/mysql.sock<br>skip-locking<br>key_buffer = 1G<br>max_allowed_packet = 50M<br>table_cache = 512<br>sort_buffer_size = 4M<br>read_buffer_size = 2M<br>read_rnd_buffer_size = 256K<br>
net_buffer_length = 2K<br>thread_stack = 128K<br>server-id       = 1<br>skip-federated<br>innodb_data_home_dir = /var/opt/csw/mysql5/<br>innodb_data_file_path = ibdata1:2000M;ibdata2:50M:autoextend<br>innodb_log_group_home_dir = /var/opt/csw/mysql5/<br>
innodb_log_arch_dir = /var/opt/csw/mysql5/<br>innodb_buffer_pool_size = 1G<br>innodb_additional_mem_pool_size = 20M<br>innodb_log_file_size = 250M<br>innodb_log_buffer_size = 20M<br>innodb_flush_log_at_trx_commit = 2<br>[mysqldump]<br>
quick<br>max_allowed_packet = 50M<br>[mysql]<br>no-auto-rehash<br>safe-updates<br>[isamchk]<br>key_buffer = 256M<br>sort_buffer_size = 256M<br>read_buffer = 2M<br>write_buffer = 2M<br>[myisamchk]<br>key_buffer = 256M<br>sort_buffer_size = 256M<br>
read_buffer = 2M<br>write_buffer = 2M<br>[mysqlhotcopy]<br>interactive-timeout<br><br><br clear="all"><br>-- <br>Asif Iqbal<br>PGP Key: 0xE62693C5 KeyServer: <a href="http://pgp.mit.edu">pgp.mit.edu</a><br>A: Because it messes up the order in which people normally read text.<br>
Q: Why is top-posting such a bad thing?<br><br><br>