• Re: Wydajnosc IO

    From EFEKT PAWKI@1:0/0 to All on Tue Apr 23 17:59:42 2013
    W dniu czwartek, 8 listopada 2012 00:56:44 UTC+1 u=BFytkownik EFEKT PAWKI n= apisa=B3:
    Aloha.
    =20
    Jak by=B6cie zinterpretowali takie wyniki IOSTAT podczas intensywnego dzi=
    a=B3ania Oracla.
    =20
    Jako magazyn s=B3u=BFy macierz FC z 10 dyskami SAS 15k rpm. w RAID 10 sko=
    nfigurowanymi. Maszyna ma 32 GB ram i 24 rdzenie.
    =20
    Ma duzo wolnej pamieci i jednym rdzeniem mieli, ale odczyty i zapisy nie =
    s=B1 najlepsze (niestety dane i redo na tej samej partycji na razie s=B1):
    =20
    Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-s=
    z avgqu-sz await svctm %util
    =20


    Aloha. Temat ogarn=B1=B3em dawno temu ale tak dla potomnych, mo=BFe si=EA p= rzyda.
    Przyczyn=B1 by=B3 wy=B3=B1czony write cache na macierzy - a konkretnie to w= =B3=B1czony ale gdzie=B6 tam g=B3=EAboko w logach zauwa=BFy=B3em, =BFe jest=
    zawieszony.
    Moje macierze FC IBM'a maj=B1 po jednym kontrolerze. Domy=B6lnie jest on ta=
    k ustawiony, =BFe je=B6li nie widzi drugiego kontrolera, to mimo =BFe jest = w=B3=B1czony zawiesza cachowanie zapisu tak d=B3ugo jak drugiego nie wykryj=
    e. Jest to na tyle ukryte, =BFe IBM sam tego nie wychwyci=B3 przez miesi=B1=
    c naszej przepychanki. Wymieniali=B6my kontrolery na nowe (co od razu m=F3w= i=B3em, =BFe nie ma sensu poniewa=BF na obu si=EA tak samo zachowywa=B3o ) = cuda wianki z konfiguracj=B1 i w sumie zupe=B3nie przypadkiem w jakim=B6 lo=
    gu to wyczyta=B3em.

    Gdy ju=BF to wy=B3apa=B3em szybko znalaz=B3em poni=BFszy link: http://communities.vmware.com/thread/195838

    Teraz =B6miga jak trzeba.
    Pozdrawiam. Pawka

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: The Kofo BBS MBSE - telnet://fido1.kofobbs.ne
  • From Michal Kawecki@110:300/1.1 to All on Fri Apr 26 08:56:02 2013
    Dnia Tue, 23 Apr 2013 08:59:42 -0700 (PDT), EFEKT PAWKI napisał(a):

    W dniu czwartek, 8 listopada 2012 00:56:44 UTC+1 użytkownik EFEKT PAWKI
    napisał:
    Aloha.

    Jak byście zinterpretowali takie wyniki IOSTAT podczas intensywnego działania Oracla.

    Jako magazyn służy macierz FC z 10 dyskami SAS 15k rpm. w RAID 10 skonfigurowanymi. Maszyna ma 32 GB ram i 24 rdzenie.

    Ma duzo wolnej pamieci i jednym rdzeniem mieli, ale odczyty i zapisy nie są najlepsze (niestety dane i redo na tej samej partycji na razie są):

    Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util


    Aloha. Temat ogarnąłem dawno temu ale tak dla potomnych, może się przyda. Przyczyną był wyłączony write cache na macierzy - a konkretnie to włączony
    ale gdzieś tam głęboko w logach zauważyłem, że jest zawieszony.
    Moje macierze FC IBM'a mają po jednym kontrolerze. Domyślnie jest on tak
    ustawiony, że jeśli nie widzi drugiego kontrolera, to mimo że jest włączony zawiesza cachowanie zapisu tak długo jak drugiego nie wykryje. Jest to na tyle ukryte, że IBM sam tego nie wychwycił przez miesiąc naszej przepychanki. Wymienialiśmy kontrolery na nowe (co od razu mówiłem, że nie ma sensu ponieważ na obu się tak samo zachowywało ) cuda wianki z konfiguracją i w sumie zupełnie przypadkiem w jakimś logu to wyczytałem.

    Gdy już to wyłapałem szybko znalazłem poniższy link: http://communities.vmware.com/thread/195838

    Teraz śmiga jak trzeba.
    Pozdrawiam. Pawka

    Dzięki. Może i mnie się to przyda, bo jeden z kabelków SAS jest
    niekompatybilny i macierz pokazuje błąd na kontrolerze. I choć niby
    wszystko działa, to wydajność macierzy nie jest taka jakiej oczekiwałem.
    --
    M.
    /odpowiadając na priv zmień px na pl/

    --- MBSE BBS v0.95.15 (GNU/Linux-x86_64)
    * Origin: INTERIA.PL S.A. (110:300/1.1@linuxnet)