-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
George Armstrong wrote:
> I have seen this happen on occasion. Seems if there is
a lot to process
> (over 2000+) from the hourly process-quarantine.pl
--learn --report cron
> job, MYSQL takes a coffee break. other times (even with
1500* 1700+ mail
> items) it works fine.
>
> Anyone know what I need to 'TweaK' in Mysql?
Hmmm. It's unusual to encounter that error with
process-quarantine.pl
(or any of the maintenance scripts, really); usually it
occurs on
low-traffic testbed systems with lots of idle time between
mail
arrivals, such that the MySQL socket connection times out
(see
<http://www.maiamailguard.com/maia/wiki/MySQLSer
verHasGoneAway>).
In this case it doesn't sound like a timeout issue, so
increasing
MySQL's timeout parameter probably won't make any
difference. In the
most general sense, the error simply means that the socket
connection to
MySQL got broken. If the MySQL server is still running, the
problem can
usually be solved just by establishing a new connection
(i.e. the
problem solves itself automatically the next time a Maia
process tries
to connect to the database); if the MySQL server has
actually crashed
this won't be possible of course.
You may want to check your MySQL logs to see if there's any
indication
of what's causing the disconnect to occur. If, for
instance, you're
exceeding some parameter limit that can be configured in
your my.cnf
file (e.g. memory allocation, buffer pool size, number of
concurrent
connections, etc.), increasing that setting may be the fix.
You won't
know /which/ parameter until you find some evidence in the
MySQL logs,
however.
Some general tweaking of MySQL for performance is a good
idea in any
case, and may implicitly solve your problem. Presumably
you're using
InnoDB tables (as you should), so most of the tweaks will
likely be to
the innodb_* settings, e.g.
skip-external-locking
max_connections=50
innodb_flush_method=O_DSYNC
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=1024M
innodb_additional_mem_pool_size=20M
table_cache=96
query_cache_limit=5M
query_cache_type=2
These numbers are not hard-and-fast, of course; they're
relative to the
amount of memory you have in the server. Settings like
innodb_buffer_pool_size can make a tremendous difference,
but don't
allocate much more than half of your physical RAM to that
setting.
You may also wish to search the archives of this list for
mysql tuning
tips; the subject has come up a number of times over the
years, with
advice from a good number of contributors. It's a subject
that merits
its own FAQ, really
- --
Robert LeBlanc <rjl renaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamail
guard.com/>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFGDDCnGmqOER2NHewRApsCAJ9IbRjozCDKhO0Oe0QxaHUoNbTc+gCg
rqfi
GFW5CXjjhDphIPJSkTCnw88=
=B8C0
-----END PGP SIGNATURE-----
_______________________________________________
Maia-users mailing list
Maia-users renaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users
|