Re: exadata write performance problems

  • From: Patrick Jolliffe <jolliffe@xxxxxxxxx>
  • To: Mladen Gogala <gogala.mladen@xxxxxxxxx>
  • Date: Sat, 16 Feb 2019 10:35:58 +0800

You seem to be referring to prioritisation at compute node process layer
whereas iorm is really handling prioritisation inside the storage cells.
Can only repeat that we had significant issues with default setting under
load, instantly fixed by moving iorm to recommended settings
Patrick

On Sat, 16 Feb 2019, 09:50 Mladen Gogala <gogala.mladen@xxxxxxxxx wrote:

Hi Patrick,

Of course that they will prioritize DBWR/LGWR over everything else,
those processes are essential for the functioning of the database. Kerry
Osborne even has a blog post which tells you how to do that:


http://kerryosborne.oracle-guy.com/2010/03/increasing-priority-of-lgwr-process-using-_high_priority_processes/

You can do the same thing on linux, using ionice, but only if you are
using CFQ scheduler, which is not what Oracle recommends. Oracle
recommends "Deadline" scheduler for rotational disks and "noop" for SSD's.

Also, as I have previously said, Exadata is a DW machine, not really
optimized for OLTP processing. Waiting on log file sync and parallel
control file write means that the underlying database is using a lot of
concurrent I/O, which is not what Exadata is made for. Exadata is a DW
machine, just like Greenplum and Netezza.

What you really need when it comes to fast writing is a storage that can
write really fast. These days, the best results are achieved by using
all flash storage. Every major vendor has an all-flash model. If you
want to drive really, really fast, you will not use F-150. If you want
to transport a ton of wooden planks from Home Depot to your home, you
will not use a Ferrari. It's as simple as that.

Regards



On 2/15/19 7:05 PM, Patrick Jolliffe wrote:
I'd look seriously to change that, we've had a few problems with
default setting (BASIC) when hitting high IO load, and it has
significantly improved by implementing the recommended setting
(AUTO).  This seems to prioritise critical database writes
(DBWR/LGWR/???) over others.
I still don't know why they haven't changed this default if it's not
the recommended value.
Starting point would be reading section 6.5.1 of following URL

https://docs.oracle.com/en/engineered-systems/exadata-database-machine/sagug/exadata-storage-server-iorm.html
Patrick

--
Mladen Gogala
Database Consultant
Tel: (347) 321-1217

--
//www.freelists.org/webpage/oracle-l



Other related posts: