Mark from support said I hit a known Xen bug, and the workaround is to boot with the 64bit kernel isntead of the 32bit kernel.

So I guess if your node does not come up, try the 64bit kernel!

I hit that bug with a few servers, it's a pain since the servers used pv_grub so had to be migrated to another host again that wasn't effected by the bug. Hopefully that get's resolved soon.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

I hope this means you're up and running - without further incident - with your new RAM on one of the new servers.

I've just migrated my Linode from 1024 to 2048 and I've landed on new hardware. Yay! (London DC)

I'm in Newark and still running on L5520

I'm in London DC, and different hardware on different linodes appears;

cat /proc/cpuinfo | grep 'model name'
model name : Intel(R) Xeon(R) CPU E5-2630L 0 @ 2.00GHz

Another one:

cat /proc/cpuinfo | grep 'model name'
model name : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz

Mixed "new" hardware? (2630L - 2670)

I've gone through several hosts in London and they seem to be an even split between the 2630L and 2670. The 2670's seems to have a measurable difference in performance but that could just be the load on the host.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

Did any of you who have upgraded do a test of disk I/O?

My Db is really down on its knees during peak hours and all I can think of causing this, since I've made no change since before the upgrade (and the traffic is somewhat "constant") is that the disk on these machines are considerably worse, performance wise, than that of the hardware used before the upgrade.

I'm sort of out of ideas here other than checking with you guys if you have a similar experience?

I've had 2 out of 4 problematic migrations that have had poor disk IO. I contacted support and they migrated the servers to another host, the hosts I was on had users with heavy disk usage.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

Ugh... Just got an email about my new E5-2670 box needing downtime for maintenance on 5/8...

_________________
Jason Litka
Utter Ramblings

Me too are you on london588? Must be something pretty important that's broken to require 45 minutes downtime.

You could ask support to migrate to a different host, that would most likely require less down time depending on the size of your disk.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

I've got them for half of my nodes(*) across several accounts, in both Newark and Dallas data centers, and on both E5-2570 and E5-2630L nodes (but not all such nodes). For a pair of more critical machines I did request a migration for so I could control the down time.

It actually takes a host quite a while to fully recover from a reboot (guest restarts are spread over time). So the actual maintenance might be relatively quick, or even just a software update or configuration change that requires a restart, but most of the window is then reserved for recovery from the reboot.

-- David

(*) Edit: I forgot a node, so it's half not more than half. It's only 5 of 10 nodes (9 of which use new hosts), but it may indicate that it's a broad based adjustment to many of the newer hosts.

More than half of your nodes? I feel fortunate! I've only had one...so far.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue

No, different DC.

I'm guessing that this has something to do with the poor disk performance a lot of people have been reporting. BIOS, RAID, or drive firmware update probably. Something is probably causing the disks to really suck under high queue depth.

_________________
Jason Litka
Utter Ramblings

It could also be something to do with the xen bug where some hosts can't boot 32 bit kernels in certain areas of memory..I hit that one a lot. The node that's scheduled for migration for me keeps most of it's data in memory so I wouldn't notice a disk slowdown on that one.

_________________
Paid support
How to ask for help
1. Give details of your problem
2. Post any errors
3. Post relevant logs.
4. Don't hide details i.e. your domain, it just makes things harder
5. Be polite or you'll be eaten by a grue