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.
>
> 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
>
>
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-lReceived on Wed Jan 30 2013 - 01:17:09 CET