I appreciate your observations, unfortunately I am stuck with Intel Quad-Core processors. :)
We are having significant issues handling IMAP requests in a timely manner (12 seconds to load the Inbox in Thunderbird and an in-house Java-mail app) on our dbmail implementation and I believe the problem resides with the database configuration. Is there anyone out there that is running dbmail 2.2.10 with a MySQL 5.0.X database with a large user group that can share their my.cnf? Our user count is over 4000. This is our my.cnf: # You can copy this file to # /etc/my.cnf to set global options, # mysql-data-dir/my.cnf to set server-specific options (in this # installation this directory is /usr/local/mysql/data) or # ~/.my.cnf to set user-specific options. # # In this file, you can use all long options that a program supports. # If you want to know which options a program supports, run the program # with the "--help" option. # The following options will be passed to all MySQL clients [client] #password = your_password port = 3306 socket = /var/lib/mysql/mysql.sock # Here follows entries for some specific programs # The MySQL server [mysqld] port = 3306 socket = /var/lib/mysql/mysql.sock max_connections = 500 max_connect_errors = 999999 skip-locking key_buffer = 384M max_allowed_packet = 8M table_cache = 1024 sort_buffer_size = 16M read_buffer_size = 16M read_rnd_buffer_size = 8M myisam_sort_buffer_size = 64M thread_cache_size = 16 query_cache_size = 128M query_cache_limit = 2M long_query_time = 10 # These variables determine the max size of a memory temp table tmp_table_size = 32M max_heap_table_size = 32M tmpdir = /tmp datadir = /var/lib/mysql # Try number of CPU's*2 for thread_concurrency thread_concurrency = 32 # Don't listen on a TCP/IP port at all. This can be a security enhancement, # if all processes that need to connect to mysqld run on the same host. # All interaction with mysqld must be made via Unix sockets or named pipes. # Note that using this option without enabling named pipes on Windows # (via the "enable-named-pipe" option) will render mysqld useless! # #skip-networking # MySQL General Query Log #log=mysql.general.log # MySQL Binary Log log-bin=mysql-bin #expire_logs_days = 1 # MySQL Slow Query Log #log-slow-queries=/var/lib/mysql/mysql.slow.log #log-queries-not-using-indexes # required unique id between 1 and 2^32 - 1 # defaults to 1 if master-host is not set # but will not function as a master if omitted server-id = 1 # InnoDB settings innodb_file_per_table 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/ innodb_log_files_in_group = 2 innodb_buffer_pool_size = 24576M innodb_additional_mem_pool_size = 20M innodb_log_file_size = 256M innodb_log_buffer_size = 16M innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 50 innodb_thread_concurrency = 1 innodb_thread_sleep_delay = 0 innodb_flush_method = O_DIRECT transaction-isolation = READ-COMMITTED #innodb_sync_spin_loops = 20 innodb_concurrency_tickets = 1500 innodb_support_xa = 0 innodb_open_files = 1000 #skip_innodb_doublewrite #skip_innodb_checksums [mysqldump] quick max_allowed_packet = 16M [mysql] no-auto-rehash # Remove the next comment character if you are not familiar with SQL #safe-updates [isamchk] key_buffer = 256M sort_buffer_size = 256M read_buffer = 2M write_buffer = 2M [myisamchk] key_buffer = 256M sort_buffer_size = 256M read_buffer = 2M write_buffer = 2M We are running MySQL on SLES 10 SP2 kernel version is 2.6.16.60-0.21-smp 32GB of RAM on a 4xQuad-Core Intel server. We've changed innodb_thread_concurrency on the fly to see if we had any performance increase, but the latest tests show no improvement with decreased performance at innodb_thread_concurrency at 4 or higher. I have been given until Friday (2 days) to resolve the issue before I am forced to go back to a flat file email system, so I greatly appreciate any and all help. If there are any other areas that I should be looking at, I will gladly take any/all suggestions. Thank you very much, Rob On Fri, Aug 22, 2008 at 5:15 AM, Vladimir Likhachev <[EMAIL PROTECTED]>wrote: > Sorry, of course, Sun bought MySQL AB. > Large server memory (more then 4 GB) usage details is the main reason of > AMD64 usage and its suggestion by Oracle, I think... Not details of > InnoDB format or MySQL server realisation... At whole, for each (heavy? > strongly?) loaded server program large memory usage is very important. > The next reason is non-independent level 2 cache memory in Intel Core Quad > processors. > Intel Em64T technology is (a very simple view) memory over 4 GB mapping in > a window 128 or 256 MB width laying below 4 GB in UMA address space. > > All this is my opinion only, based on Intel SR/SH (4*Xeon-MP) and Intel > platforms 4*Xeon 2*Core processors, 1*Intel CoreQuad workstations usage. No > use Intel CoreQuad for "serious" servers in companies where I work. Up to > 120 GB InnoDB bases in DBMail 2.xx. > > ------------------------------ > > Date: Fri, 22 Aug 2008 10:07:10 +1000 > From: [EMAIL PROTECTED] > To: [email protected] > Subject: RE: [Dbmail] Query to show mailbox folders running slow > > > On Thu, 21 Aug 2008 08:01:43 +0000, Vladimir Likhachev wrote: > > > Oracle (current owner of MySQL AB) suggests AMD64 processors. > > Minor correction. Sun bought MySQL AB. Oracle bought InnoDB. I'm not too > impressed with either move frankly. How many people think Oracle bought > InnoDB to incorporate their technology into the next version of Oracle? > > > ------------------------------ > Explore the seven wonders of the world Learn > more!<http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE> > > _______________________________________________ > DBmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail > >
_______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
