Subject: Re: Lost connection to MySQL server during query
To: None <jadacuma@ched.gov.ph>
From: =?ISO-8859-1?Q?Andreas_Ha=DFfeld?= <andreas@hassfeld.net>
List: netbsd-users
Date: 03/12/2007 16:01:24
Joseph A. Dacuma wrote:
> Hi All!
> 

Hi,

> Whenever I try to restore a mysqldump file this message appears:
> 
> ERROR 2013 (HY000) at line nnn: Lost connection to MySQL server during query.
> 
> The restore procedure is being done on a local machine where the Mysql 5
> DB server also resides. This happens on both i386 and amd64 boxes running
> on NetBSD 3.1 stable using pkgsrc 2006 Q4 (MySQL 5.0.27). I remember one
> other box running MySQL 5 from pkgsrc 2006q3 also having the same problem.
> 
> Please also note that on both machines, I tried using using a default
> large my.cnf. I also tried both with modifications on the following:
> 
> query_cache_limit = 4M
> query_cache_size = 128M
> bulk_insert_buffer_size = 8M
> 
> All four tests yeiled the same error. I tried restoring the same dumpfile
> on another DB server also running MySQL 5.0.27 on FreeBSD 6 release with
> no modifiacations, everything went ok.
> 
> I noticed that if the table to be restored is too large the restore
> procedure stops. On smaller ones its successful. Anyone experiencing the
> same problem? I may have missed something on our NetBSD boxen.
> 

I solved that by cranking up memory limits via a custom kernel with 
increased maxusers and a few other tuning values:


maxusers        128             # estimated number of users

options         CHILD_MAX=640   # max simultaneous processes
options         OPEN_MAX=256    # max open files per process
options         SHMMAXPGS=59400
options         SHMSEG=512
options         SEMMNI=512      # Maximum number of sets of IPC semaphores
options         SEMMNS=1024     # Sys-wide max number of individual IPC 
semaphores
options         SEMMNU=512
options         SEMMAP=512


You could also create an old style mysql-dump with one column per line 
using the following switch: --skip-extended-insert
but I bumped into memory limits even when doing large queries, so 
increasing resources might be better.

> 
> Joseph
> 

Yours,
Andreas