Hi Greg:
I keep coming back to this message when I need to break from a project I am
working on so I'll let this fly now and see if it gets some ideas going for
you....
( I see since I started this Mathew has dropped you a note about PostGreSQL
which is just so true. Sure some mysql folks don't like hearing that but if
you know pgsql .... it's not so scary)
* dbmail.conf?
You are not using a socket connection for mysql?
You have likely experimented with changes to the number of child processes
in dbmail.conf but I do wonder on the basis of the small amount of data here
about max 200 IMAPD / 200 POP children and 1000 + 1000 connections when you
have only max connected 170 users shared between POP3 and IMAP. I wonder
which protocol users like the most? Are you getting POP DoS'd?
Many-users-POP-every-min kinda thing? Try jack up the mysql query cache to
something huge. After many hours of uptime what is the RES and actual memory
used for MySQL and how much mem does DBMail really get after all the buffers
and such get their chunk? ( After a 7 or 14-day uptime the used MYSQL memory
should be your new configged RES plus a little -- giving the rest back to
the OS, the Raid 5 drive buffers(!), MTA and MDA.)
* Is the database clean?
That's a large MySQL database for only 300 users. There's nothing crazy
saying even a terrabyte db can run well with MySQL but it is somewhat new
paradigm and takes a bit of science and mad luck to get the right formula of
resources and config to do it well -- I think about your scaling dilemma.
Meanwhile for 300 megs and more I favour PostgreSQL if I want to do it the
easy way. With MySQL you have to figure out how to do it. With pgsql you
just do it. But... truth is, DBMail works vewry well with MySQL.
You are using MySQL 4.1? I hope.
Is the database clean? Each of your users must be storing about .7 Gigs
mail -- a full cd's worth. Send each user a blank CD and tell them to get
their crap off your server :o) heh heh don't. How often do you have cron
run dbmail-util -a -y ?
* MySQL on a Raid5?
I wonder if some problem is with the RDBMS on a Raid 5? I know many folks
like Raid 5 but I think its absurd for busy RDBMS useage. Write is wickedly
slow and uses huge CPU for big writes even if talking to a 3Ware
harware-raid card's processor. I have found nice RDBMS speed in 64-bit but
gave up on even a 3Ware Raid 5 and chose a faster mirrored stripe when
drives first started getting BIG. With mail there's just too much stuff to
write while at the same time users are doing a gazillion reads. Raid 5 can't
chew gum and walk at the same time -- simultaneous big writes and reads
drives CPU loads to crazy levels. ( I also migrated MySQL off the DBMail
host but a short Gig-LAN pipe away -- that way in each case the service
delivery and RDBMS storage got the full range of the host's resources. The
trip down the pipe on 3306 has a little bit of latency but once the useage
goes up the cost of the transfer is way down. Also 64-bit for the RDBMS
allows huge throughput to and from also huge physical memory resources cuz
the mem manger is on the CPU.)
What about building a nice replication host with a fat mirrored stripe and
when you are happy with it, make the move - change the IP in the MTA and MDA
configs.
My one remaining Raid 5 RDBMS has only survived because it is using a
PostgreSQL database or I would have shifted over to a stripe. Only complaint
is that it is a little too slow but the environment allows that. There are
many more users than what you have though. - 32-bit Athlon 2800 MPs on an
Tyan MPX board. Raid 5 Terrabyte is made up with 250meg drives - two
spares -- getting old too. It's about 999 megs and 360 megs are used by the
OS and RDBMS database -- doesn't need to be that big but for whatever reason
it was the best of all the Raid 5s. I actually have the OS on the Raid5
array -- never did that before and never again.
Are you pushing into swap? Is 4G the max for that architecture? I feel that
is quite light for the size of chunks you seem to be using (700megs per user
manipulated by 170 connections at peak.) Your mysql conf file on a rough
count is for something a tad larger like 2.5 gig per cpu. Are those 32-bit
Xeons?
I think thread_concurrency=8 is tricky with Hyperthreading. Is HTT off or
on. I know a lot of people think this is really four cpus but MySQL is
smarter maybe cuz I found that thread_concurrency=4 worked slightly better
with 32-bit Hyperthreading "ON".
Anyway... good luck
:o)
Mike
----- Original Message -----
From: "Greg Hellings" <[EMAIL PROTECTED]>
To: "DBMail mailinglist" <[email protected]>
Sent: Sunday, March 05, 2006 6:54 PM
Subject: [Dbmail] Terrible Load Issues With 2.0.9
We've been having terrible load issues with 2.0.9 and only about 300
users. We've got dual 3.6ghz Xeons with 1M L2 cache and 4G of ram and a
RAID5 979G. During our heavy load hours (9-5) the system crawls to the
point of timing out many mail client operations. The load averages are
extremely high, and Mysql and Dbmail-imapd are using a ton of cpu.
Our clients are using a mix of Entourage, Mail.app, Thunderbird, and
squirrelmail (only 5 or 10 webmail clients during our heavy load period).
Our dbmail_messageblk is about 220G right now.
The system runs fine until about 170 users connect, and then the slow
downs start.
Here is our my.cnf and dbmail.conf
#############################################################
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
old_passwords=1
set-variable=max_connections=350
set-variable=query_cache_size=64M
set-variable=max_allowed_packet=16M
set-variable=table_cache=1024
set-variable=open_files_limit=4096
set-variable=binlog_cache_size=1M
set-variable=max_heap_table_size=32M
set-variable=thread_cache_size=80
set-variable=query_cache_limit=2M
set-variable=tmp_table_size=64M
set-variable=sort_buffer_size=16M
set-variable=log_slow_queries=/var/log/mysql-slow.log
set-variable=long_query_time=10
set-variable=innodb_log_group_home_dir=/var/lib/dbmail-log/
set-variable=key_buffer_size=8M
set-variable=wait_timeout=60
set-variable=interactive_timeout=60
set-variable=thread_concurrency=8
set-variable=innodb_thread_concurrency=10
set-variable=innodb_buffer_pool_size=2G
set-variable=innodb_additional_mem_pool_size=4M
set-variable=innodb_log_buffer_size=4M
set-variable=thread_cache_size=8M
[mysql.server]
user=mysql
basedir=/var/lib
[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
#############################################################
[DBMAIL]
host=localhost
sqlport=3306
# sqlsocket=/var/lib/mysql/mysql.sock
user=dbmail
pass=
db=dbmail
POSTMASTER=
TRACE_LEVEL=2
[SMTP]
SENDMAIL=/usr/sbin/sendmail
AUTO_NOTIFY=no
AUTO_REPLY=no
TRACE_LEVEL=2
[LMTP]
EFFECTIVE_USER=dbmail
EFFECTIVE_GROUP=dbmail
BINDIP=*
PORT=24
NCHILDREN=20
MAXCHILDREN=10
MINSPARECHILDREN=2
MAXSPARECHILDREN=4
MAXCONNECTS=10000
TIMEOUT=300
RESOLVE_IP=no
TRACE_LEVEL=2
MAX_ERRORS=500
[POP]
EFFECTIVE_USER=dbmail
EFFECTIVE_GROUP=dbmail
BINDIP=*
PORT=120
NCHILDREN=50
MAXCHILDREN=200
MINSPARECHILDREN=2
MAXSPARECHILDREN=4
MAXCONNECTS=10000
TIMEOUT=300
RESOLVE_IP=yes
POP_BEFORE_SMTP=no
TRACE_LEVEL=2
[IMAP]
EFFECTIVE_USER=dbmail
EFFECTIVE_GROUP=dbmail
BINDIP=*
PORT=143
NCHILDREN=50
MAXCHILDREN=200
MINSPARECHILDREN=2
MAXSPARECHILDREN=4
MAXCONNECTS=1000
TIMEOUT=60
RESOLVE_IP=no
IMAP_BEFORE_SMTP=no
TRACE_LEVEL=1
#############################################################
--
Greg Hellings Network & Security Analyst
[EMAIL PROTECTED] Dailey & Associates
(310) 279-4321 Fax (310) 360-0810
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
