Jaki jest najlepszy system plików dla wydajności wstawiania w PostgreSQL?

Jestem ciekawy, czy ktokolwiek tam przeprowadził eksperymenty lub porównania między systemami plików a wydajnością bazy danych. W systemie Linux zastanawiam się, jaki jest optymalny system plików dla bazy danych Postgres. Jakie ustawienia (i-węzeł itp.) Są do tego idealne? Czy jest to coś, co może drastycznie różnić się w zależności od danych w bazie danych?

Jeśli szukasz pytania dotyczącego ogólnej wydajności systemu plików / bazy danych, ten post zawiera kilka dobrych informacji.

Chciałbym jednak uzyskać jak najwięcej porad dotyczących wydajności wstawiania, a nie wydajności odczytu. Dzięki za wszystkie wspaniałe odpowiedzi!

Kup kopię „postgresql high performance” Grega Smitha. To świetna książka, a dwa lub więcej rozdziałów dotyczą sprzętu dyskowego i systemów plików. Dowiesz się dużo.

W skrócie: nie ma krótkiej odpowiedzi.

Ale postaram się lato:

• nie używaj ext2, dopóki nie dowiesz się, co robisz.
• z ext3 strzeż się skoków punktu kontrolnego z powodu wywołań fsync, patrz strony 113 oraz 82 i 79
• użyj ext4 lub xfs
• są inne opcje

Ale ponieważ naprawdę zastanawiasz się, jakiego FS użyć, powinieneś przeczytać książkę!

Po pierwsze, potrzebujesz najpierw niezawodnego systemu plików i szybkiej sekundy. Które wykluczają niektóre opcje ...

Testy wydajności pokazują, że często XFS zapewnia najlepszą wydajność. Istnieją pewne problemy ze stabilnością, gdy osiągniesz scenariusz z dyskiem bardzo zbliżonym do pełnego, ale dopóki monitorujesz, że tak się nie dzieje, da ci to nieco lepszą wydajność.

Teoretycznie nie potrzebujesz systemu plików kronikowania dla katalogu pg_xlog, ale różnica prędkości jest zwykle tak mała, że ​​po prostu nie jest tego warta. W przypadku katalogu danych naprawdę powinieneś zawsze mieć system plików kronikowania metadanych.

Systemy zarządzania bazami danych wdrażają własne dzienniki za pomocą dzienników bazy danych, więc zainstalowanie takiego DBMS w dziennikowanym systemie plików obniża wydajność dzięki dwóm mechanizmom:

1. Nadmiarowe dzienniki zwiększają aktywność dysku

2. Fizyczny układ dysku może być pofragmentowany (chociaż niektóre systemy plików do dziennika mają mechanizmy do czyszczenia tego).

3. Duża aktywność dysku może wypełnić dziennik, powodując fałszywe warunki „zapełnienia dysku”.

Kilka lat temu widziałem taki przypadek w systemie plików LFS w instalacji Baan na urządzeniu HP / UX. W systemie występowały trwałe problemy z wydajnością i uszkodzeniem danych, które nie zostały zdiagnozowane, dopóki ktoś nie zorientował się, że systemy plików zostały sformatowane przy użyciu LFS.

Woluminy przechowujące pliki bazy danych zwykle zawierają niewielką liczbę dużych plików. Serwery DBMS zwykle mają ustawienie, które konfiguruje, ile bloków jest odczytywanych w pojedynczym We / Wy. Mniejsze liczby byłyby odpowiednie dla systemów przetwarzania transakcji o dużej ilości, ponieważ zminimalizowałyby buforowanie zbędnych danych. Większe liczby byłyby odpowiednie dla systemów takich jak hurtownie danych, które wykonały wiele odczytów sekwencyjnych. Jeśli to możliwe, dostrój rozmiar bloku alokacji systemu plików, aby był taki sam, jak odczyt wielu bloków ustawiony na DBMS.

Niektóre systemy zarządzania bazami danych mogą działać na surowych partycjach dysku. Daje to różny stopień przyrostu wydajności, zwykle mniej niż w nowoczesnym systemie z dużą ilością pamięci. W starszych systemach z mniejszą ilością miejsca na buforowanie metadanych systemu plików oszczędności na dyskowych operacjach wejścia / wyjścia były dość znaczne. Surowe partycje utrudniają zarządzanie systemem, ale zapewniają najlepszą dostępną wydajność.

