Re: new database server build - sanity check

From: Mark Burgess <mark_at_burgess-consulting.com.au>
Date: Wed, 30 Jan 2013 11:17:09 +1100
Message-Id: <92B0B603-9286-4DDC-92D7-9C20513530B0_at_burgess-consulting.com.au>



Yes it is ZFS writes causing the higher kernal CPU - however - I suspect it might be a certain combination of events that cause it to happen. I have noticed that this problem appears when we are writing to the dataset that has a mismatch between the IO size and the recordsize property - in particular when there has previously been a large number of files removed that have been written with recordsize A and then we are writing back to the dataset with recordsize B. There is most likely a valid reason for this given that one of the common ZFS optimisation recommendations is to set the recordsize property to match the db_block_size value etc. I also suspect that we amplify the problem by writing our RMAN backup (non-compressed) to the FRA sitting on the pool before pushing it off to an external server. The backup can generate far more IO than the normal database workload that these servers support. I am looking to implement the _backup_disk_bufsz settings documented in Metalink  note # 1072545.1 to see if this helps when writing the RMAN backups.

I need to do further testing of this - so far these are just observations but I don't have any fact as yet to back it up.

Regards,

Mark

> Mark writes:
>

>> - ZFS can push the kernel CPU utilisation up when writing - during periods
>> of intense writing..ie..RMAN backup..we can see the kernel CPU utilisation
>> going up to 40% so you need to allow for this additional overhead.

>
> Are you sure the extra CPU is due to ZFS overhead? We have the same on AIX
> and JFS2. I reasoned that it was just the RMAN compression, which should be
> CPU intensive.
>
> Rich
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
--
http://www.freelists.org/webpage/oracle-l
Received on Wed Jan 30 2013 - 01:17:09 CET

Original text of this message