2

i have a setup here where we use a Solaris 10 x86, zpool for oracle12c-redo-log using mirrored disks and mirrored ZIL. logbias="latency", recordsize=128:

pool: xxxxxx01_redo00 state: ONLINE scan: resilvered 25.1G in 0h1m with 0 errors on Thu Jan 22 15:24:41 2015 config:

    NAME                                       STATE     READ WRITE CKSUM
    xxxxxx01_redo00                            ONLINE       0     0     0
      mirror-0                                 ONLINE       0     0     0
        c5t60000970000295700789533031393742d0  ONLINE       0     0     0
        c5t60000970000295700860533033424537d0  ONLINE       0     0     0
    logs
      mirror-1                                 ONLINE       0     0     0
        c5t60000970000295700789533032304344d0  ONLINE       0     0     0
        c5t60000970000295700860533033423844d0  ONLINE       0     0     0

When i now check what the lgwr process does in terms of IO it is after all mostly writes to the redo-logs (when not switching logs).

Here is what i do not get: The lgwr-process does writes in different sizes (which is okay) and i expect to see them actually happening on the ZIL-Devices until the txg_timeout is getting hit, then i expect to see the flush to the data-disks. Instead the picture is different.

Here is the iostat:

0.0  133.3    0.0 4067.1  0.0  0.1    0.0    0.5   0   7 c5t60000970000295700789533032304344d0
0.0  133.8    0.0 4077.1  0.0  0.3    0.0    2.2   0  29 c5t60000970000295700860533033423844d0
44.6    0.0 5708.7    0.0  0.0  0.1    0.0    2.0   0   9 c5t60000970000295700789533031393742d0
33.6    0.0 4297.6    0.0  0.0  0.1    0.0    3.3   0  11 c5t60000970000295700860533033424537d0

as you can see, the first two disks are the ZILs, the other two are the actual disks with the Data.

checking the lgwr from syscall-level with:

./rwsnoop -p <PID>
 UID    PID CMD          D   BYTES FILE
708  16559 oracle       W     512 /export/zones/xxxxxx01/root/opt/app/oracle/redo00/XXXX0/XXXX0_redo07.rdo
708  16559 oracle       W   58368 /export/zones/xxxxxx01/root/opt/app/oracle/redo00/XXXX0/XXXX0_redo07.rdo
708  16559 oracle       W    2560 /export/zones/xxxxxx01/root/opt/app/oracle/redo00/XXXX0/XXXX0_redo07.rdo
708  16559 oracle       W   26112 /export/zones/xxxxxx01/root/opt/app/oracle/redo00/XXXX0/XXXX0_redo07.rdo
708  16559 oracle       W   69632 /export/zones/xxxxxx01/root/opt/app/oracle/redo00/XXXX0/XXXX0_redo07.rdo

here we can see that the lgwr-process does its io with different blocksizes.

now from a devices-pov (of the Data-Devices not the ZIL)

./iosnoop -d <sd-dev>
UID   PID D    BLOCK   SIZE       COMM PATHNAME
708 16559 R 29073760 131072     oracle <none>
708 16559 R 29074016 131072     oracle <none>
708 16559 R 29073504 131072     oracle <none>
708 16559 R 29073760 131072     oracle <none>
708 16559 R 29073504 131072     oracle <none>
708 16559 R 29073760 131072     oracle <none>
708 16559 R 29074784 131072     oracle <none>
708 16559 R 29074784 131072     oracle <none>
708 16559 R 29074784 131072     oracle <none>
708 16559 R 29074272 131072     oracle <none>
708 16559 R 29074272 131072     oracle <none>

this seem to be clearly zfs 128k reads but why so they happen? is it just because the recordsize=128 and zfs collecting the writes and because of the c-o-w it needs to read?

I would appreciate to dig deeper with you all or just be enlightened ;-)

Cheers B.

migrated from stackoverflow.com Mar 19 '15 at 12:24

This question came from our site for professional and enthusiast programmers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.