Oct
30
Written by:
Bert
Thursday, October 30, 2008 6:25 AM
A few weeks ago I wrote about how simply adjusting various virtualized infrastructure default settings that a database could perform up to
440% better. Of course “
your mileage” will vary, but the key point is that taking the time to properly layer your virtual infrastructure settings can have substantial impacts – which are only magnified by the net or cumulative effect of a virtual server hosting multiple database servers. And while my example was specific to Oracle, the same principles generally apply for any database being deployed on a virtual server.
I presented this information since there are still many who question deploying database servers on virtualized platforms. My key contention is that as long as there are sufficient resources and/or bandwidth to handle the net requests, that requiring database servers to be islands onto themselves is now passé’. Even if we say that there is a 10-20% overhead (which I’m inclined to say is closer to ten than twenty), with cheap hardware these days the benefits just far outweigh the negatives – just spend 10% more and get a bigger server to handle multiple databases. But it may be a few years before that opinion is generally or more widely accepted.
This week I’m going to elaborate on just one of the techniques I used to get such stellar results. If you refer back to the
first blog, I’m going to explain choice #10. As a reminder:
- #10 = Adjust VM client file system block size to more closely match Oracle block size
The default block size for both the host and client OS file systems’ is generally not the same as your Oracle block size (although hopefully the Oracle block size is a multiple of the OS file block size). Since the host may be servicing multiple Oracle databases with different block sizes, different database platforms (e.g. MySQL), or being used as to host other applications (e.g. web server) – we cannot always make this adjustment at the host level. But generally we can make it for each of the Oracle database clients.
Let’s assume we have a Linux host running a Linux based Oracle database client. Let’s assume that we create the host file system using the default block size: 2K. Let’s further assume that we do the same thing on the client – but that we size the database blocks at 4K. Thus each Oracle physical IO requests asks the client OS for two IO’s, and the client asks the host for two IO’s. That’s a total of four IO requests (although only two physical IO’s in reality – but there is overhead for each request, so larger numbers are worse). Now if the client had instead created its file system at 4K, then the IO numbers would instead be client = 1 and host = 2 for a total of 3 (which is obviously less than 4). Here’s a chart to show some common combinations and their sometimes surprising overheads:
|
Host OS block size
|
2
|
2
|
2
|
2
|
2
|
2
|
2
|
2
|
4
|
4
|
4
|
4
|
4
|
4
|
4
|
4
|
|
Client OS block size
|
2
|
2
|
2
|
2
|
4
|
4
|
4
|
4
|
2
|
2
|
2
|
2
|
4
|
4
|
4
|
4
|
|
DB block size
|
2
|
4
|
8
|
16
|
2
|
4
|
8
|
16
|
2
|
4
|
8
|
16
|
2
|
4
|
8
|
16
|
|
Total IO requests
|
4
|
7
|
13
|
25
|
5
|
7
|
12
|
22
|
4
|
7
|
13
|
25
|
4
|
6
|
11
|
21
|
Obviously there are some very bad choices in the chart above. So a seemingly good 16K database block size might actually result in total 25 IO requests across the virtualization infrastructure. While it’s still effectively just 16K being read, the extra overheads added by this mismatch only serve to multiply the bad effects. So choose wisely.
1 comment(s) so far...
Re: Oracle + VMware = Success Part III
I forgot to mention - that the Oracle multi block read count init.ora parameter can exasperate this even further. In Oracle prior to 11g, the default was 16 - which might cause some problems. In Oracle 11g, the default is now 128! So if you've got a couple Oracle 11g databases hosted on the same VMware host and using the defaults, the numbers above would be even worse :(
By bscalzo on
Friday, October 31, 2008 6:07 AM
|