Woluminy RAID-5 wiążą się z większym obciążeniem zapisu niż woluminy RAID-10, więc zajęta baza danych z dużym ruchem zapisu będzie działać lepiej (często znacznie lepiej) na macierzy RAID-10. Dzienniki powinny być fizycznie oddzielne woluminy dyskowe do danych. Jeśli Twoja baza danych jest duża i w większości przeznaczona tylko do odczytu (np. Hurtownia danych), może zaistnieć potrzeba umieszczenia jej na woluminach RAID-5, jeśli nie spowoduje to nadmiernego spowolnienia procesu ładowania.

Buforowanie z zapisem w kontrolerze może zapewnić wzrost wydajności kosztem stworzenia niektórych (względnie mało prawdopodobnych, ale możliwych) trybów awarii, w których dane mogą zostać uszkodzone. Największą wygraną w tym zakresie są wysoce losowe obciążenia dostępu. Jeśli chcesz to zrobić, rozważ umieszczenie dzienników na osobnym kontrolerze i wyłączenie buforowania z zapisem w woluminach dziennika. Dzienniki będą wówczas miały lepszą integralność danych, a pojedyncza awaria nie będzie mogła wyjąć zarówno woluminów dziennika, jak i danych. Umożliwia to przywracanie z kopii zapasowej i przechodzenie do przodu z dzienników.

Zrobiłem tak szczegółowy raport, ale tylko w języku francuskim . Jeśli czytasz francuski lub jesteś zadowolony z automatycznych narzędzi do tłumaczenia ... Możesz ponownie użyć metodologii i uruchomić ją dla siebie.

Streszczenie: Użyłem pgbench. Program planujący wejścia / wyjścia systemu Linux ma bardzo małe znaczenie dla wydajności, a system plików tylko trochę. Jeśli więc Ci się spieszy, wybierz domyślną. Wybrałem JFS.

System plików to tylko część problemu. Możesz uzyskać znaczny wzrost wydajności, zmieniając harmonogram we / wy. Na szczęście jest to dość łatwe do przetestowania, ponieważ można zmienić harmonogram we / wy na bieżąco. Sugeruję wypróbowanie każdego z nich przez kilka dni pod typowym obciążeniem i sprawdzenie, która daje najlepszą wydajność.

Kilka miesięcy temu przeprowadziłem kilka testów:

Miałem mały program testowy, który utworzył 50 wątków, w których każdy wątek wstawił 1000 (lub jeśli było to 10000) wierszy do tej samej tabeli.

• Z bazą danych EXT3 i 4-dyskowym RAID5 zajęło to 50 sekund.
• Przy stole na ramdysku (przy użyciu obszaru tabel) zajęło to jeszcze 50 sekund. Powodem, dla którego nie było to szybsze, jest to, że wszystko jest rejestrowane w katalogu pg_xlog, który wciąż znajduje się w tym samym RAID 5.
• Przeniosłem pg_xlog na 4-dyskowy RAID0 (pasek) i ten sam program uruchomiłem w 40 sekund.
• Do celów testowych przeniosłem pg_xlog na ramdysk i miałem wszystko inne na RAID dysku EXT3 4. Program został zakończony po mniej niż 5 sekundach.

Ale posiadanie pg___xlog na ramdysku oprogramowania nie jest opcją: jeśli stracisz zawartość katalogu pg_xlog, postgres nie uruchomi się. (Ale istnieją ramdyski sprzętowe z podtrzymaniem bateryjnym, które mogą być interesujące.)

IMHO: Użyj systemu plików, który najbardziej ci odpowiada, do plików bazy danych. Przenieś pg_xlog (z dowiązaniem symbolicznym, patrz dokumentacja) na najszybsze możliwe urządzenie.

Widziałem, że pamiętałem, że ulepszony FreeBSD da ci nieco większą wydajność w porównaniu do innych systemów operacyjnych. Chociaż jestem pewien, że ta informacja jest nieaktualna i prawdopodobnie przede wszystkim mitem. Jednak możesz to wypróbować, zapoznaj się z wytycznymi dotyczącymi ustawień jądra: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html