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.

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.