scipilot's questions

Recently our MySQL server has been "going away" (ie. the client connection drops out). After weeks of trying different things (like adjusting packet size), we've discovered that it's our Veeam imaging backups which use the VMWare API to snapshot and copy the vmdks etc.

We are using ESXi 5 with a Centos 6.4 guest, running (pretty much) only MySQL 5.1.69-log.

The change which seemed to initiate this problem was increasing the physical disk size to 300GB, from about 100, and resizing the guest filesystem to use most of the new capacity. Ever since the disk was increased, we've been getting these problems during backups - presumably due to the increase time it takes to perform snapshot related functions.

The new disks are 2x300GB Gen8 15k SAS in RAID1. The old disks would have been similar only smaller. The target of the Veeam process is a ReadyNAS over a 1Gb dedicated ethernet (i.e. separated from general office traffic).

The host is an HP DL380P tower:

==server spec (BASE CHASSIS)==
SERIES DL380P GEN8
PROCESSOR TYPE Intel Xeon E5-2609 v2 (2.5GHz/4-core/10MB/6.4GT-s QPI/80W)
NUMBER OF PROCESSORS 2 
MEMORY 80GB
INTERNAL DRIVE BAYS 8 SFF HDD Bays
COMPATIBLE HDD SFF SAS/SATA
HARD DISK CONTROLLER SMART ARRAY P420I/ZERO MEMORY CONTROLLER (RAID 0/1/1+0)

My "IT guy" has made a few tweaks to the Veeam config including skipping empty blocks (the majority of the new disk is empty), but this didn't seem to help at all.

Veeam haven't been much help either, saying "reboot the target" or "we just use VMWare APIs".

I believe the "stun" means the virtual machine simply freezes for a time (around 30s) then continues normally.

VMWare.log example:

Line 7411: 2016-06-08T17:11:44.910Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 21068381 us
Line 7556: 2016-06-08T17:22:24.608Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 19819322 us
Line 7700: 2016-06-08T17:22:30.140Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 1130044 us
Line 7929: 2016-06-08T17:23:08.616Z| vcpu-0| I120: Checkpoint_Unstun: vm stopped for 30197618 us

So my problem has two likely solutions:

1. Is there a way to prevent or reduce the "stunning" of a VMWare guest during imaging.

2. Is there a way to reduce the impact of the stun onto MySQL or the virtual network or Centos.

I have a server application which uses permanently connected incoming ports within the range that W2k8 now uses in the IANA recommended range of ~49000-65000. (For legacy reasons it's extremely difficult to change this, so I'm going to have to change Window's range to avoid my range, but that's not the question).

I've been researching how to avoid conflicts with ephemeral ports in Windows 2008 Server, but can't find details on the Windows algorithm for selecting ephemeral ports.

When the Windows network layer is assigning a 'random' ephemeral port for the response to an outgoing TCP/IP connection, does it test the proposed port to see if it's being used already?

(The Linux kernel seems to do a check_established test but could still re-use some used connections, so I'm wondering what decisions Windows might make in taking seemingly unused or idle ports off another process...)

i.e. if my server opens winsocks on all its ports, and keeps them in LISTENING state, will Windows respect and skip over them because they're in use? Or will it ignore the fact they're in use, and assign them to other processes anyway for ephemeral use, causing conflicts?

I have found that sometimes when my server starts it cannot allocate a few of its ports, because they're being used for random purposes by other processes - which makes sense and I understand that. But I haven't yet been able to prove if ports it does manage to initially open are subsequently 'stolen' for ephemeral purposes (it's a difficult thing to test or force due to the large range and random nature).

As I said, I am going to reconfigure windows to avoid my server anyway, so this question is more out of curiosity and to explain recent behaviour more clearly (to rule in/out other possible bugs!)

thanks in advance