List Info

Thread: Mysql has gone away :'(




Mysql has gone away :'(
country flaguser name
United States
2007-03-28 18:14:07
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?
 
Thanks!
 
2007-03-28 18:06:44 Maia: [process-quarantine-sub] Learned mail item 2914787 as spam and reported it
2007-03-28 18:06:47 Maia: [process-quarantine-sub] Learned mail item 2914860 as spam and reported it
2007-03-28 18:06:49 Maia: [process-quarantine-sub] Learned mail item 2914894 as spam and reported it
2007-03-28 18:06:51 Maia: [process-quarantine-sub] Learned mail item 2914897 as spam and reported it
2007-03-28 18:06:53 Maia: [process-quarantine-sub] Learned mail item 2914952 as spam and reported it
2007-03-28 18:06:55 Maia: [process-quarantine-sub] Learned mail item 2915096 as spam and reported it
2007-03-28 18:06:59 Maia: [process-quarantine-sub] Learned mail item 2915746 as spam and reported it
2007-03-28 18:07:00 Maia: [process-quarantine-sub] 16 spam items processed (16 learned, 16 reported)
2007-03-28 18:07:02 Maia: [process-quarantine-sub] 0 non-spam items processed (0 learned)
Subroutine new redefined at /etc/mail/spamassassin/FuzzyOcr. pm line 48.
Subroutine dummy_check redefined at /etc/mail/spamassassin/FuzzyOcr.pm line 59.
Subroutine fuzzyocr_check redefined at /etc/mail/spamassassin/FuzzyOcr.pm line 63.
Subroutine fuzzyocr_do redefined at /etc/mail/spamassassin/FuzzyOcr.pm line 101.
2007-03-28 18:07:04 Maia: [process-quarantine-sub] 0 spam items processed (0 learned, 0 reported)
2007-03-28 18:07:05 Maia: [process-quarantine-sub] 0 non-spam items processed (0 learned)
DBD::mysql::st execute failed: MySQL server has gone away at /var/spool/amavis/maia/scripts/process-quarantine.pl line 382.
2007-03-28 18:07:05 Maia: [process-quarantine] FATAL ERROR: Couldn't execute query: MySQL server has gone away
 
 
 
 ;

George Armstrong
Assistant Director Technology
Monroe-Woodbury CSD
Harriman, NY  10926
845-460-6600
garmstromw.k12.ny.us">garmstromw.k12.ny.us
george.armstrongmw.k12.ny.us">george.armstrongmw.k12.ny.us

  
Re: Mysql has gone away :'(
country flaguser name
Canada
2007-03-29 16:33:27
-----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 <rjlrenaissoft.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-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )