I looked at /var/log/syslog and found that my problem is worse than it seemed: Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Dump of the tablespace extent descriptor: len 40; hex 00000000000006e40000400008e60000400002f600000001ffffffffffffffffffffffffffffffff; asc @ @ ; Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Serious error! InnoDB is trying to free page 17131 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: though it is already marked as free in the tablespace! Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: The tablespace free space info is corrupt. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: You may need to dump your InnoDB tables and recreate the whole Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: database! Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Please refer to Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: about forcing recovery. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 100607 9:41:28InnoDB: Assertion failure in thread 2982538128 in file fsp0fsp.c line 2981 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: We intentionally generate a memory trap. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: Submit a detailed bug report to http://bugs.mysql.com. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: If you get repeated assertion failures or crashes, even Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: immediately after the mysqld startup, there may be Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: corruption in the InnoDB tablespace. Please refer to Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: InnoDB: about forcing recovery. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 100607 9:41:28 - mysqld got signal 11; Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: This could be because you hit a bug. It is also possible that this binary Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: or one of the libraries it was linked against is corrupt, improperly built, Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: or misconfigured. This error can also be caused by malfunctioning hardware. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: We will try our best to scrape up some info that will hopefully help diagnose Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: the problem, but since we have already crashed, something is definitely wrong Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: and this may fail. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: key_buffer_size=16777216 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: read_buffer_size=131072 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: max_used_connections=2 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: max_connections=100 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: threads_connected=1 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: It is possible that mysqld could use up to Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 233983 K Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: bytes of memory Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Hope that's ok; if not, decrease some variables in the equation. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: thd=(nil) Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Attempting backtrace. You can use the following information to find out Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: where mysqld died. If you see no messages after this, something went Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: terribly wrong... Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Cannot determine thread, fp=0xb1c5cf48, backtrace may not be correct. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Stack range sanity check OK, backtrace follows: Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x81cd88d Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x83cdf5c Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x83664c5 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x836676c Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x836c957 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x837660e Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x837865e Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x83466ce Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x8347ac7 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x832ab97 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x838a6e9 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0x830df1c Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0xb76d84fb Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: 0xb74ecf5e Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: New value of fp=(nil) failed sanity check, terminating stack trace! Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: stack trace is much more helpful in diagnosing the problem, so please do Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: resolve it Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: The manual page at http://www.mysql.com/doc/en/Crashing.html contains Jun 7 09:41:28 lru-lnx-srv02 mysqld[27060]: information that should help you find out what is causing the crash. Jun 7 09:41:28 lru-lnx-srv02 Koha Zebraqueue [31497]: failed to connect to DB: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (111) Jun 7 09:41:28 lru-lnx-srv02 mysqld_safe[27083]: Number of processes running now: 0 Jun 7 09:41:28 lru-lnx-srv02 mysqld_safe[27085]: restarted Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Log scan progressed past the checkpoint lsn 1 1833585166 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 InnoDB: Database was not shut down normally! Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Starting crash recovery. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Reading tablespace information from the .ibd files... Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Restoring possible half-written data pages from the doublewrite Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: buffer... Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Doing recovery: scanned up to log sequence number 1 1833662694 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 InnoDB: Starting an apply batch of log records to the database... Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Progress in percents: 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: InnoDB: Apply batch completed Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 InnoDB: Started; log sequence number 1 1833662694 Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: 100607 9:41:28 [Note] /usr/sbin/mysqld: ready for connections. Jun 7 09:41:28 lru-lnx-srv02 mysqld[27088]: Version: '5.0.51a-24+lenny1~bpo40+1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Debian) Best regards, Robert Meltz Field Service Engineer 770.458.8658 x108 404.642.9093 cell rmeltz@insolnet.com www.insolnet.com Follow us on Twitter: www.twitter.com/Insol_IT At Insol: ownership and partnership know no bounds. IT's personal. -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Robert Meltz Sent: Monday, June 07, 2010 8:56 AM To: Reed Wade Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] MySQL socket errors Thanks Reed, could you please clarify a bit? Are you referring to the line in my.cnf that contains "bind-address" because if so, it is already set to 127.0.0.1. Best regards, Robert Meltz Field Service Engineer 770.458.8658 x108 404.642.9093 cell rmeltz@insolnet.com www.insolnet.com Follow us on Twitter: www.twitter.com/Insol_IT At Insol: ownership and partnership know no bounds. IT's personal. -----Original Message----- From: reedwade@gmail.com [mailto:reedwade@gmail.com] On Behalf Of Reed Wade Sent: Friday, June 04, 2010 10:48 PM To: Robert Meltz Cc: koha@lists.katipo.co.nz Subject: Re: [Koha] MySQL socket errors Consider using the IP address (127.0.0.1) instead of localhost for the db connection. This will cause mysql to connect via TCP instead of using a named socket and may help -- assuming your database is responsive otherwise. ( Mysql's decision to trap the localhost name and act differently with it instead of making that a separate option is insane but in character. ) -reed On Sat, Jun 5, 2010 at 12:35 AM, Robert Meltz <RMeltz@insolnet.com> wrote:
Good Morning,
I am having problems with Koha returning the following error:
Koha error The following fatal error has occurred:
Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) at /usr/share/perl/5.8/CGI/Carp.pm line 314. Compilation failed in require at /usr/share/koha/lib/C4/Auth.pm line 30. BEGIN failed--compilation aborted at /usr/share/koha/lib/C4/Auth.pm line 30. Compilation failed in require at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25. BEGIN failed--compilation aborted at /usr/share/koha/opac/cgi-bin/opac/opac-detail.pl line 25.
If I refresh the page it usually works, but this error appears more often than not since yesterday morning. I looked at some performance items suspecting that it may be related to slow response from the underlying system.
top - 08:31:07 up 20:01, 1 user, load average: 0.21, 0.24, 0.25
# for i in a b; do hdparm -tT /dev/sd"$i"; done
/dev/sda: Timing cached reads: 2166 MB in 1.88 seconds = 1152.66 MB/sec Timing buffered disk reads: 22 MB in 3.28 seconds = 6.71 MB/sec
/dev/sdb: Timing cached reads: 2530 MB in 1.87 seconds = 1355.50 MB/sec Timing buffered disk reads: 34 MB in 3.32 seconds = 10.24 MB/sec
# mount /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) /sys on /sys type sysfs (rw,noexec,nosuid,nodev) varrun on /var/run type tmpfs (rw,noexec,nosuid,nodev,mode=0755) varlock on /var/lock type tmpfs (rw,noexec,nosuid,nodev,mode=1777) udev on /dev type tmpfs (rw,mode=0755) devshm on /dev/shm type tmpfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sdb1 on /var/lib type ext3 (rw,relatime,errors=remount-ro)
It looks to me like the drives are slow. Not all that surprising considering that there are 6 virtual machines running off the same hyper-V host. What can I do to increase the performance under these conditions, or am I on the wrong track entirely?
Best regards, Robert Meltz _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha