We are often asked by clients to help them squeeze more performance from an existing infrastructure, to speed up an application or shorten an IT-dependent business process. Early on in the discussion there's a tendency for sysadmins and architects to dive in to technical minutiae, the black magic and chicken-waving of memory page sizes, block alignment, cache segmentation, and thread pinning. This is almost always a mistake at this early stage and can drain days and weeks with few results. The business gets frustrated when deadlines are missed and the techies can't answer simple questions like "when will this be fixed?", "how much sooner will I get my results?", and "what will it cost to process data within that time window?". Black magic has a time and a place, but at 360is we save our voodoo until the latter stages of a performance tuning project.
Before making non-portable, hard-to-maintain, unsupported, obscure, or fragile configuration changes that break when you least expect them (and may not even be understood by those operating the infrastructure) we start with the basics:
- Is what you have, setup properly? Many complex multi-vendor data centres have a setup that is sub-optimal in some way.
- Is the system already performing more-or-less as you would expect "on paper" +/-25%? We whiteboard a block diagram of devices, buses, networks, data volumes, benchmarks.
- If it isn't then there is probably a significant configurational mistake to be found. Forget about jumbo frames if your switch is stuck in half-duplex mode.
- Focus on the biggest wins first, they are often the easiest to achieve. Only then do we go chasing marginal gains with our consultant's Juju. Don't waste days chasing the last 3% unless that gain makes economic sense for your business process.
At 360is we are fans of FreeBSD, and regularly recommend it as a secure, low-maintenance, stable, and performant, server operating system. Unfortunately there is no official support for FreeBSD in the Citrix XenServer product. What this means in practice is that those wanting to run FreeBSD on XenServer deploy it in HVM mode and without Xen-Tools. Pure HVM mode is slow for network and disk access, and no Xen-Tools means no live migration, not good for production workloads.
Shooting for the biggest win first, we have made available a basic, paravirtualized-drivers-with-xentools-installed, FreeBSD 9.0 64-bit Template that delivers approximately twice the performance of the pure HVM install of the Operating System. No tuning, no special settings, absolutely no chicken-waving.
- FreeBSD 9.0
- 64-Bit (amd64)
- Paravirtualized Drivers in the XENHVM kernel
- Open Source Xen-Tools pre-installed
- Small (389MB) XVA file
Get the FreeBSD 9.0 XenServer Template XVA, (cookies/valid Email required in order to be sent the password).
If you need to extract more performance or reliability from an existing infrastructure, application, or IT-driven process, 360is consultants know how, get in touch.
=== Update 26-07-12 ===
As we always get asked about these "relative-to" bar charts, the absolute figures were 188MB/sec for the VM derived from our template, and 92MB/sec for the ordinary install using Citrix "Other OS" template. The fast VM consumed 67% of 1 vCPU on an otherwise idle system. The physical hardware used was a VMCo VA12xx Appliance with its local IOPS sink configured as an SR.
=== Update 11-10-12 ===
This XVA was prepared for XenServer 6.0.2, and probably wont work on XenServer 6.1. If you have a commercial imperative for it on a different version of XenServer, with a different version of FreeBSD other than 9.0, or for that matter with i386 versus amd64, then get in touch with our project office.
Posts
