No garbage hassles as BT goes Azul

New platform overcomes Java VM pausing problems

Adding storage to a network is straightforward; adding processing power tends to involve a lot more complexity. This is something Azul Systems aims to change. Following the recent announcement of its second generation Vega processor, is today’s news that BT will be using the company's processing appliances to handle both its existing web applications, as well as providing the foundation for a utility computing farm – part of BT’s 21st Century Network.

The Azul platform is more than just a box you connect to your network, which replaces software virtual machines. It’s also a set of tools for managing application performance and handling how you bill the rest of the business for CPU usage. Mainframe administrators will be familiar with these techniques, but they’re still new to the arrays of application servers that now run many of our businesses. Being able to bill for actual CPU and memory usage is a key part of any utility computing platform – whether it’s Sun’s $1 per CPU per hour or an IT department billing the rest of the business for application operations.

We spent some time last week at Azul’s Mountain View offices looking at their appliance management tools and investigating some of the key differences between Java applications running on a traditional JVM and those running on an Azul processing appliance. Web-based management tools give an overview of what all the processors on all the appliances in a processing pool are running and how hard they’re working, drilling down into each application instance, and to each thread. That’s a detailed view into the operation of a virtual machine that can help with debugging and code optimisation.

Java’s garbage collection system can be a problem for application development, especially as it affects applications that need a large amount of system heap. It’s difficult to put a whole database into memory, as your JVM will pause your application, “stopping the world”, while it scavenges free memory – with no control of just how long it will pause your code for, or just when it’ll kick in… The larger your heap size, the longer the pause. There are fixes, usually involving using server farms and database pools, as well as handing heap-intensive applications back to the database tier.

Things are different for applications that run on Azul’s processing appliances. With 96GB of heap available to each thread, there’s a lot of scope for building and running memory intensive applications. Garbage collection is no longer a problem, as a parallelised concurrent garbage collector handles memory management without affecting your applications. Similar tools also handle heap fragmentation issues. A garbage collection thread will run concurrently with each application thread, marking memory, relocating live objects, and finally remapping memory.

While Azul describes its garbage collection as “pauseless”, it does briefly pause your application at certain points – though this is imperceptible to users – and overall application performance is deterministic. With a deterministic JVM that runs with very brief pauses, an application running on Azul appliances can work with very large in memory databases - without slowing down at just the wrong moment.

According to BT director of operational integrity Claire Rawlins, Azul will save the giant telco from “the speculative capacity planning and over-provisioning that was once needed with more traditional approaches”.

<Shows a rack of Azul appliances.

BT also appreciates the fact that Azul appliances are less demanding in the server room; Azul fits 384 cores into an 11u rack that produces less heat than a standard server (as the illustration suggests).®

Sponsored: Network DDoS protection