Re: slow rman compression on exadata x8-m to zfs

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Tue, 7 Dec 2021 11:27:38 -0500
Message-ID: <27a2b9b1-5351-cd99-8966-e2adec5b2afe_at_gmail.com>


On 12/7/21 11:07, Michael McMullen wrote:
basic compression for all systems

From: oracle-l-bounce_at_freelists.org <oracle-l-bounce_at_freelists.org> on behalf of Michael McMullen <ganstadba_at_hotmail.com>
Sent: December 7, 2021 9:57 AM
To: oracle-l_at_freelists.org <oracle-l_at_freelists.org>
Subject: slow rman compression on exadata x8-m to zfs
 

exadata x8-m high capacity  - new
exadata x5-2,x6-2 - old
zfs storage
big file tablespaces
24 channels 128G section size
configure device type disk parallelism 24 backup type to backupset;

We're migrating, 11.2,12.2,18c databases from various exadata's to a new x8-m system.
Db's are going from rac db's to container rac db's.

All the exadatas are using the same zfs for backups and backup scripts are the same.

We noticed the backups are reading at 500Mb/sec to the zfs on the new exadata. Previously they would read at 8-10Gb/sec on the older exadatas while using rman compression. They were all writing to the same zfs, so a mix of ib/roce/public infterfaces depending on the exadata.

If I remove compression on the rman backups on the new system then I get 8-10Gb/sec.

Everything seems to be ok at the network level, MTU etc.

I think I've narrowed it down to just the compression. CPU's are at 100% for the rman processes with compression and ~50% without. I'm not seeing that on the other exadatas.

Any ideas?

Thanks
Mike



Hi Mike,

I don't undestand, where does the network fit into this picture? Are you doing rman target /? If you are, network shouldn't play any role. Anyway, if the compression on the rman side is slow and your target is ZFS appliance, you can set ZFS compression. On Slowaris, I used to do zfs set compression=lz4 <pool name>. ZFS appliance must have the corresponding configuration option for the exported mount point. That would still save you space, but would move the compression CPU usage from the expensive DB server to the cheapo NAS. You can use different compression algorithms, but LZ4 looks the bast with regard to CPU expenditure.

Regards

-- 
Mladen Gogala
Database Consultant
Tel: (347) 321-1217
https://dbwhisperer.wordpress.com
-- http://www.freelists.org/webpage/oracle-l Received on Tue Dec 07 2021 - 17:27:38 CET

Original text of this message