ERROR 2006 (HY000) at line 257: MySQL server has gone away

ERROR 2006 (HY000) at line 257: MySQL server has gone away

When doing a mysql dump to the database, if you get this error, it means that you have a connection timeout on the database or your restore is doing a chunk of data that exceeds the max allowed packets.


If you are on AWS follow the steps below

  1. Go to your RDS Dashboard and click Parameter Groups.
  2. Click Create DB Parameter Group, name it something like ‘LargeImport’, (making sure the DB Parameter Group Family you select matches your instance version) and edit the parameters.
  3. Increase the ‘max_allowed_packet‘ on ‘LargeImport’ to accommodate your import size (Valid values are 1024-1073741824).
  4. Increase the ‘wait_timeout‘ parameter to accommodate your import size. (Valid values are 1-31536000 seconds).
  5. Save your changes.
  6. Click Instances in the left column and select your instance.
  7. Click Instance Actions and choose Modify.
  8. Change the Parameter Group to your new ‘LargeImport’ group and click Continue.
  9. Click ‘Modify DB Instance’.
  10. Once the change has completed, click Instance Actions again and reboot your instance.

Once your instance has rebooted, you should be able to do larger sql imports.

Once you’ve completed your import, switch your instance parameter group back to the default parameter group and reboot it again.

On mysql server

Increase the settings in my.cnf file and restart mysql.


Mysql database size

Find the database size of each database

Run the below query at the mysql prompt

SELECT table_schema “Data Base Name”,
sum( data_length + index_length ) / 1024 / 1024 “Data Base Size in MB”,
sum( data_free )/ 1024 / 1024 “Free Space in MB”
FROM information_schema.TABLES
GROUP BY table_schema ;

How to generate JVM Heap dump

  • Find the process Id of the java process

In linux. Go to command line.

ps aux | grep ‘java’


  • To generate the dump.


jmap -dump:format=b,file=/tmp/heapdump-001.hprof <process id>


$ jmap -dump:format=b,file=/tmp/heapdump-001.hprof  31467

Dumping heap to /tmp/heapdump-001.hprof …

Heap dump file created

 The dump file wil be generated at /tmp/heapdump-001.hprof.


$ ls -al /tmp/heapdump-001.hprof

-rw——- 1 admin admin 48657063 Feb 23 10:00 /tmp/heapdump-001.hprof


 You can use Eclipse Memory Analyzer  to analyze the heap dumps

Linux boot process


Based on the boot order given in the bios, the device from where the boot sector has to be
loaded is determined.


Bios loads and executes the first 512 bytes off the bootable device. The MBR points to the boot loader.

At this point you will be presented with the options of selecting the OS to boot. The grub

config file is /boot/grub/menu.lst

Grub can load an os directly or chainload another bootloader. The latter is not preferred

since we need to maintain a second bootloader. This can be used when you need to load an OS

which is not supported by GRUB

Set the root device where the os is located.

root (hd0,0)

Load the kernel image

kernel /vmlinuz-2.6.18-128.4.1.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet

Load the kernel modules using initrd image , if needed

initrd /initrd-2.6.18-128.4.1.el5.img

To load an unsupported OS

Set GRUB’s root device to the partition by the command

grub> rootnoverify (hd0,0)

Set the active flag in the partition by the command

grub> makeactive

Load the boot loader by the command

grub> chainloader +1

`+1′ is the offset. +1 indicates that GRUB should read one sector from the start of the partition.


In  the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM  disk  initialized  by the boot loader).  In the second phase, additional drivers or other modules are loaded from the initial  root  device’s  contents. After loading the additional modules, a new root file system (i.e., the normal root file system) is mounted from a different device.

The boot loader loads the kernel program and the initrd’s content into the memory.

Ram disk(/dev/initrd) is initialized by the boot loader before kernel startup. On kernel startup, the kernel uncompresses and copies the content of initrd into the ram device(/dev/ram0) and frees memory used by initrd.

The kernel then rw mount the ram device(/dev/ram0) as initial root file system.

The executable file linuxrc load the necessary modules from the ramdisk. Once linuxrc terminates,the normal file system is mounted.

If the normal root filesystem has the /initrd directory, the ram disk(/dev/ram0) is moved to that.(this will be read-only) The already running processes from /dev/ram0 will continue to run. If the /initrd directory is not present, the ram disk is unmounted.

The usual boot sequence (e.g. invocation of /sbin/init) is performed on the normal root file system.

INIT process

The init process is the last step in the boot procedure and identified by process id “1”. Init is responsible for starting system processes as defined in the /etc/inittab file. Init typically will start multiple instances of “getty” which waits for console logins which spawn one’s user shell process. Upon shutdown, init controls the sequence and processes for shutdown. The init process is never shut down. It is a user process and not a kernel system process although it does run as root.

System Login Prompt

The /etc/inittab will initialize the scripts in the specified run levels.} else {