Classifieds Plug-in throwing up huge error logs & site crashing

Since launching http://www.eqlife.co.uk, we're getting periodical site crashes triggered by something associated with the WordPress Classifieds plug-in. Error logs output the following query each time resulting in error logs well in excess of 100mb. No other errors (other than a few PHP depreciation messages) are shown.

[13-Apr-2011 10:39:19] WordPress database error Lock wait timeout exceeded; try restarting transaction for query UPDATE 'wp_options' SET 'option_value' = 'a:2:{s:8:\"versions\";a:2:{s:7:\"version\";s:5:\"2.0.0\";s:10:\"db_version\";s:3:\"2.0\";}s:4:\"data\";a:3:{s:17:\"post_types_loaded\";a:34404:{i:0;b:1;i:1;b:1;i:2;b:1;i:3;b:1;i:4;b:1;i:5;b:1;i:6;b:1;i:7;b:1;i:8;b:1;i:9;b:1;i:10;b:1;i:11;b:1;i:12;b:1;i:13;b:1;i:14;b:1;i:15;b:1;i:16;b:1;i:17;b:1;i:18;b:1;i:19;b:1;i:20;b:1;i:21;b:1;i:22;b:1;i:23;b:1;i:24;b:1;i:25;b:1;i:26;b:1;i:27;b:1;i:28;b:1;i:29;b:1;i:30;b:1;i:31;b:1;i:32;b:1;i:33;b:1;i:34;b:1;i:35;b:1;i:36;b:1;i:37;b:1;i:38;b:1;i:39;b:1;i:40;b:1;i:41;b:1;i:42;b:1;i:43;b:1;i:44;b:1;i:45;b:1;i:46;b:1;i:47;b:1;i:48;b:1;i:49;b:1;i:50;b:1;i:51;b:1;i:52;b:1;i:53;b:1;i:54;b:1;i:55;b:1;i:56;b:1;i:57;b:1;i:58;b:1;i:59;b:1;i:60;b:1;i:61;b:1;i:62;b:1;i:63;b:1;i:64;b:1;i:65;b:1;i:66;b:1;i:67;b:1;i:68;b:1;i:69;b:1;i:70;b:1;i:71;b:1;i:72;b:1;i:73;b:1;i:74;b:1;i:75;b:1;i:76;b:1;i:77;b:1;i:78;b:1;i:79;b:1;i:80;b:1;i:81etc etc......}}}' WHERE 'option_name' = 'classifieds_options' made by require, require_once, require_once, require_once, do_action, call_user_func_array, Classifieds_Core_Data->load_data, update_site_option, update_option

The site is running on the latest versions of WP and BP and all plug-ins are up-to-date. Server details provided below.

Apache/2.2.14 (Unix) mod_ssl/2.2.14 OpenSSL/0.9.8l
PHP/5.3.1
MySQL client version: mysqlnd 5.0.5-dev - 081106 - $Revision: 289630 $

The site is usually bought back up by restarting MySQL services and we're hoping an increased packet limit will stop the site going down but we could really do with identifying the route of the problem.

I'm completely stuck so any ideas would be a massive help!

  • Julian Evans

    Don't suppose anyone has had a chance to look into this a little further?

    It's becoming a bit of an issue as we think that the problem with mySQL logs filling up (as a result of the classifieds plug-in error) is in turn filling up the drive and bringing it down. This problem (and a potential problem with replication) is affecting our entire LAMP server.

    Any help would be massively appreciated.

  • Julian Evans

    The server spec is 4 virtual CPUs, 4Gb ram - VMWare virtual machines.

    MySQL config as follows:

    # Example MySQL config file for very large systems.
    #
    # This is for a large system with memory of 1G-2G where the system runs mainly
    # MySQL.
    #
    
    # 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
    skip-external-locking
    key_buffer_size = 384M
    max_allowed_packet = 16M
    table_open_cache = 512
    sort_buffer_size = 4M
    read_buffer_size = 2M
    read_rnd_buffer_size = 8M
    myisam_sort_buffer_size = 64M
    thread_cache_size = 8
    query_cache_size = 64M
    # Try number of CPU's*2 for thread_concurrency
    thread_concurrency =4
    
    # Enable MySQL 5.5 Performance Schema
    performance_schema
    
    # 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
    
    # Replication Master Server (default)
    # binary logging is required for replication
    log-bin=mysql-bin
    
    server-id = 1
    
    # binary logging - not required for slaves, but recommended
    #log-bin=mysql-bin
    #
    # binary logging format - mixed recommended
    #binlog_format=mixed
    
    # Point the following paths to different dedicated disks
    #tmpdir         = /tmp/
    #log-bin        = /path-to-dedicated-directory/hostname
    
    # Uncomment the following if you are using InnoDB tables
    datadir=/mysql_data
    innodb_data_home_dir = /mysql_data/
    innodb_log_group_home_dir = /mysql_data/
    
    expire_logs_days=5
    
    #innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend
    
    # You can set .._buffer_pool_size up to 50 - 80 %
    # of RAM but beware of setting memory usage too high
    #innodb_buffer_pool_size = 384M
    #innodb_additional_mem_pool_size = 20M
    # Set .._log_file_size to 25 % of buffer pool size
    #innodb_log_file_size = 100M
    #innodb_log_buffer_size = 8M
    #innodb_flush_log_at_trx_commit = 1
    #innodb_lock_wait_timeout = 50
    innodb_flush_log_at_trx_commit = 1
    sporadic-binlog-dump-fail
    sync_binlog = 1
    log-output = TABLE
    slow-query-log
    expire_logs_days = 10
    log-queries-not-using-indexes
    performance_schema_events_waits_history_long_size = 10000
    max_connections=300
    log_warnings=2
    connect_timeout=20
    
    long_query_time = 10
    performance_schema_events_waits_history_size = 10
    auto_increment_offset = 1
    max_connect_errors = 100
    
    [mysqldump]
    quick
    max_allowed_packet = 16M
    
    [mysql]
    no-auto-rehash
    # Remove the next comment character if you are not familiar with SQL
    #safe-updates
    
    [myisamchk]
    key_buffer_size = 256M
    sort_buffer_size = 256M
    read_buffer = 2M
    write_buffer = 2M
    
    [mysqlhotcopy]
    interactive-timeout