MySQL (innodb) performance tuning

The smallest member of SonicWall's UTM firewall is the SonicWall TZ100, or TZ100 in short. This little, white-looking appliance, albeit low-end, is a 100% UTM-enabled device, capable of url/content filtering, antivirus inspection and IDS/IPS analysis. You can read the full SonicWall TZ 100 product specifications here, while you can download the complete SonicWall TZ's series PDF datasheet from http://www.sonicwall.com/emea/488_6392.html

Current bare hardware list price is 295$, while a 1 year UTM licenze (yes, you need a license for that) costs another 225$. If you buy the TotalSecure 100 bundle (hardware + 1 year license), list price is at 465$. List price are obviously subject to change; however, you can not expect prices to fall down by a great amount. The point is that we are dealing with a very capable SonicOS-based appliance that boast 5 Fast Ethernet port and quite interesting UTM throughput, as SonicWall state a ~25 Mbit/s full UTM (antivirus + IDS/IPS) performance. Firewall and VPN specifications are quite respectable, being rated at 100 Mbit/s and 75 Mbit/s respectively.

On 12 October 2011 AMD disclose its new flagship CPU: the Bulldozer-based FX-8150 processor. Equipped with 16 MB L2/L3 caches, eight integer cores and four beefed-up FMAC FPUs, the new architecture sound very promising.

However, as many online reviewers discovered, the new AMD Bulldozer architecture didn't performs so well, especially in desktop workloads. Sure, in many cases it was a significant improvement versus the old K10-based PhenomII processors. At the same time, it fail to impress in a large number of tests.

The key question is: why? Why the new AMD processor, with its massive 16 MB cache and 1.2B total transistors number, barely outperform the old Phenom processors? And why sometime it is even slower? This article is going to shed some light on the problem.

Almost one year ago, I checked how different cache settings affected KVM storage subsystem performance. Results were very clear: to obtain good I/O speed, you had to use the write-back or none cache policies, avoiding the write-through one. However, as the write-back policy intrinsic comported some data-loss risk, the safer bullet was to not use any host-based cache (the “nocache” KVM option).

Some months ago, I wrote an article showing a significant problem regarding KVM and Qcow2 implementations under Red Hat Enterprise Linux 6.0. The problem was that using the default, not-preallocated Qcow2 file backend, I/O performance greatly suffered. You can read here for more information.

Today, I want to see if anything has changed in the last months: more specifically, I am curious to know if manual metadata preallocation remain a necessity or if the underlying Qcow2 / KVM code improved at a point were we can simply forget about manually creating a preallocated Qcow2 file backend.