Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

2x RAID10 SAS + SSD + PostgreSQL, prośba o opinie

ZefirMefisto 29 Lip 2014 09:18 1188 10
  • #1 29 Lip 2014 09:18
    ZefirMefisto
    Poziom 2  

    Zacznę od przedstawienia aktualnej sytuacji:

    - aktualnie posiadamy 4 dyski SAS 15k złożone w RAID10
    - na dyskach znajduje się baza danych, która do małych już nie należy: ok 300GB
    - na serwerze nie ma innych usług z wyjątkiem PostgreSQL
    - ogromna ilość ilość operacji i duża ilość zmieniających się danych sprawia, że dyski nie nadążają z ciągłym zapisem i odczytem, efektem jest zwiększony load i iowait'y
    - używana aplikacja, zapytania, indeksy, tabele są na okrągło optymalizowane lub poprawiane, ale zaczyna to już nie wystarczać
    - z osiągów w tym momencie na macierzy: test zapisu sekwencyjnego 25-50MB/s, odczyt ok 50-75MB/s (tragic!)

    Pomysł usprawnienia całości polega na zastąpieniu aktualnej macierzy RAID10 zbudowanej na dyskach SAS przez macierz RAID10 na dyskach SSD, co na pewno poprawi sytuacje. Dodatkowo chcemy na starej macierzy postawić kopie bazy replikowaną strumieniowo przez WAL jako baza tylko do odczytu wspomagająca aplikacje. Problemem jest tutaj możliwość wpięcia maksymalnie 8 dysków, więc na jednej macierzy musiałby się znaleźć również system.

    Proszę o opinie czy taka konfiguracja/pomysł ma sens czy może jest to trochę przerost formy nad treścią?

    0 10
  • #2 29 Lip 2014 09:34
    PDT
    Poziom 24  

    ZefirMefisto napisał:
    - ogromna ilość ilość operacji i duża ilość zmieniających się danych sprawia, że dyski nie nadążają z ciągłym zapisem i odczytem, efektem jest zwiększony load i iowait'y


    A PostgreSQL ma mechanizmy do analizy zapytań. Co znaczy określenie "ogromna ilość", jak takie typowe zapytanie "wycenia" profiler?

    ZefirMefisto napisał:
    Pomysł usprawnienia całości polega na zastąpieniu aktualnej macierzy RAID10 zbudowanej na dyskach SAS przez macierz RAID10 na dyskach SSD, co na pewno poprawi sytuacje.


    Baza danych na dyskach SSD to gwarantowana porażka.

    PS. Pamięć FLASH z której zbudowano dyski SSD ma zbyt ograniczoną liczbę zapisów. Żaden TRIM przy bazie danych nie pomoże.

    0
  • #3 29 Lip 2014 09:39
    ylk
    Poziom 2  

    PDT napisał:
    Pamięć FLASH z której zbudowano dyski SSD ma zbyt ograniczoną liczbę zapisów. Żaden TRIM przy bazie danych nie pomoże.

    Obstawiam, że zanim to się stanie, dyski będą już dawno przerobione na żyletki :)

    0
  • #4 29 Lip 2014 09:57
    PDT
    Poziom 24  

    ylk napisał:
    Czy można prosić o rozwinięcie tematu?


    A serwer i system operacyjny to jaki jest? Ma on przynajmniej 8GB RAM i Xeona?
    Czy to Linux? 64-bitowy? Dostrojony do tego zastosowania?

    Pzdr

    PS. Z tymi żyletkami po kilku tygodniach działania to bym nie przesadzał.

    0
  • #5 29 Lip 2014 10:00
    ZefirMefisto
    Poziom 2  

    PDT napisał:
    ZefirMefisto napisał:
    - ogromna ilość ilość operacji i duża ilość zmieniających się danych sprawia, że dyski nie nadążają z ciągłym zapisem i odczytem, efektem jest zwiększony load i iowait'y


    A PostgreSQL ma mechanizmy do analizy zapytań. Co znaczy określenie "ogromna ilość", jak takie typowe zapytanie "wycenia" profiler?.


    Typowego kosztu zapytań nie sposób znaleźć, ich różnorodność na to nie pozwala, ale proszę z slowlogu wycena ostatnich trzech:
    - Hash Left Join (cost=810.19..565241.11 rows=2000 width=1507) (actual time=3200.296..13861.432 rows=2000 loops=1)
    - Limit (cost=19482.56..36295.55 rows=1000 width=645) (actual time=1499.975..1499.975 rows=1000 loops=1)
    - Nested Loop Anti Join (cost=36.61..150858.86 rows=1 width=169) (actual time=1.676..1.676 rows=1 loops=1)

    0
  • #6 29 Lip 2014 10:03
    ylk
    Poziom 2  

    Debian 7 64bit, ma Xeona 16 rdzeni, 24GB RAM. Dostrojony - cóż, w jakimś stopniu na pewno, ale być może jest jeszcze dużo do zrobienia, tylko trzeba o tym wiedzieć.

    0
  • #7 29 Lip 2014 10:04
    ZefirMefisto
    Poziom 2  

    Dodam jeszcze, że wąskim gardłem jest tu dysk, to akurat jest pewne i stąd pomysł z dyskami SSD

    0
  • #8 29 Lip 2014 10:42
    PDT
    Poziom 24  

    Proponuję jednak skoncentrować się nad bazą danych.
    Nie to żeby cokolwiek w niej mieszać, ale co nam szkodzi przynajmniej sprawdzić czy tam gdzie są złączenia (zwłaszcza te kosztowne), istnieją odpowiednie klucze obce. Jak taki dedykowany klucz dodamy, to porównamy wydajności zapytań.
    Z praktyki wiem, że projektanci baz danych często zaniedbują takie optymalizacje. W końcu jak testują produkt to mają w nim szebanaście rekordów i wszystko 'śmiga'.

    Pzdr

    PS. Ale to już raczej tematyka na inny dział.

    0
  • #9 29 Lip 2014 11:00
    ZefirMefisto
    Poziom 2  

    Optymalizacja bazy jest robiona, jak sądzę przez ludzi, którzy mają trochę o tym pojęcia :) i to faktycznie na inny dział.

    Mamy zamiar zrobić teraz optymalizacje Hardware i poprawić trochę najwęższe gardło w całym systemie. Ponieważ nie mamy doświadczenia w tej kwestii, stąd ten topic. Jeśli nie SSD to może jakaś inna konfiguracja?

    0
  • #10 29 Lip 2014 11:42
    PDT
    Poziom 24  

    Przeczytałem jeszcze raz #1 post, masz rację co do konieczności usprawnienia 'hardware':

    ZefirMefisto napisał:
    test zapisu sekwencyjnego 25-50MB/s, odczyt ok 50-75MB/s (tragic!)

    Porównawczo zamieszczam wynik z mojego 'budżetowego' lapka:
    Kod: bash
    Zaloguj się, aby zobaczyć kod

    A ten serwer w 'hdparm -t' ile wykazuje? Też 75MB/s? (nie wiem czym było mierzone)

    0
  • #11 29 Lip 2014 11:57
    ylk
    Poziom 2  

    Tak, hdparmem właśnie, wyniki są różne w zależności od stopnia wykorzystania bazy. Przykładowo wyniki 2ch uruchomień

    Code:

    [root@newmaster /media]# hdparm -tT /dev/sdc

    /dev/sdc:
     Timing cached reads:   14658 MB in  2.00 seconds = 7337.54 MB/sec
     Timing buffered disk reads: 376 MB in  3.03 seconds = 124.03 MB/sec
    [root@newmaster /media]# hdparm -tT /dev/sdc

    /dev/sdc:
     Timing cached reads:   15134 MB in  2.00 seconds = 7575.95 MB/sec
     Timing buffered disk reads: 280 MB in  3.03 seconds =  92.35 MB/sec

    0