Zone Alarm !!!
Karl Reitschuster
in Sun Solaris, System Environment
|
Post a Comment
|
3 References
Hi,
the title is not a title of a Science Fiction film or of a Hackers memories intruding networks or a gaming title but is SUN Solaris related. SUN Solaris 5.10 introduced a virtualization concept called Zones. A Zone is like a logical/virtual machine on a SUN Server Hardware. Zones are nearer bound to resources then for example a VM like VMware or Parallels (on Mac); This keeps the frictional loss of resources lower.
At our customer site database servers are driven in SUN Solaris Zones. Resources dependent on the implementation of a zone could be shared between the Zones. Hardware is better utilized.
But one drawback is here - it's to specify performance; After changing an internal Oracle parameter which could affect all execution plans i tested our batch jobs if they keep the timing windows. And ... they did not. All batches run 20-50% slower then expected. A quick view to the DB Console showed the root cause for this: Independent of the batch job some other programs consumed 100% CPU in an interval of 10-15 minutes as
you can see here :
You see in the graph the batch job allocated one Core - but on the Host graph you see some other programs allocated all 8 cores. I your database is the only one and you work in a Zone it's time for ZoneAlararm!! Another indicator something is sucking your resources is on the start page of the Db Console. On the Host CPU section CPU usage is monitored - the consumption of the current instance and Others. Others could be another database another program in the same Zone or in another one.
On Sun Solaris you can measure global (all(*) Zones) CPU usage with mpstat; and it showed 100% CPU usage for 8 cores. Hm ...
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 562 0 0 510 300 333 171 133 9 0 192 98 2 0 0
1 353 0 0 204 0 396 202 146 13 1 159 99 1 0 0
2 145 0 0 174 0 329 172 58 19 0 230 99 1 0 0
3 432 0 0 139 0 256 136 64 5 0 176 99 1 0 0
4 369 0 0 206 1 393 203 101 10 0 260 98 2 0 0
5 403 0 0 295 155 258 141 75 5 0 262 97 3 0 0
6 402 0 7 170 28 254 139 69 3 0 163 98 2 0 0
7 378 0 0 117 0 220 115 50 8 0 164 97 3 0 0
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 437 0 1827 531 303 370 199 154 13 0 265 98 2 0 0
1 468 0 0 486 0 449 227 179 19 0 204 98 2 0 0
2 658 0 0 434 5 320 164 69 18 1 283 99 1 0 0
3 141 0 0 401 0 275 142 67 12 0 154 99 1 0 0
4 368 0 0 475 1 393 209 98 11 0 188 99 1 0 0
5 315 0 0 598 177 316 172 95 15 0 241 98 2 0 0
6 298 0 0 397 39 170 97 58 5 0 106 98 2 0 0
7 497 0 14 443 0 363 183 71 11 0 341 96 4 0 0
That was the reason the batch job did not run fast as expected. Being on a Zone or another VM construct increases the need to understand virtualization and to be wakeful for side effect - ZoneAlarm!!!
Karl Reitschuster
(*) depends on zone configuration (mpstat man page) : When executing in a zone and if the pools facility is active, mpstat(1M) will only provide information for those processors which are a member of the processor set of the pool to which the zone is bound.
Email Article to FriendReferences (3)
-
Related: Solaris Containers (Zones) -
Related: Solaris Containers
-
Related: man page mpstat
Reader Comments