Mailing List Archive: DBMail: users

slow deliver

Index | Next | Previous | View Threaded

remy at linuxnet

Jun 23, 2012, 7:56 PM

Post #1 of 2 (260 views)
Permalink

slow deliver

Hello gentlemen.

See if one of you could help me.

I have a fresh installation of dbmail 3.0.2. (mysql 5.1.46; postfix
2.7.1 in a openSuSE 11.3 everthing in the same server).

And I use fetchmail to get mails from just one account to be delivered
through postfix to dbmail. Everything is working fine, my doubt is about
delay. When I run fetchmail, I get my postfix queue filled with
thousands of messages quickly and following /var/log/mail I could see it
takes more than 2 seconds to deliver each one.

(some supposedly relevant parameters from supposedly relevant config files:)
my.cnf
key_buffer_size = 16M
max_allowed_packet = 180M
table_open_cache = 64
sort_buffer_size = 4M
net_buffer_length = 32K
read_buffer_size = 2M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 32M

postfix - main.cf
lmtp_destination_concurrency_limit = 30
lmtp_host_lookup = native ( to avoid dns issues, it uses /etc/hosts)
mailbox_transport = dbmail-lmtp:localhost:24

dbmail.conf
max_db_connections = 80 [. as you can see here, I tried to improve its
performance, without success though]
sqlsocket = /var/run/mysql/mysql.sock

On the other hand I have another server in another place running same
version of programs but dbmail 2.2.17. In this one, when I want it to
work faster I just improve all the parameters about the processes:

NCHILDREN
MAXCHILDREN
MINSPARECHILDREN
MAXSPARECHILDREN
MAXCONNECTS
and then I get a lot of dbmail-lmtp process, and they do the job really
fast, of course, at cost of a lot of memory...

of course, I'm aware of the "Server Changes", that's why in the other
deployment I've tried improve the "max_db_connectons", because I guess
it plays as a kind of substitute, so to speak, to all the other
processes parameters listed above. Probably I'm wrong.

Now I ask you: is there a way to make it behaves just like my old dbmail
2.2.17? Let's suppose I have memory to spend and I would like it to
deliver all my local messages really fast.

Actually by now, It's still not a serious issue, but I fear It will be.
And also I'm really curious to understand why it happens.

Thanks in advance.
Remy

_______________________________________________
DBmail mailing list
DBmail [at] dbmail
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

h.reindl at thelounge

Jun 24, 2012, 2:40 AM

Post #2 of 2 (233 views)
Permalink

Re: slow deliver [In reply to]

Am 24.06.2012 04:56, schrieb remy:
> I have a fresh installation of dbmail 3.0.2. (mysql 5.1.46; postfix
> 2.7.1 in a openSuSE 11.3 everthing in the same server).

update to MySQl 5.5 if possible

> (some supposedly relevant parameters from supposedly relevant config files:)

they most interesting ones are innodb-settings
but let's look to you provided ones

get "mysqltunber.pl", it will show you taht many of your settings
below would kill you machine in the worst case if all connections
are used by out-of-memorfy BUT do not blindly believe any output
from mysqltuner to higher settings, you should use uit more to make
sure not wasting ressources without any benefit

> my.cnf
> key_buffer_size = 16M

may be way to less, depens on your databases (mysqltuner)

> max_allowed_packet = 180M

OK

> table_open_cache = 64

http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_table_open_cache

should be max_connections x table_count

> sort_buffer_size = 4M

this is wy too high

buffer allocatin happens per connection / thread
memorfy allocation needs ressources

sort_buffer_size = 320K

> net_buffer_length = 32K

remove this one

> read_buffer_size = 2M

way to high, also per connection / thread and
there are many benchmarks that allocation above
128K may slow down things dramatically

read_buffer_size = 128K

> read_rnd_buffer_size = 4M

way too high
read_rnd_buffer_size = 256K

> myisam_sort_buffer_size = 32M

this one is OK and needed for "optimize tbale" on large MyISAM tables
___________________________________

what is much more interesting are the innodb-settings
you did not care about - below my reommended ones for
MySQL 5.5 while you must check with the error-log which
are not supported at 5.1 if you can not upgrade

"innodb_buffer_pool_size" is the most important one
and should be in the baest case as lage as the whole
database, my expiereince is that 33-50% are for
dbmail OK

"innodb_log_file_size" is a litle problematic to change
please consult google how to do or leave it untouched
and maybe "innodb_log_buffer_size" can help you
reduce the pressure here

innodb_buffer_pool_size = 3072M
innodb_buffer_pool_instances = 3
innodb_purge_threads = 1
innodb_max_purge_lag = 200000
innodb_max_dirty_pages_pct = 60
innodb_additional_mem_pool_size = 64M
innodb_log_file_size = 512M
innodb_log_buffer_size = 256M
innodb_thread_concurrency = 32
innodb_thread_sleep_delay = 10
innodb_flush_log_at_trx_commit = 2
innodb_support_xa = 1
innodb_lock_wait_timeout = 50
innodb_table_locks = 0
innodb_checksums = 0
innodb_file_format = barracuda
innodb_file_per_table = 1
innodb_open_files = 600
innodb_io_capacity = 300
innodb_read_io_threads = 8
innodb_write_io_threads = 8
transaction-isolation = READ-COMMITTED

Attachments:

signature.asc (0.26 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads