Performance impact of Zones.
I was really astonished when i saw this question. Because this question was a old acquaintance from years ago, that i didn’t heard for a long time. However there was it again. The question: “What’s the overhead of Zones?”. Sun was and Oracle is not saying “zero”. We saying saying minimal. However during all the performance analysis gigs on customer systems i made since the introduction of Zones i failed to measure any overhead caused by zones. When there was overhead in that situation it was in the error of measurement.
What i saw however, was additional load intoduced by processes that wouldn’t be there when you would use only one zone Like additional monitoring daemons, like additional daemons having a controlling or supervising job for the application that resulted in slighly longer runtimes of processes, because such additional daemons wanted some cycles on the CPU as well. Like additional sshd daemons, like additional init processes. So i ask when someone wants to tell me that he measured a slight slowdown, if he or she has really measured the impact of the virtualization layer or of a side effect described above.
It seems to be a little bit hard to believe, that a virtualisation technology has no overhead, however keep in mind that there is no hypervisor and just one kernel running that looks and behaves like many operating system instances to apps and users. While this imposes some limits to the technology (because there is just one kernel running you can’t have zones with different kernels versions running … obvious even to the cursory observer), but that is key to it’s lightweightness and thus to the minimal overhead.
Perhaps when you still don’t believe me, you believe some numbers … there are already quite a number of benchmarks using Zones (some of them what marketing calls “World Records”, i call them “really fscking good result” ;) ). Keep in mind that you normally configure everything away in benchmarks, that takes away performance and if there would be a performance gain, it would be realtively easy to configure the same without containers. However all this benchmarks are using zones.
SPECjEnterprise2010 on Oracle WebLogic Server Standard Edition Release 10.3.5 on SPARC T4-4 on Solaris 10:
Four application server instances were hosted in 4 separate Solaris Containers.
Eight application server instances were hosted in 8 separate Solaris Containers.
Oracle Fusion Middleware WebLogic Avitek Medical Records Sample Application on T3-1B
The Avitek Medical Records application instances were deployed in Oracle Solaris zones on the SPARC T3-1B server, allowing for flexible, scalable and lightweight architecture of the application tier.
Eight application server instances were hosted in 8 separate Solaris Containers.
Seven Containers were bound to separate processor sets where each pset
consisted of 4 cores (32 HW threads) using /usr/sbin/psrset -b PSET PID.
The eighth Container used the default processor set.
The Solaris Container and Processor Set configuration is in the FDA.
Four application server instances were hosted in 4 separate Solaris Containers.
PeopleSoft HRMS 9.1 on SPARC T4 Servers:
Each PeopleSoft Application Server instance running in an Oracle Solaris Container was configured to run 5 application server Domains with 30 application server instances to be able to effectively handle the 15,000 users workload with zero application server queuing and minimal use of resources.
Siebel CRM 8.1.1 on SPARC T3-1
Oracle Solaris Containers were used to virtualize the Web and DB tier of the benchmark.
SAS Grid Computing 9.2 on Sun Fire X2200M2 on Solaris 10
The other piece that resulted in a significant increase in throughput through the 10GbE NIC was to use multiple NFS client processes. We achieved this through zones.
JD Edwards EnterpriseOne Day in the Life Benchmark with Added Batch Component on SPARC T3-1
The solution exercises various JD Edwards EnterpriseOne applications while running Oracle WebLogic Server 11g Release 1 and Oracle Web Tier Utilities 11g HTTP server in Oracle Solaris Containers, together with the Oracle Database 11g Release 2.
Finacle 10.3 on T3-1, T3-2 and M-series (external):
During the benchmark runs, Finacle e-banking solution was deployed in a virtualized environment using the Oracle Solaris Zones feature of Oracle Solaris.
Eight sparse root Oracle Solaris Containers each with one 1.6 GHz eight-core UltraSPARC T2 Plus processor and 32 GB memory were configured on two identical Sun SPARC Enterprise T5440 servers to run eight BI nodes inside the virtual servers.
Bank: Server was divided into four Solaris Containers (zones). One webserver instance per zone
Ecom: Server was divided into four Solaris Containers (zones). One webserver instance per zone.
Supp: Server was divided into four Solaris Containers (zones). One webserver instance per zone.
An article of Jeff Victor about “Virtual Overhead?” citing a number of SAP benchmarks running on zones comparing them to other virtualization solutions respectively uncontainered Solaris 10 environments. So you see, even in benchmark environments where you fight for the last percents, using Solaris Zones is nothing uncommon. Perhaps this is an even better data point that just me saying that in the beginning ;)