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!
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
