1. Forum
  2. Usenet
  3. COMP.UNIX.SOLARIS

  • ZFS high time utilisation for compression

    From YTC#1@21:1/5 to All on Wed Jan 15 21:58:49 2020
    Same custy as last post....

    Before I go off into researching and stat checking , I wonder if someone
    has a quick answer

    Oracle DB redo log dataset is compressed (don;t ask, DBAs changed usage
    without saying).

    log files show as 250Mb in OraDB and 100Mb on filesystem .... DBAs don;t
    like this (banging head against wall).

    Anyway,they did some copy tests.
    With compression on a log file takes 2mis 45 secs (about 1min 45 sec in
    kernel) to copy.

    With compression off, 15 secs.

    That is an excessive over head IMO.

    Server is M4000, S10. Zpool version =37.

    I'll try and get a comparable test on the new S7s tomorrow.... just
    don;t want to be wasting time on what I see as a non issue (ie :- just
    turn compression off).



    --
    Bruce Porter
    "The internet is a huge and diverse community but mainly friendly" http://ytc1.blogspot.co.uk/
    There *is* an alternative! https://www.libreoffice.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cindy.swearingen@gmail.com@21:1/5 to All on Wed Jan 22 08:05:34 2020
    On Wednesday, January 15, 2020 at 2:58:54 PM UTC-7, YTC#1 wrote:
    Same custy as last post....

    Before I go off into researching and stat checking , I wonder if someone
    has a quick answer

    Oracle DB redo log dataset is compressed (don;t ask, DBAs changed usage without saying).

    log files show as 250Mb in OraDB and 100Mb on filesystem .... DBAs don;t
    like this (banging head against wall).

    Anyway,they did some copy tests.
    With compression on a log file takes 2mis 45 secs (about 1min 45 sec in kernel) to copy.

    With compression off, 15 secs.

    That is an excessive over head IMO.

    Server is M4000, S10. Zpool version =37.

    I'll try and get a comparable test on the new S7s tomorrow.... just
    don;t want to be wasting time on what I see as a non issue (ie :- just
    turn compression off).



    --
    Bruce Porter
    "The internet is a huge and diverse community but mainly friendly" http://ytc1.blogspot.co.uk/
    There *is* an alternative! https://www.libreoffice.org/

    Hi Bruce,

    Which ZFS compression is this? According to our recommendations, the only compression recommended for Oracle DB workloads is for the archive.

    https://www.oracle.com/technetwork/server-storage/solaris10/config-solaris-zfs-wp-167894.pdf

    Thanks, Cindy

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From YTC#1@21:1/5 to cindy.swearingen@gmail.com on Wed Jan 22 16:20:34 2020
    On 22/01/2020 16:05, cindy.swearingen@gmail.com wrote:
    On Wednesday, January 15, 2020 at 2:58:54 PM UTC-7, YTC#1 wrote:
    Same custy as last post....

    Before I go off into researching and stat checking , I wonder if someone
    has a quick answer

    Oracle DB redo log dataset is compressed (don;t ask, DBAs changed usage
    without saying).

    log files show as 250Mb in OraDB and 100Mb on filesystem .... DBAs don;t
    like this (banging head against wall).

    Anyway,they did some copy tests.
    With compression on a log file takes 2mis 45 secs (about 1min 45 sec in
    kernel) to copy.

    With compression off, 15 secs.

    That is an excessive over head IMO.

    Server is M4000, S10. Zpool version =37.

    I'll try and get a comparable test on the new S7s tomorrow.... just
    don;t want to be wasting time on what I see as a non issue (ie :- just
    turn compression off).


    Hi Bruce,

    Which ZFS compression is this? According to our recommendations, the only compression recommended for Oracle DB workloads is for the archive.

    https://www.oracle.com/technetwork/server-storage/solaris10/config-solaris-zfs-wp-167894.pdf

    It is the lzjb (not had a chance to do a comparison on S7 yet).

    And, yes we did point out to the DBAs that if they change usage from
    archive log to redo log that is a good idea to let people know :-)


    Compression is now off and times have improved.

    My only curiosity now is
    * What happens when ZFS writes to a section previously compressed file
    (ie the redo log) , does it still compress until the file is moved ?




    --
    Bruce Porter
    "The internet is a huge and diverse community but mainly friendly" http://ytc1.blogspot.co.uk/
    There *is* an alternative! https://www.libreoffice.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From cindy.swearingen@gmail.com@21:1/5 to All on Wed Jan 22 09:12:50 2020
    On Wednesday, January 15, 2020 at 2:58:54 PM UTC-7, YTC#1 wrote:
    Same custy as last post....

    Before I go off into researching and stat checking , I wonder if someone
    has a quick answer

    Oracle DB redo log dataset is compressed (don;t ask, DBAs changed usage without saying).

    log files show as 250Mb in OraDB and 100Mb on filesystem .... DBAs don;t
    like this (banging head against wall).

    Anyway,they did some copy tests.
    With compression on a log file takes 2mis 45 secs (about 1min 45 sec in kernel) to copy.

    With compression off, 15 secs.

    That is an excessive over head IMO.

    Server is M4000, S10. Zpool version =37.

    I'll try and get a comparable test on the new S7s tomorrow.... just
    don;t want to be wasting time on what I see as a non issue (ie :- just
    turn compression off).



    --
    Bruce Porter
    "The internet is a huge and diverse community but mainly friendly" http://ytc1.blogspot.co.uk/
    There *is* an alternative! https://www.libreoffice.org/

    ZFS compresses blocks. After compression is disabled, then its possible that the redo log will contain both compressed and uncompressed blocks until its rotated completely.

    Thanks, Cindy

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From YTC#1@21:1/5 to cindy.swearingen@gmail.com on Wed Jan 22 22:33:12 2020
    On 22/01/2020 17:12, cindy.swearingen@gmail.com wrote:
    On Wednesday, January 15, 2020 at 2:58:54 PM UTC-7, YTC#1 wrote:
    Same custy as last post....

    Before I go off into researching and stat checking , I wonder if someone
    has a quick answer

    Oracle DB redo log dataset is compressed (don;t ask, DBAs changed usage
    without saying).

    log files show as 250Mb in OraDB and 100Mb on filesystem .... DBAs don;t
    like this (banging head against wall).

    Anyway,they did some copy tests.
    With compression on a log file takes 2mis 45 secs (about 1min 45 sec in
    kernel) to copy.

    With compression off, 15 secs.

    That is an excessive over head IMO.

    Server is M4000, S10. Zpool version =37.

    I'll try and get a comparable test on the new S7s tomorrow.... just
    don;t want to be wasting time on what I see as a non issue (ie :- just
    turn compression off).


    ZFS compresses blocks. After compression is disabled, then its possible that the redo log will contain both compressed and uncompressed blocks until its rotated completely.



    Ta, I suspected something like that, just could not find the info.



    --
    Bruce Porter
    "The internet is a huge and diverse community but mainly friendly" http://ytc1.blogspot.co.uk/
    There *is* an alternative! https://www.libreoffice.org/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)