Page 1


Idź do • Spis treści • Przykładowy rozdział • Skorowidz Katalog książek • Katalog online • Zamów drukowany katalog Twój koszyk • Dodaj do koszyka Cennik i informacje • Zamów informacje o nowościach • Zamów cennik Czytelnia • Fragmenty książek online

Kontakt Helion SA ul. Kościuszki 1c 44-100 Gliwice tel. 32 230 98 63 e-mail: helion@helion.pl © Helion 1991–2011

Wysoko wydajny PostgreSQL 9.0 Autor: Gregory Smith Tłumaczenie: Robert Górczyński ISBN: 978-83-246-3062-2 Tytuł oryginału: PostgreSQL 9.0 High Performance Format: 170×230, stron: 464

Poznaj najlepsze techniki zwiększania wydajności PostgreSQL i sprawdzone rozwiązania najczęściej spotykanych problemów! • Jak dobierać komponenty serwera, aby maksymalnie wykorzystać jego możliwości? • Jak przeprowadzać testy wydajności całego systemu, od sprzętu po aplikację? • Jak skutecznie indeksować bazę danych i optymalizować zapytania? Mający za sobą już ponad piętnaście lat rozwoju PostgreSQL jest dziś potężnym systemem baz danych typu open source, o sprawdzonej architekturze i reputacji narzędzia niezawodnego oraz nieprzeciętnie wydajnego. Współdziała on ze wszystkimi popularnymi systemami operacyjnymi i jest w pełni zgodny z warunkami ACID. Te zalety sprawiają, że można go używać jako magazynu danych dla aplikacji oraz jako bazy danych dla aplikacji sieciowych. Jednak osiągnięcie maksymalnej wydajności PostgreSQL nie jest wcale zadaniem łatwym, a w trakcie korzystania z jego serwerów można napotkać powtarzające się trudności, zwłaszcza gdy wzrasta obciążenie serwera, a wymagania stają się coraz większe. Jeśli zatem nie chcesz tygodniami dochodzić do właściwych rozwiązań swoich problemów – oto książka, w której znajdziesz całą potrzebną Ci wiedzę. Masz w rękach kompletny podręcznik, przeznaczony dla średnio i bardzo zaawansowanych administratorów baz danych, którzy już używają PostgreSQL lub dopiero zamierzają to zrobić. Najpierw zapoznasz się z najnowszymi wersjami tej platformy oraz dowiesz się, jak dobierać komponenty serwera, aby optymalnie wykorzystać możliwości systemu. Dzięki tej książce: • Poznasz najlepsze praktyki pozwalające na obsłużenie wymagających aplikacji • Odkryjesz, dlaczego sprzęt komputerowy nadaje się (lub nie) dla wysoko wydajnych aplikacji bazodanowych • Zrozumiesz, na czym polegają kompromisy związane z szybkością i niezawodnością działania • Zoptymalizujesz system operacyjny, aby osiągnąć najlepszą wydajność bazy danych • Przeprowadzisz testy wydajności całego systemu, od sprzętu komputerowego po aplikację • Przeanalizujesz rzeczywiste przykłady, co pozwoli Ci poznać wpływ różnych ustawień parametrów serwera na wydajność • Będziesz skutecznie monitorować zdarzenia zachodzące na serwerze, zarówno w bazie danych, jak i poza nią • Znajdziesz najlepsze dodatki, rozszerzające podstawowe możliwości bazy danych PostgreSQL • Dowiesz się, jak przygotować replikację systemów za pomocą najnowszych funkcji wprowadzonych w PostgreSQL 9.0 Zoptymalizuj swój serwer PostgreSQL i unikaj problemów, które mogą zmniejszyć jego wydajność!


Spis treci O autorze

13

O recenzentach

15

Wprowadzenie

17

Rozdzia 1. Wersje PostgreSQL

21

Wydajno we wczeniejszych wydaniach PostgreSQL Wybór odpowiedniej wersji Uaktualnienie do nowszej gównej wersji PostgreSQL czy inna baza danych? Narzdzia PostgreSQL Moduy contrib w PostgreSQL pgFoundry Dodatkowe oprogramowanie zwizane z PostgreSQL Cykl yciowy aplikacji PostgreSQL Optymalizacja wydajnoci w praktyce Podsumowanie

Rozdzia 2. Sprzt dla bazy danych Zrównowaenie wydatków na zakup sprztu Procesor Pami Dyski twarde Kontrolery dysków Niezawodne kontrolery i konfiguracja dysków Bufor zapisu Wpyw bufora bez wstrzymywania zapisu na wydajno Podsumowanie

22 23 23 26 27 27 30 30 31 32 34

35 35 36 37 37 43 48 49 52 53


Wysoko wydajny PostgreSQL 9.0

Rozdzia 3. Testy wydajnoci sprztu dla bazy danych Testy wydajnoci procesora i pamici memtest86+ Testowanie pamici za pomoc narzdzia STREAM Testy wydajnoci procesora Powody wolnego dziaania procesora i pamici Fizyczna wydajno dysku Swobodny dostp i liczba operacji wejcia-wyjcia na sekund Dostp sekwencyjny i ZCAV Liczba wykonywanych operacji zatwierdzania Narzdzia do testowania wydajnoci dysku hdtune dd bonnie++ sysbench Skomplikowane testy wydajnoci dysku twardego Przykadowe wyniki testu wydajnoci dysku Oczekiwana wydajno dysku Podsumowanie

Rozdzia 4. Konfiguracja dysków Maksymalna wielko systemu plików Odzyskiwanie danych po awarii systemu plików Systemy plików z ksigowaniem Systemy plików w Linuksie ext2 ext3 ext4 XFS Inne systemy plików w Linuksie Bariery zapisu Ogólne dostrajanie systemów plików w Linuksie Systemy plików Solaris i FreeBSD Solaris UFS FreeBSD UFS2 ZFS Systemy plików w Windows FAT32 NTFS Konfiguracja dysku dla PostgreSQL Dowizania symboliczne Tablespace Drzewo katalogów bazy danych Macierze dyskowe, RAID i konfiguracja dysków Podsumowanie

4

55 55 56 56 59 60 61 61 63 64 65 65 69 70 75 77 78 80 83

85 85 86 87 88 88 89 91 91 93 94 96 102 102 104 105 107 107 107 108 108 109 109 112 115


Spis treci

Rozdzia 5. Pami dla bufora bazy danych Jednostki pamici w pliku konfiguracyjnym postgresql.conf Zwikszenie parametrów pamici wspódzielonej w systemie Unix w celu zdefiniowania wikszego bufora Semafory jdra Oszacowanie wielkoci pamici wspódzielonej Przegld bufora bazy danych Instalacja pg_buffercache w bazie danych Konfiguracja ukadu dysków Utworzenie nowego bloku w bazie danych Zapis zmodyfikowanych bloków na dysku Naprawa bazy danych po awarii a wielko bufora Podstawy przetwarzania punktów kontrolnych Dziennik zapisu z wyprzedzeniem a proces naprawy po awarii Tworzenie punktów kontrolnych Cykl ycia bloku bazy danych Bufor bazy danych kontra bufor systemu operacyjnego Podwójnie buforowane dane Przecienie punktu kontrolnego Pocztkowe wskazówki dotyczce wielkoci Analiza zawartoci bufora Zapytania pozwalajce na przegld zawartoci bufora Przegld wielkoci bufora i jej dostosowanie Podsumowanie

Rozdzia 6. Optymalizacja konfiguracji serwera Interakcja z uywan konfiguracj Ustawienia domylne i sposoby ich zerowania Dozwolony kontekst do przeprowadzania zmian Ponowne wczytywanie pliku konfiguracyjnego Ustawienia na poziomie serwera Poczenia z baz danych Pami wspódzielona Rejestrowanie zdarze Polecenie VACUUM i dane statystyczne Punkty kontrolne Ustawienia mechanizmu WAL Replikacja WAL i PITR Ustawienia na poziomie klienta Optymalizacje niezalecane Optymalizacja ustawie nowego serwera Wskazówki dotyczce serwerów dedykowanych Wskazówki dotyczce serwerów wspódzielonych pgtune Podsumowanie

117 118 119 120 121 122 123 124 126 127 128 128 128 129 131 132 133 134 135 136 137 141 141

143 144 144 144 146 147 147 149 150 152 155 156 159 159 162 164 164 165 166 166

5


Wysoko wydajny PostgreSQL 9.0

Rozdzia 7. Rutynowa konserwacja Widoczno transakcji wraz z kontrol wspóbienoci Wewntrzne mechanizmy okrelajce widoczno Uaktualnienia Konflikty podczas blokowania rekordów Usunicie Zalety mechanizmu MVCC Wady mechanizmu MVCC Wyzerowanie identyfikatora transakcji Vacuum Implementacja procesu vacuum Operacja czyszczenia na podstawie kosztów Demon autovacuum Powszechnie spotykane problemy z vacuum i autovacuum Automatyczna analiza Nadmuchane indeksy Pomiar nadmuchania indeksu Szczegóowe monitorowanie stron indeksu i danych Monitorowanie dzienników zdarze zapyta Podstawowa konfiguracja rejestracji zdarze w PostgreSQL Rejestrowanie trudnych zapyta Analiza pliku dziennika zdarze Podsumowanie

Rozdzia 8. Sprawdzanie wydajnoci bazy danych Domylne testy pgbench Definicja tabeli Wykrywanie skali wielkoci bazy danych Definicja skryptu zapytania Konfiguracja serwera bazy danych pod ktem pgbench Rczne uruchamianie pgbench Wyniki graficzne generowane za pomoc pgbench-tools Konfiguracja pgbench-tools Przykadowe wyniki testów pgbench Test przeprowadzajcy jedynie zapytania SELECT Test transakcji TPC-B-like Analiza opó nienia Powody otrzymywania bdnych wyników i rónic Programistyczne wersje PostgreSQL Wtki worker i ograniczenia programu pgbench Wasne testy pgbench Test szybkoci wstawiania danych Testy wydajnoci Transaction Processing Performance Council Podsumowanie

6

167 167 168 169 171 173 174 174 174 176 177 179 181 185 190 191 191 193 194 194 199 200 207

209 209 210 210 211 213 214 216 216 217 217 218 219 222 223 224 225 225 226 228


Spis treci

Rozdzia 9. Indeksowanie bazy danych Przegld sposobów indeksowania Dane statystyczne suce do pomiaru wielkoci zapytania na dysku i bloku indeksu Uruchomienie przykadu Konfiguracja przykadowych danych Proste wyszukiwania za pomoc indeksów Pene skanowanie tabeli Tworzenie indeksu Wyszukiwanie za pomoc nieefektywnego indeksu

czenie indeksów Przejcie ze skanowania indeksowanego na sekwencyjne Klastry kontra indeksy Polecenie Explain oraz liczniki bufora Tworzenie indeksu i jego obsuga Zapewnienie unikalnoci indeksów Wspóbiene tworzenie indeksu Klastrowanie indeksu Ponowne indeksowanie Rodzaje indeksów B-tree Hash GIN GiST Zaawansowane sposoby korzystania z indeksów Indeksy wielokolumnowe Indeksy dla operacji sortowania Indeksy czciowe Indeksy bazujce na wyraeniu Indeksowanie na potrzeby wyszukiwania penego tekstu Podsumowanie

Rozdzia 10. Optymalizacja zapyta Przykadowe zbiory danych Pagila Dell Store 2 Podstawy polecenia EXPLAIN Obcienie zwizane z pomiarem Zachowanie przy zimnym i rozgrzanym buforze Struktura wzów planu zapytania Podstawy obliczania kosztu Narzdzia analizy danych polecenia EXPLAIN Graficzne przedstawienie danych EXPLAIN Rozbudowane dane wyjciowe Dane wyjciowe EXPLAIN w postaci czytelnej dla komputera Narzdzia suce do analizy planu

229 230 230 231 232 233 234 235 235 237 238 239 241 241 242 243 243 244 245 245 246 246 247 247 248 248 249 249 250 250

253 253 254 254 256 256 257 259 260 262 262 263 263 264

7


Wysoko wydajny PostgreSQL 9.0

czenie zbiorów rekordów Identyfikator krotki Skanowanie sekwencyjne Skanowanie indeksu Mapa bitowa i skanowanie indeksu Przetwarzanie wzów Wze Sort Wze Limit Wze Aggregate Wze HashAggregate Wze Unique Wze Result Wze Append Wze Group Wzy Subquery Scan i Subplan Operacje ustawiania Materializacja Skanowanie CTE Zczenia Ptle zagniedone Zczenie Merge Join Zczenia Hash Join Dane statystyczne Przegldanie i szacowanie za pomoc danych statystycznych Cele danych statystycznych Obszary trudne do oszacowania Inne parametry planowania zapytania effective_cache_size work_mem constraint_exclusion cursor_tuple_fraction Wykonywanie innych typów zapyta Poprawianie zapyta Optymalizacja dla w peni buforowanych zbiorów danych Poszukiwanie odpowiednika zapytania Wyczanie funkcji optymalizatora Rozwizywanie bdów optymalizatora Unikanie planu restrukturyzacji za pomoc OFFSET Zewntrzne róda problemów Ograniczenia SQL Numerowanie rekordów w SQL Uywanie funkcji Window do numerowania Uywanie funkcji Window do kumulowania wyniku Podsumowanie

8

265 265 266 266 267 268 268 270 271 272 273 274 275 276 277 278 279 280 281 281 283 285 290 290 293 295 295 295 297 298 298 298 299 300 300 301 305 306 309 309 309 311 311 313


Spis treci

Rozdzia 11. Dane statystyczne i dziaanie bazy danych Widoki danych statystycznych Widoki kumulacyjne i ywe Dane statystyczne tabel Operacje wejcia-wyjcia tabel Dane statystyczne indeksu Operacje wejcia-wyjcia indeksu Dane statystyczne dotyczce caej bazy danych Poczenia i aktywno Blokady Transakcje wirtualne Dekodowanie informacji o blokadzie Oczekiwanie na blokad transakcji Oczekiwanie na blokad tabeli Rejestrowanie informacji o blokadach Wykorzystanie dysku Bufor, zapis w tle oraz aktywno tworzenia punktu kontrolnego Zapis migawek pg_stat_bgwriter Optymalizacja z uyciem danych statystycznych dotyczcych zapisu w tle Podsumowanie

Rozdzia 12. Monitorowanie i trendy Narzdzia monitorujce w systemie Unix Przykadowa konfiguracja vmstat iostat top sysstat i sar Narzdzia monitorujce dla Windows Meneder zada Monitor systemu Windows Oprogramowanie trend贸w Rodzaje monitorowania i oprogramowanie trend贸w Nagios Cacti Munin Inne pakiety trend贸w Podsumowanie

Rozdzia 13. Pula pocze i buforowanie Pula pocze Liczniki puli pocze pgpool-II pgBouncer

315 315 317 318 320 322 323 324 324 325 326 327 330 331 332 333 335 337 339 341

343 343 344 344 347 355 357 360 360 360 362 363 364 366 366 367 369

371 371 372 373 374

9


Wysoko wydajny PostgreSQL 9.0

Buforowanie bazy danych memcached pgmemcache Podsumowanie

Rozdzia 14. Skalowanie za pomoc replikacji Hot Standby Terminologia Konfiguracja przekazywania danych mechanizmu WAL Protok贸 Streaming Replication Optymalizacja funkcji Hot Standby Menedery kolejki replikacji Slony Londiste Skalowanie odczytu za pomoc oprogramowania replikacji bazujcego na kolejce Wymagania aplikacji specjalnych Bucardo pgpool-II Inne interesujce projekty replikacji Podsumowanie

Rozdzia 15. Partycjonowanie danych Partycjonowanie o zasigu tabeli Okrelenie pola klucza uywanego do partycjonowania Wielkoci partycji Tworzenie partycji Przekierowywanie polece INSERT do partycji Plany zapyta dla pustej partycji Zmiana daty i uaktualnianie wyzwalacza Migracja partycjonowanej uywanej tabeli Zapytania partycjonowane Tworzenie nowych partycji Zalety partycjonowania Bdy czsto popeniane podczas partycjonowania Partycjonowanie poziome za pomoc PL/Proxy Generowanie wartoci hash Skalowanie za pomoc PL/Proxy Skalowanie za pomoc GridSQL Podsumowanie

Rozdzia 16. Unikanie najczciej spotykanych problem贸w Operacja bulk-loading Metody wczytywania danych Optymalizacja operacji bulk-loading Pominicie optymalizacji mechanizmu WAL

10

376 376 377 378

381 381 382 383 384 384 386 387 387 388 388 388 389 389 391

393 393 394 395 396 397 399 400 401 403 405 406 407 408 408 410 411 412

415 415 416 417 418


Spis treci

Ponowne utworzenie indeks贸w i dodanie ogranicze Przywracanie r贸wnolege Czyszczenie po operacji wczytania danych Najczstsze problemy zwizane z wydajnoci Zliczanie rekord贸w Niewyjanione operacje zapisu Wolne wykonywanie funkcji i polece skadowanych Testy wydajnoci PL/pgSQL Ogromne przecienie klucza zewntrznego Uycie pamici przez wyzwalacz Ogromne przecienie mechanizmu zbierajcego dane statystyczne Zmaterializowane widoki Profilowanie bazy danych gprof OProfile Visual Studio DTrace Problemy wydajnoci w poszczeg贸lnych wersjach Agresywne uaktualnienia PostgreSQL 8.1 8.2 8.3 8.4 9.0 Podsumowanie

Skorowidz

419 419 420 421 421 422 423 424 424 425 426 427 427 427 428 428 428 429 430 431 432 432 434 436 441

443

11


6 Optymalizacja konfiguracji serwera Podstawowe ustawienia optymalizacyjne PostgreSQL znajduj si w zwykym pliku tekstowym o nazwie postgresql.conf umieszczonym w strukturze katalogów bazy danych. Struktura katalogów w systemach z rodziny Unix czsto okrelana jest przy uyciu zmiennej rodowiskowej $PGDATA, a wic cieka dostpu do pliku konfiguracyjnego na tych platformach ma posta $PGDATA/postgresql.conf. W rozdziale przedstawiono omówienie parametrów konfiguracyjnych; praktycznie jest to powielony ogólny format stosowany w dokumentacji dostpnej na stronie http://www.postgresql. org/docs/current/static/runtime-config.html. Jednak tutaj, zamiast opisywania znaczenia kadego parametru, nacisk zosta pooony na udzielenie wskazówek dotyczcych ustawiania najwaniejszych wartoci z perspektywy uytkownika zainteresowanego optymalizacj wydajnoci. Rozdzia naley wic potraktowa jako uzupenienie materiau umieszczonego w oficjalnej dokumentacji, a nie jej zamiennik. Inne ródo informacji na omawiany tutaj temat znajduje si w artykule „Tuning Your PostgreSQL Server” dostpnym na stronie http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server, w którym pewne informacje s identyczne z przedstawionymi w rozdziale. Struktura artykuu wiki powoduje, e jest on aktualizowany na bieco i moe zawiera pewne informacje dotyczce przyszych wersji bazy danych PostgreSQL, który byy niedostpne w trakcie przygotowywania tego rozdziau.


Wysoko wydajny PostgreSQL 9.0

Interakcja z uywan konfiguracj Istnieje wiele sposobów modyfikacji parametrów bazy danych, nie s to jedynie edycja pliku konfiguracyjnego i ponowne uruchomienie serwera. Poznanie i zrozumienie tych sposobów ma znaczenie krytyczne zarówno dla skrócenia czasu niedostpnoci serwera jedynie z powodu rutynowych zmian konfiguracyjnych, jak i zagwarantowania, e czytelnik przeprowadza modyfikacj waciwych parametrów, gdy zmiana ma zosta wprowadzona natychmiast.

Ustawienia domylne i sposoby ich zerowania Baza danych ma dwa rodzaje ustawie, które mona okreli jako „ustawienia domylne” w zalenoci od kontekstu. Jednym z nich s ustawienia domylne powodujce ustalenie przez serwer pewnych wartoci, jeeli uytkownik nie zmieni adnych opcji — s to ustawienia, z którymi serwer jest uruchamiany jeszcze przed odczytaniem pliku konfiguracyjnego postgresql.conf. Od wydania PostgreSQL 8.4 wartoci te mona sprawdzi w kolumnie boot_val w widoku pg_settings. Wicej informacji na ten temat znajduje si na stronie http://www.postgresql.org/ docs/current/static/view-pg-settings.html. Po uruchomieniu serwera i wprowadzeniu zmian w parametrach, które równie posiadaj swoje wartoci domylne, powrót do wspomnianych wartoci domylnych nastpuje w wyniku wydania polecenia RESET. Dziaanie tego polecenia zostao omówione na stronie http://www. postgresql.org/docs/current/static/sql-reset.html. Te wartoci domylne mona przejrze w kolumnie reset_val znajdujcej si w widoku pg_settings.

Dozwolony kontekst do przeprowadzania zmian Kade ustawienie konfiguracyjne ma powizany z nim kontekst, w ramach którego moe zosta zmienione. Najlepszym sposobem okrelenia dozwolonego kontekstu do przeprowadzania zmian jest bezporednie zapytanie bazy danych. W przedstawionym poniej przykadzie pokazano po jednym wpisie dla kadego rodzaju kontekstu (w rzeczywistoci po wydaniu poniszego polecenia dane wyjciowe bd zawieray wszystkie parametry serwera): postgres=# select name,context from pg_settings; name | context ----------------------------+-----------archive_command | sighup archive_mode | postmaster block_size | internal log_connections | backend log_min_duration_statement | superuser search_path | user

144


Rozdzia 6. • Optymalizacja konfiguracji serwera

W oficjalnym podrczniku uytkownika pole kontekstu (context) nie jest zbyt dobrze udokumentowane. Poniej przedstawiono wic znaczenie rónych stosowanych ustawie w kolejnoci od najtrudniejszego do najatwiejszego do zmiany. Q internal . Ustawienia te w duej mierze s wewntrznymi ustawieniami bazy danych okrelonymi w trakcie jej kompilacji. Wywietlane s w celu dostarczenia uytkownikowi informacji, ale nie mog zosta zmienione bez ponownej kompilacji serwera. Q postmaster. Ustawienia s uaktualniane jedynie podczas penego uruchamiania serwera. Do tej kategorii zaliczaj si wszystkie opcje dotyczce pamici wspódzielonej. Q sighup. Wysanie sygnau HUP do serwera spowoduje ponowne odczytanie pliku konfiguracyjnego postgresql.conf, a wszelkie zmiany wprowadzone do tego parametru bd natychmiast zastosowane. Wicej informacji na ten temat znajduje si w kolejnym punkcie zatytuowanym „Ponowne wczytywanie pliku konfiguracyjnego”. Q backend. Ustawienia oznaczone za pomoc tej waciwoci s podobne do ustawie sighup, z wyjtkiem faktu, e wprowadzone zmiany nie maj wpywu na ju istniejce sesje bazy danych. Tylko sesje uruchomione po wprowadzeniu zmian bd stosoway nowe ustawienia. Istnieje niewiele parametrów oznaczonych omawian waciwoci, wikszo z nich wpywa jedynie na dziaania podejmowane w trakcie uruchamiania i zamykania sesji. Ostatnia opcja tej grupy (log_connections) nie moe dziaa wstecz, to znaczy nie ma moliwoci rozpoczcia rejestrowania zdarze ju nawizanego poczenia. Zdarzenia bd rejestrowane tylko dla nowych pocze ustanowionych po wczeniu opcji log_connections. Q superuser. Ustawienia tej grupy mog by modyfikowane w dowolnym momencie

przez kadego superuytkownika bazy danych (z reguy uytkownika, który utworzy baz danych, czyli bardzo czsto „postgres”). Aktywowanie zmiany nie wymaga penego, ponownego wczytania pliku konfiguracyjnego. Wikszo ustawie tej grupy jest powizana z rejestrowaniem w plikach dzienników zdarze rónych aspektów polece wykonywanych przez serwer. Q user. Te parametry poszczególni uytkownicy mog dostosowa w dowolnym momencie swojej sesji. Wprowadzone zmiany dotycz jedynie danej sesji. Wikszo parametrów zmienia sposób wykonywania zapyta, co pozwala na przeprowadzenie optymalizacji w ramach sesji. Na podstawie powyszej sesji mona si przekona, e udzielenie odpowiedzi na — wydawaoby si — proste pytanie, jaka jest bieca warto work_mem, moe by bardzo trudne, w zalenoci od wybranego kontekstu. Pocztkowo warto ta moe by wartoci okrelon w pliku konfiguracyjnym postgresql.conf, nastpnie moe by zmieniona w wyniku ponownego wczytania konfiguracji, a na kocu znów zmieniona przez uytkownika przed wykonaniem zapytania.

145


Wysoko wydajny PostgreSQL 9.0

Ponowne wczytywanie pliku konfiguracyjnego Istniej trzy sposoby pozwalajce bazie danych na ponowne wczytanie konfiguracji w celu uaktualnienia wartoci zaliczajcych si do grupy sighup. Jeeli czytelnik jest poczony z baz danych jako superuytkownik, mona uy funkcji pg_reload_conf() w nastpujcy spos贸b: postgres=# SELECT pg_reload_conf(); pg_reload_conf ---------------t

Sygna SIGHUP mona wysa r贸wnie rcznie za pomoc polecenia kill systemu Unix: $ ps -eaf | grep "postgres -D" postgres 11185 1 0 22:21 pts/0 麓postgres -D /home/postgres/data/ $ kill -HUP 11185

00:00:00 /home/postgres/inst/bin/

Wreszcie, sygna SIGHUP mona wysya do serwera przy uyciu narzdzia pg_ctl: $ pg_ctl reload server signaled

Niezalenie od uytego sposobu, po wysaniu sygnau SIGHUP w dziennikach zdarze bazy danych znajdzie si nastpujcy komunikat: LOG: received SIGHUP, reloading configuration files

Nastpnie, za pomoc polece, takich jak SHOW, lub po przejrzeniu widoku pg_settings mona potwierdzi, e zmiany zostay wprowadzone zgodnie z oczekiwaniami.

Umieszczanie ustawie w komentarzach Co si stanie w sytuacji, gdy pewien parametr zosta rcznie ustawiony, ale musi by wyczony w dziaajcym serwerze? Konkretna odpowied zaley od wersji uywanego serwera. Przyjmijmy zaoenie, e plik postgresql.conf zosta uruchomiony wraz z ustawionym nastpujcym parametrem: checkpoint_segments = 30

W celu wyczenia tego parametru trzeba wyedytowa plik konfiguracyjny, a parametr umieci w komentarzu: #checkpoint_segments = 30

Nastpnie konieczne jest nakazanie serwerowi, aby ponownie wczyta plik konfiguracyjny: $ pg_ctl reload

146


Rozdzia 6. • Optymalizacja konfiguracji serwera

Parametr checkpoint_segments jest ustawieniem kontekstu sighup. Od PostgreSQL 8.3 powysza zmiana spowoduje powrót do wartoci domylnej serwera (boot_val). W wersji 9.0 w dzienniku zdarze zostanie ponadto umieszczony nastpujcy komunikat: LOG: received SIGHUP, reloading configuration files LOG: parameter "checkpoint_segments" removed from configuration file, reset ´to default

Uycie wartoci domylnej mona potwierdzi za pomoc polecenia SHOW: $ psql -x -c "show checkpoint_segments" -[ RECORD 1 ]-------+-checkpoint_segments | 3

Jeeli uywany serwer to PostgreSQL w wersji 8.2 lub wczeniejszej, wprowadzona zmiana nie spowoduje adnego efektu, to znaczy parametr checkpoint_segments nadal bdzie mia warto 30. Dopiero po penym, ponownym uruchomieniu serwera nastpi przywrócenie wartoci domylnej, czyli 3. Poniewa takie zachowanie jest skomplikowane i uzalenione od uywanej wersji serwera, dowiadczeni administratorzy PostgreSQL zwykle dwukrotnie sprawdzaj parametry, które maj zamiar zmodyfikowa. Do sprawdzenia uywaj polecenia SHOW lub widoku pg_settings i upewniaj si w ten sposób, e parametr ma oczekiwan warto. W tym miejscu inn, skomplikowan kwesti jest moliwo doczenia dodatkowych plików konfiguracyjnych z poziomu gównego pliku postgresql.conf. W przypadku takiego rozwizania skutek jest taki sam jak wstawienie zawartoci okrelonego pliku we wskazanym miejscu. W widoku pg_settings mona pozna nazw pliku, z którego pochodzi dany parametr, wraz z numerem wiersza zawierajcego aktywn wersj. Warto te pamita, e w przypadku wielokrotnego ustawiania tego samego parametru pod uwag zawsze brane jest tylko ostatnie jego wystpienie.

Ustawienia na poziomie serwera Wprawdzie w pewnych przypadkach parametry mog by modyfikowane w innych kontekstach, przedstawione w tym podrozdziale s tymi, które mona zmodyfikowa w pliku postgresql.conf odczytywanym przed uruchomieniem serwera.

Poczenia z baz danych Istnieje wiele parametrów konfiguracyjnych okrelajcych sposoby zdalnego i lokalnego nawizywania poczenia z baz danych. Pena lista wspomnianych parametrów zostaa przedstawiona na stronie http://www.postgresql.org/docs/current/static/runtime-config-connection.html.

147


Wysoko wydajny PostgreSQL 9.0

listen_addresses W kadej instalacji wymagajcej obsugi pocze pochodzcych z systemów zdalnych konieczna jest modyfikacja parametru listen_addresses pozwalajcego na obsug takich pocze. Domylnie dozwolone s jedynie poczenia lokalne pochodzce od uytkownika zalogowanego do tego samego systemu, w którym znajduje si baza danych. Powszechnie stosowanym podejciem jest akceptacja pocze przychodzcych z kadego miejsca. W tym celu w gównym pliku konfiguracyjnym trzeba umieci poniszy wiersz: listen_addresses = '*'

Aby kontrolowa, kto moe nawiza poczenie, trzeba przeprowadzi konfiguracj pliku pg_hba.conf, co zostao omówione na stronie http://www.postgresql.org/docs/current/static/ auth-pg-hba-conf.html. Stosowanie takiego podejcia wie si z pewnym problemem dotyczcym wydajnoci. Filtrowanie pocze za pomoc dokadniej skonfigurowanego parametru listen_addresses moe by znacznie bardziej efektywne ni pozwolenie na nawizanie poczenia wszystkim klientom. Zezwolenie klientowi na poczenie, a nastpnie jego odrzucenie w wyniku wpisu znajdujcego si w pliku konfiguracyjnym pg_hba.conf powoduje niepotrzebne zuycie pewnych zasobów serwera i naraa system na niebezpieczestwo przeprowadzenia w ten sposób ataku typu odmowa usugi — DoS (ang. Denial Of Service) — przez zoliwego uytkownika. W praktyce tylko niewielka liczba serwerów PostgreSQL pozwala na bezporednie przyjmowanie zapyta pochodzcych z internetu. Normalnie s one filtrowane przez port domylny PostgreSQL (5432) na poziomie zapory sieciowej, co stanowi najefektywniejsze podejcie i jest czsto stosowan implementacj mechanizmu wspódzielonej ochrony take innych aplikacji. W systemie podczonym do internetu, takim jak na przykad klastry zawierajce bazy danych dla usug „w chmurach”, naley upewni si o stosowaniu wszystkich trzech warstw ochrony. Na poziomie zapory sieciowej warto okreli, kto moe nawiza poczenie z serwerem, dodatkowo zmniejszy list nasuchiwanych adresów za pomoc opcji listen_addresses, a take ograniczy uytkownikom dostp do bazy danych za pomoc pliku konfiguracyjnego pg_hba.conf.

max_connections Jednym z parametrów, dla którego czytelnik najczciej bdzie ustawia warto (z reguy 100) w pliku konfiguracyjnym postgresql.conf wygenerowanym przez initdb, jest max_connections. Poniewa, jak wspomniano w poprzednim rozdziale, kade poczenie wykorzystuje niewielk ilo pamici wspódzielonej, w systemach domylnie uywajcych niewielkiej iloci pamici wspódzielonej nawizanie wikszej iloci pocze nie zostanie nawet dozwolone. W zwizku z powyszym, podobnie jak w przypadku parametru shared_buffers, po utworzeniu klastra bazy danych i okreleniu w domylnym pliku konfiguracyjnym najwikszej dopuszczalnej wartoci (do 100) przeprowadzane s pewne badania. W praktyce ilo pamici niewspódzielonej uywanej przez kadego klienta podczas przeprowadzania operacji, takich jak sortowanie, jest wprawdzie znacznie wiksza, ale iloci wykorzystywanej pamici wspódzielonej nie mona pomin.

148


Rozdzia 6. โ€ข Optymalizacja konfiguracji serwera

Wane jest, aby w tym parametrze nie ustawia wartoci wyszej ni konieczna. Istnieje wiele wad wynikajcych z ustawienia wyszej wartoci parametru max_connections. Jedna z nich to marnowanie pamici wspรณdzielonej, ale to problem, ktรณrym naley si najmniej przejmowa, poniewa ilo pamici wspรณdzielonej wykorzystywanej przez kade poczenie pozostaje niewielka. Jednak s inne zasoby wykorzystywane przez klienta, na przykad alokacja pamici dla operacji sortowania (kontrolowana za pomoc parametru work_mem omรณwionego dalej, w tym rozdziale), ktรณra z reguy obejmuje ogromny blok pamici. Jeeli dozwolona bdzie obsuga wikszej liczby pocze, to by bezpiecznie oszczdza pami, trzeba rรณwnie zmniejszy wartoci wspomnianych ustawie, tak aby zminimalizowa niebezpieczestwo alokacji wikszej iloci pamici ni dostpna. Ze wzgldu na problemy zwizane z alokacj zasobรณw, serwery PostgreSQL w Windows mog mie bardzo ograniczon liczb obsugiwanych pocze. Bardzo czsto zdarza si, e zanim wyczerpana zostanie pami w obszarze Desktop Heap, obsuonych bdzie jedynie okoo 125 pocze. Wicej informacji na temat tego problemu oraz potencjalne sposoby jego rozwizania mona znale  na stronie http://wiki.postgresql.org/wiki/Running_&_Installing_PostgreSQL_On_Native_Windows.

Wreszcie, nawizywanie pocze w bazie danych PostgreSQL naley uwaa za operacj intensywnie wykorzystujc zasoby. Celem bazy danych nie jest dziaalno w charakterze komponentu nawizujcego poczenie z baz danych, przeprowadzajcego uwierzytelnianie i dotarcie do punktu, w ktรณrym zapytanie bdzie wykonane jako stosunkowo niewielka operacja. Ogรณlnie rzecz ujmujc, obcienie zwizane z nawizaniem kilkuset pocze staje si wskim gardem podczas dziaania serwera. Dokadna liczba pocze, po przekroczeniu ktรณrej staj si one obcieniem, zaley od uywanego sprztu i konfiguracji serwera. Jeeli czytelnik ma zamiar obsugiwa jednoczenie tysice zapyta, nie moe zastosowa podejcia, w ktรณrym kady klient bezporednio nawizuje poczenie z baz danych. W takim przypadku najczciej stosowanym rozwizaniem problemu skalowalnoci jest uycie oprogramowania obsugujcego pul pocze midzy aplikacj i baz danych. Temat ten zosta omรณwiony w rozdziale 13.

Pami wspรณdzielona Waciwe ustawienie wartoci parametrรณw zwizanych z pamici wspรณdzielon jest wane, poniewa ich zmiana zawsze wymaga penego, ponownego uruchomienia serwera bazy danych โ€” serwer nie ma moliwoci dynamicznej ponownej alokacji pamici wspรณdzielonej.

shared_buffers Parametr shared_buffers by szczegรณowo omawiany w poprzednim rozdziale.

149


Wysoko wydajny PostgreSQL 9.0

Ustawienia Free Space Map (FSM) Przestrze pozostaa w wyniku operacji usuwania bd modyfikacji danych jest umieszczana przez polecenie VACUUM w przestrzeni FSM (ang. Free Space Map). Nowe operacje alokacji wykorzystuj przestrze pochodzc z FSM, zamiast alokowa now przestrze na dysku. Od wydania PostgreSQL 8.4 przestrze FSM jest przechowywana na dysku, a tym samym automatycznie skaluje swoj wielko. W PostgreSQL do wersji 8.3 przestrze FSM bya przechowywana w pamici wspódzielonej, co wymagao dokadnego monitorowania iloci tej pamici i potencjalnie prowadzio do zwikszenia jej zuycia. Upewnienie si, e wartoci parametrów max_fsm_pages i max_fsm_relations w pliku konfiguracyjnym s wystarczajce, powinno by czci regularnych operacji konserwacyjnych w tych wersjach serwera PostgreSQL. Operacj t mona przeprowadzi rcznie bd wyda polecenie VACUUM VERBOSE przeprowadzajce pomiar biecego uycia pamici wspódzielonej w bardziej zautomatyzowany sposób. Wicej informacji na ten temat przedstawiono w rozdziaach 5. i 7.

Rejestrowanie zdarze

Ogólne ustawienia dotyczce rejestracji zdarze s wane, ale w pewnym sensie pozostaj poza zakresem tematycznym tej ksiki. Czytelnik moe by zmuszony do ustawienia parametrów, takich jak log_destination, log_directory i log_filename, w sposób zgodny z systemem oraz wymaganiami administratora uywanego rodowiska. Parametry te maj domylnie ustawione rozsdne wartoci pozwalajce na rozpoczcie pracy w wikszoci systemów. W rozdziale 7. zostanie poruszony problem dostosowania omawianych parametrów w celu przeprowadzenia rejestracji zdarze w plikach CSV, co moe by uyteczne podczas pomiaru czasu wykonywania zapyta. W wikszoci systemów Unix bardzo czsto zdarza si, e opcje dotyczce rejestracji zdarze bazy danych s ustawiane w skryptach uruchamiajcych i zatrzymujcych serwer, a nie bezporednio w pliku konfiguracyjnym postgresql.conf. Jeeli w celu rcznego uruchomienia serwera stosowane jest polecenie pg_ctl, czytelnik moe odkry, e rejestracja zdarze nastpuje poprzez ich bezporednie wywietlenie na ekranie. W takim przypadku, aby dowiedzie si, o co chodzi, trzeba spojrze do skryptu uruchamiajcego serwer w zwyky sposób (najczciej /etc/init.d/postgresql). W wikszoci przypadków do polecenia pg_ctl wystarczy doda opcj -l nazwa_pliku, która powoduje przekierowanie danych wyjciowych do standardowego pooenia.

log_line_prefix Warto domylna opcji log_line_prefix jest pusta, a to zdecydowanie niepodane. Warto dobra na pocztek bdzie miaa nastpujc posta: log_line_prefix='%t:%r:%u@%d:[%p]: '

150


Rozdzia 6. • Optymalizacja konfiguracji serwera

Powyszy parametr powoduje umieszczenie w kadym wierszu dziennika zdarze takich informacji jak: Q %t: znacznik czasu; Q %u: nazwa uytkownika bazy danych; Q %r: nazwa zdalnego komputera, z którego nawizano poczenie; Q %d: nazwa bazy danych, z któr nawizano poczenie; Q %p: identyfikator procesu poczenia.

Na pocztku moe nie by takie oczywiste, po co zostay zastosowane powysze wartoci domylne, a zwaszcza identyfikator procesu. Jednak po próbie rozwizania kilku problemów zwizanych z wydajnoci konieczno zapisania w pliku dziennika zdarze wymienionych informacji stanie si bardziej oczywista i czytelnik bdzie zadowolony z faktu posiadania tych informacji. Inne podejcie warte rozwaenia to ustawienie wartoci parametru log_line_prefix w taki sposób, aby dzienniki zdarze byy zgodne z programem pgFouine, omówionym w rozdziale 7. Jest to rozsdny, przeznaczony do ogólnego rejestrowania zdarze prefiks, a wiele witryn i tak ostatecznie stosuje pewne mechanizmy analizy zapyta.

log_statement Oto opcje do zastosowania w tym parametrze: Q none. Nie s rejestrowane adne informacje na poziomie polece. Q ddl. Rejestrowane s jedynie polecenia DDL (ang. Data Definition Language), na przykad CREATE lub DROP. Takie ustawienie mona zastosowa nawet w systemie

produkcyjnym i jest przydatne podczas wychwytywania najwaniejszych zmian przypadkowo lub celowo wprowadzonych przez administratorów. Q mod. Rejestrowane s wszystkie polecenia modyfikujce warto, czyli praktycznie wszystkie, poza prostymi poleceniami SELECT . Jeeli obcienie w serwerze to przede wszystkim polecenia SELECT przeprowadzajce niewielk ilo zmian w danych, praktycznym rozwizaniem moe by pozostawienie tej opcji wczonej przez cay czas. Q all. Rejestrowane s wszystkie polecenia. Ogólnie rzecz ujmujc, pozostawienie tej opcji wczonej w serwerze produkcyjnym jest niepraktyczne, ze wzgldu na obcienie powodowane przez operacj rejestrowania zdarze. Gdy jednak serwer jest na tyle potny, aby poradzi sobie z takim obcieniem, pozostawienie tej opcji wczonej przez cay czas moe okaza si pomocne. Rejestrowanie polece to uyteczna technika pozwalajca na wyszukiwanie problemów zwizanych z wydajnoci. Analiza informacji zebranych po ustawieniu parametru log_statement i powizanych róde informacji szczegóowych na poziomie polece moe ukaza prawdziw przyczyn wielu rodzajów problemów wydajnoci. Zebrane w ten sposób informacje mona poczy z odpowiednimi narzdziami analizy, które omówiono w rozdziale 7.

151


Wysoko wydajny PostgreSQL 9.0

log_min_duration_statement Gdy znamy ju ilo czasu wymagan do wykonania typowego zapytania, uycie parametru log_min_duration_statement pozwoli na rejestrowanie tylko tych polece, których wykonanie przekroczy ustalony czas. Warto jest podawana w milisekundach, tak wic parametr mona ustawi w nastpujcy sposób: log_min_duration_statement=1000

Powysze polecenie powoduje rejestracj w dzienniku zdarze tylko polece wykonywanych duej ni sekund. Parametr moe by uyteczny do wyszukiwania róde „odstajcych” polece, których wykonanie trwa znacznie duej ni pozostaych. Jeeli uywany jest PostgreSQL w wersji 8.4 lub nowszej, zamiast tej funkcji preferowanym rozwizaniem moe by modu auto_explain. Wicej informacji na temat moduu mona znale  na stronie http://www.postgresql.org/docs/8.4/static/auto-explain.html. Modu umoliwia sprawdzenie operacji wykonywanych przez powolne zapytania po przejrzeniu powizanych z nimi planów EXPLAIN.

Polecenie VACUUM i dane statystyczne Baza danych PostgreSQL wymaga dwóch podstawowych form regularnej obsugi podczas dodawania, uaktualniania i usuwania danych. Polecenie VACUUM powoduje usunicie mieci po starych transakcjach, cznie z usuniciem informacji, które nie s duej widoczne, oraz zwrócenie zwolnionego miejsca, tak aby mogo by ponownie wykorzystane. Im wicej w bazie danych wykonywanych polece UPDATE i DELETE, tym czciej trzeba przeprowadza operacj usuwania mieci. Nawet w statycznych tabelach, których zawarto nigdy nie ulega zmianie, od czasu do czasu trzeba wykona operacj usuwania mieci. Polecenie ANALYZE przeglda tabele w bazie danych i zbiera na ich temat dane statystyczne — informacje, takie jak liczba posiadanych rekordów bd liczba odmiennych wartoci w tabelach. Wiele aspektów planowania zapytania zaley od prawidowego zebrania tych danych. Wicej informacji na temat polecenia VACUUM znajduje si w rozdziale 7., natomiast temat stosowania danych statystycznych poruszono w rozdziale 10.

Demon autovacuum Poniewa zadanie usuwania mieci ma w duszej perspektywie znaczenie krytyczne dla bazy danych, od wydania PostgreSQL 8.1 w serwerze umieszczono demon autovacuum, który dziaa w tle i zajmuje si wspomnianym zadaniem. Aktywacja demona nastpuje po wykonaniu w bazie danych liczby zmian przekraczajcej warto obliczon na podstawie wielkoci tabeli.

152


Rozdzia 6. • Optymalizacja konfiguracji serwera

Parametr dla demona autovacuum jest wczony domylnie w PostgreSQL 8.3, a warto domylna jest ustalona w sposób wystarczajcy do dziaania mniejszej bazy danych i wymaga jedynie niewielkiej rcznej modyfikacji. Ogólnie rzecz biorc, trzeba uwaa, aby ilo danych w obszarze FSM nie przekraczaa wartoci ustalonej przez parametr max_fsm_pages. Od PostgreSQL 8.4 opisane wymaganie nie stanowi ju powodu do zmartwie dla uytkownika.

Wczanie demona autovacuum w starszych wersjach Jeeli demon autovacuum jest dostpny, ale nie jest wczony domylnie, jak ma to miejsce w bazach danych PostgreSQL 8.1 i 8.2, istnieje kilka powizanych z nim parametrów, które musz by wczone w celu zapewnienia jego prawidowej pracy. Wicej informacji na ten temat przedstawiono na stronach http://www.postgresql.org/docs/8.1/interactive/maintenance.html i http://www.postgresql.org/docs/8.2/interactive/routine-vacuuming.html. W wymienionych wersjach w pliku konfiguracyjnym postgresql.conf trzeba ustawi trzy parametry: stats_start_collector=true stats_row_level=true autovacuum=on

Warto zwróci uwag, e — zgodnie z ostrzeeniem przedstawionym w dokumentacji — zalecane jest równie uycie parametru superuser_reserved_connections zezwalajcego na dziaanie demonów autovacuum w wymienionych wersjach bazy danych. Demon autovacuum dostpny w wersjach 8.1 i 8.2 nie jest a tak wydajny jak dostarczany w wersjach 8.3 i nowszych. Uzyskanie odpowiedniego balansu zapewniajcego prawidow obsug bazy danych bez zbyt duego obcienia serwera bdzie wymagao pewnych eksperymentów i dopasowywania wartoci. Poniewa jest to tylko jeden proces, pozostawienie go, by dziaa w tle, gdy serwer jest zajty, bdzie mniejszym obcieniem dla serwera. Zagadnienie to nie bdzie tutaj obszernie omawiane. Ogólnie rzecz biorc, znacznie lepszym rozwizaniem jest powicenie czasu na uaktualnienie bazy danych PostgreSQL do wydania zawierajcego nowsz wersj demona autovacuum ni próba dostosowania starszej wersji. Szczególnie dotyczy to sytuacji, kiedy równoczenie wystpuj inne problemy z wydajnoci, których nie mona tak atwo rozwiza w starszej wersji serwera.

maintenance_work_mem Kilka operacji w serwerze bazy danych wymaga pamici roboczej dla operacji wikszych ni zwyke sortowanie. Polecenia VACUUM, CREATE INDEX oraz ALTER TABLE ADD FOREIGN KEY mog alokowa maksymaln ilo pamici okrelon przez parametr maintenance_work_mem. Jest mao prawdopodobne, aby wiele sesji przeprowadzao jednoczenie tego rodzaju operacje. Dla tego parametru mona okreli warto znacznie wysz ni w standardowej opcji work_mem ustawianej dla kadego klienta. Warto pamita, e przynajmniej parametr autovacuum_max_workers

153


Wysoko wydajny PostgreSQL 9.0

(dla którego od wersji 8.3 warto domylna wynosi 3) zaalokuje t ilo pamici, dlatego te podczas okrelania tej wartoci naley uwaa na takie sesje (prawdopodobnie z jedn lub dwiema sesjami wykonujcymi operacj CREATE INDEX). Przy zaoeniu, e liczba demonów autovacuum nie zostaa zwikszona, typowe wysokie ustawienie omawianej wartoci w nowoczesnym serwerze bdzie miao warto 5% cakowitej iloci pamici RAM. Tak wic nawet pi procesów nie wykorzysta wicej ni jedn czwart dostpnej pamici RAM. Oznacza to, e maintenance_work_mem wykorzystuje okoo 50 MB pamici na kady dostpny gigabajt pamici RAM w serwerze.

default_statistics_target PostgreSQL podejmuje decyzje dotyczce sposobu wykonywania zapyta na podstawie danych statystycznych zebranych dla kadej tabeli i przechowywanych w bazie danych. Tego rodzaju informacje s zbierane podczas analizy tabel za pomoc polecenia ANALYZE lub demona autovacuum. W kadym przypadku ilo informacji zbierana w trakcie analizy jest okrelana przez parametr default_statistics_target. Zwikszenie wartoci tego parametru wydua analiz. Analiza regularnie przeprowadzana przez demon autovacuum w tle stanowi coraz wiksze obcienie podczas konserwacji bazy danych. Jednak brak odpowiednich danych statystycznych dotyczcych tabeli skutkuje ryzykiem uycia niewaciwego planu wykonywania zapyta wzgldem tej tabeli. Warto domylna wymienionej opcji z reguy jest bardzo niska (to znaczy 10), ale w PostgreSQL 8.4 zostaa zwikszona do 100. Stosowanie wikszej wartoci byo popularne take w starszych wersjach bazy danych w celu ogólnego poprawienia zachowania zapyta. Indeksy korzystajce z operatora LIKE dziaaj znacznie lepiej, gdy opisywany parametr ma warto wysz ni 100, a nie nisz, co wie si ze zdefiniowan na stae zmian sposobu ich dziaania po uyciu wartoci wikszej ni 100 dla tego parametru. Warto zwróci uwag, e zwikszenie wartoci parametru default_statistics_target skutkuje ogólnym spowolnieniem systemu, jeeli w ogóle nie s wykonywane zapytania, w których dodatkowe dane statystyczne powoduj wybór lepszego planu wykonywania. Z tego powodu pewne proste testy wydajnoci pokazuj, e baza danych PostgreSQL w wersji 8.4 jest nieco wolniejsza od 8.3, jeeli obie stosuj wartoci domylne parametrów. W niektórych przypadkach po instalacji wersji 8.4 mona zmniejszy warto wymienionego parametru. Ustawianie wyjtkowo duej wartoci parametru default_statistics_target jest odradzane, ze wzgldu na generowane wówczas ogromne obcienie dla bazy danych. Jeeli w tabeli znajduje si kolumna, o której wiadomo, e potrzebuje lepszych danych statystycznych, mona wzgldem tej kolumny wykona polecenie ALTER TABLE SET STATISTICS w celu dostosowania dla niej wartoci parametru. Takie rozwizanie jest lepsze ni zwikszanie wartoci domylnej parametru dla caego systemu, gdy wtedy kada tabela „paci” za wymaganie jednej kolumny w bazie danych. Zazwyczaj kolumny wymagajce do prawidowej pracy naprawd duej iloci danych statystycznych musz mie warto parametru default_statistics_target równ 1000 (w nowszych wersjach PostgreSQL zwikszono j do 10000), aby zmiana bya

154


Rozdzia 6. • Optymalizacja konfiguracji serwera

widoczna. Jest to warto duo wiksza ni ilo danych statystycznych konieczna do zebrania w kadej tabeli bazy danych.

Punkty kontrolne Sposób dziaania mechanizmu punktów kontrolnych i dotyczce go parametry przedstawiono w poprzednim rozdziale. W tym miejscu nacisk pooono na powszechnie stosowane praktyki ustawiania wartoci pocztkowych dla tych parametrów.

checkpoint_segments Kady segment mechanizmu WAL zabiera do 16 MB. Jak przedstawiono na stronie http://www. postgresql.org/docs/current/interactive/wal-configuration.html, maksymaln liczb segmentów, która moe by w uyciu w danym momencie, mona obliczy ze wzoru: (2 + checkpoint_completion_target) * checkpoint_segments + 1

Warto zwróci uwag, e baza danych PostgreSQL w wersjach wczeniejszych ni 8.3 nie obsuguje rozproszonych punktów kontrolnych, ale nadal mona uy powyszego wzoru i po prostu dla brakujcej wartoci wykorzysta poniszy fragment kodu: checkpoint_completion_target=0

Wynik to cakowita wielko wszystkich segmentów mechanizmu WAL, które mog znale  si na dysku. Pozwala to zarówno na ustalenie iloci zajmowanego miejsca na dysku twardym, jak i oszacowanie iloci czasu potrzebnego na przeprowadzenie naprawy po awarii bazy danych. Oczekiwany wzrost wielkoci dziennika zdarze pg_xlog zosta przedstawiony w poniszej tabeli. checkpoint_segments

checkpoint_completion_target=0

target=0.5

target=0.9

3

112 MB

144 MB

160 MB

10

336 MB

416 MB

480 MB

32

1040 MB

1296 MB

1504 MB

64

2064 MB

2576 MB

2992 MB

128

4112 MB

5136 MB

5968 MB

256

8208 MB

10256 MB

11904 MB

Ogólny wniosek, który mona wycign na podstawie przedstawionych tutaj danych, jest nastpujcy: na kade 32 segmenty punktów kontrolnych trzeba si liczy z akumulacj okoo 1 GB danych mechanizmu WAL. Poniewa w przypadku takiej iloci danych naprawa bazy danych po awarii moe zaj sporo czasu, warto 32 to najwiksza, jak warto zastosowa w powanym, produkcyjnym serwerze bazy danych. Warto domylna 3 jest jednak dla wikszoci systemów stanowczo za maa, nawet w niewielkich instalacjach naley rozway jej zwikszenie do 10.

155


Wysoko wydajny PostgreSQL 9.0

Warto wiksz ni 32 stosuje si zazwyczaj tylko w mniejszych serwerach przeprowadzajcych operacje typu bulk-loading, poniewa moe to znacznie zwikszy wydajno, a czas naprawy bazy danych po ewentualnej awarii jest nieistotny. Bazy danych, które regularnie przeprowadzaj operacje bulk-loading, mog wymaga wikszej wartoci parametru checkpoint_segments.

checkpoint_timeout Warto domylna tego parametru wynoszca 5 minut jest wystarczajca dla wikszoci instalacji. Jeeli system nie nada z operacjami zapisu i zwikszono warto parametru checkpoint_ ´segments w taki sposób, e parametr checkpoint_timeout sta si podstawowym sposobem inicjowania operacji tworzenia punktu kontrolnego, rozsdne bdzie rozwaenie zwikszenia wartoci take dla parametru checkpoint_timeout. Ustalenie przerwy w dugoci dziesiciu minut lub nawet wicej midzy tworzeniem punktów kontrolnych nie jest niebezpieczne, po prostu wydua czas naprawy bazy danych po ewentualnej awarii. Poniewa jest to jeden z parametrów, które maj wpyw na dugo czasu niedostpnoci bazy danych po awarii, jego warto naley ustawia bardzo ostronie.

checkpoint_completion_target Po zwikszeniu wartoci parametru checkpoint_segments do przynajmniej 10 rozsdne wydaje si równie zwikszenie wartoci parametru checkpoint_competion_target do jego praktycznego maksimum wynoszcego 0,9. W ten sposób uzyskiwane jest maksymalne rozproszenie punktów kontrolnych, co przynajmniej teoretycznie oznacza mniejsze obcienie zwizane z operacjami wejcia-wyjcia. Jednak w niektórych sytuacjach utrzymywanie wartoci domylnej 0,5 nadal bdzie lepszym rozwizaniem, poniewa zmniejsza prawdopodobiestwo, e operacje zapisu jednego punktu kontrolnego zazbi si z operacjami drugiego. Wydaje si nieprawdopodobne, aby warto poniej 0,5 bya w ogóle efektywna dla rozpraszania punktów kontrolnych. Co wicej, o ile liczba segmentów nie jest naprawd ogromna, mae zmiany wartoci parametru maj niewielkie znaczenie. Jedyne sensowne podejcie polega na wypróbowaniu obu wartoci (0,5 i 0,9) w aplikacji i sprawdzeniu na poziomie monitorowania systemu operacyjnego, która powoduje mniejsze obcienie zwizane z operacjami wejcia-wyjcia.

Ustawienia mechanizmu WAL Mechanizm WAL (ang. Write-Ahead Log) uywany w PostgreSQL zosta omówiony w rozdziale 5.

wal_buffers Dokumentacja parametru wal_buffers sugeruje, e warto domylna wynoszca 64 kB jest wystarczajca tak dugo, dopóki pojedyncza transakcja nie przekracza wymienionej wartoci.

156


Rozdzia 6. • Optymalizacja konfiguracji serwera

Jednak w praktyce testy wydajnoci intensywnie wykorzystujce operacje zapisu pokazuj, e optymaln wydajno mona osign po ustawieniu znacznie wikszej wartoci, co najmniej 1 MB lub wicej. Jedyn wad jest zwikszony poziom wykorzystania pamici wspódzielonej. Biorc po uwag, e nie ma potrzeby, aby wicej ni pojedynczy segment WAL musia by buforowany, a take ilo pamici instalowan w nowoczesnych serwerach, parametrowi wal_buffers mona obecnie przydzieli znacznie wiksz warto: wal_buffers=16MB

Po ustawieniu powyszej wartoci mona zapomnie o parametrze wal_buffers jako potencjalnym wskim gardle lub komponencie, który pó niej trzeba optymalizowa. W przypadku niewielkiej iloci pamici w serwerze mona rozway uycie mniejszej wartoci.

wal_sync_method W rozdziale 2. wyjaniono, jak wane jest skonfigurowanie serwera w taki sposób, aby unika wykorzystywania nietrwaych buforów zapisu. Jednym z celów parametru wal_sync_method jest optymalizacja zachowania podczas korzystania z nietrwaych buforów zapisu. Zachowanie domylne jest w pewien sposób odmienne od wikszoci opcji. Podczas kompilacji kodu ródowego serwera rozwaane s róne moliwe sposoby zapisu. Jeden, uznany za najbardziej efektywny, staje si pó niej stosowany domylnie w trakcie kompilacji. Jednak warto ta nie jest zapisana w pliku konfiguracyjnym postgresql.conf wygenerowanym przez initdb, co odrónia j od innych automatycznie wykrywanych i charakterystycznych dla platform wartoci, takich jak shared_buffers. Przed zmian czegokolwiek naley za pomoc polecenia SHOW sprawdzi, co w uywanej przez czytelnika platformie zostao wykryte jako najszybsza, bezpieczna metoda. W systemie Linux wynik jest nastpujcy: postgres=# show wal_sync_method; wal_sync_method ----------------fdatasync

Z kolei na platformach Windows i Mac OS X istnieje specjalny parametr gwarantujcy, e system operacyjny wyczyci wszystkie bufory zapisu. Na wspomnianych platformach wartoci bezpieczn, która wcza takie zachowanie, jest: wal_sync_method=fsync_writethrough

Jeeli ustawienie takie jest dostpne, naprawd naley je wykorzysta! Pracuje ono prawidowo i gwarantuje wykonywanie bezpiecznych operacji zapisu w bazie danych bez spowalniania innych aplikacji, co ma miejsce w przypadku cakowitego wyczenia bufora zapisu w dysku twardym.

157


Wysoko wydajny PostgreSQL 9.0

Jednak powysze ustawienie nie bdzie funkcjonowao na wszystkich platformach. Warto pamita, e po zmianie wartoci domylnej na przedstawion powyej nastpi pewien spadek wydajnoci. Dzieje si tak zawsze podczas przejcia z buforowania niebezpiecznego do bezpiecznego. Na innych platformach optymalizacja parametru wal_sync_method moe by znacznie bardziej skomplikowana. Teoretycznie istnieje moliwo poprawienia wydajnoci operacji zapisu w systemach z rodziny Unix poprzez zmian dowolnej metody zapisu uywajcej par write/fsync lub write/fdatasync na stosujc zapis prawdziwie synchroniczny. Mona si przekona, po wydaniu polecenia SHOW, e na platformach obsugujcych bezpieczne zachowanie zapisu DSYNC jest to opcja stosowana domylnie: wal_sync_method=open_datasync

Jednak take w tym przypadku opcja ta nie jest jawnie podana w pliku konfiguracyjnym. Jeeli tak jest na uywanej przez czytelnika platformie, mona przeprowadzi jedynie niewielk optymalizacj. Warto open_datasync to ogólnie optymalne podejcie, a kiedy wymieniona opcja jest dostpna, pozwala nawet na bezporednie uywanie urzdze wejcia-wyjcia, a take pomijanie bufora systemu operacyjnego. W systemie Linux sytuacja jest prawdopodobnie najbardziej skomplikowana. Jak przedstawiono we wczeniejszym fragmencie kodu, platforma Linux domylnie uywa metody fdatasync. Za pomoc poniszego polecenia mona wczy tryb synchronicznych operacji zapisu: wal_sync_method=open_sync

Ponadto w wielu przypadkach mona odkry, e metoda ta dziaa szybciej — czasami nawet znacznie szybciej — ni okrelona domylnie. Jednak bezpieczestwo jej stosowania zaley od uywanego systemu plików. W wikszoci systemów Linux domylnym systemem plików jest ext3, który w wielu przypadkach nie obsuguje bezpiecznych operacji zapisu O_SYNC, co moe doprowadzi do uszkodzenia danych. Przykady niebezpieczestw takiego ustawienia na platformie Linux przedstawiono w wtku „PANIC caused by open_sync on Linux” znajdujcym si na stronie http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php. Istniej dowody, e w ostatnich wersjach jdra (2.6.32) ten problem nie istnieje, jeli uywany jest system plików ext4, ale takie rozwizanie nie zostao jeszcze intensywnie przetestowane na poziomie bazy danych. W kadym przypadku podczas przeprowadzania wasnych testów wartoci parametru wal_sync_method naley wykona równie test polegajcy na „wycigniciu z gniazda sieciowego

wtyczki przewodu zasilajcego serwer”. Spowoduje to nage odcicie zasilania serwera i pozwoli na sprawdzenie, czy nastpia utrata jakichkolwiek danych w wyniku stosowania testowanej metody. Zalecane jest równie przeprowadzenie dugotrwaych testów przy duym obcieniu, aby znale  sporadyczne bdy, które mog doprowadzi do awarii.

158


Rozdzia 6. โ€ข Optymalizacja konfiguracji serwera

Replikacja WAL i PITR Parametry archive_mode, archive_command oraz archive_timeout zostay omรณwione w rozdziale 14.

Ustawienia na poziomie klienta Wprawdzie wszystkie parametry omawiane w tym podrozdziale mog by dostosowane na poziomie klienta, podane jest ustawienie dla nich odpowiednich wartoci pocztkowych w gรณwnym pliku konfiguracyjnym. Gdy trzeba zmieni warto parametru w poszczegรณlnych klientach, zawsze mona j wprowadzi na czas trwania sesji, wykorzystujc do tego polecenie SET.

effective_cache_size Jak wspomniano w poprzednim rozdziale, baza danych PostgreSQL uywa zarรณwno wasnej dedykowanej jej pamici (shared_buffers), jak i korzysta z bufora systemu plikรณw. W pewnych sytuacjach, podczas podejmowania decyzji dotyczcych efektywnoci uycia indeksu bd nie, baza danych porรณwnuje obliczone przez siebie wielkoci wzgldem efektywnej sumy wszystkich wymienionych buforรณw. Warto t spodziewa si znale  w parametrze effective_ ยดcache_size. Ta sama regua, wedle ktรณrej warto parametru shared_buffers powinna wynosi okoo 25% iloci pamici systemowej, mรณwi take, e warto parametru effective_cache_size powinna wynosi od 50 do 75% iloci pamici RAM. Aby znacznie dokadniej oszacowa wartoci, trzeba na pocztek przyjrze si buforowi systemu plikรณw: Q w systemach z rodziny Unix oszacowanie wielkoci bufora systemu plikรณw wymaga dodania wartoci free i cached wywietlanych przez polecenia free i top; Q w systemach Windows naley wywietli okno Menedera zada Windows, przej

na zakadk Wydajno i odczyta warto w linii Bufor systemu. Po przyjciu, e baza danych zostaa ju uruchomiona, do obliczonych wartoci trzeba doda jeszcze warto shared_buffers, w ten sposรณb otrzyma si effective_cache_size. Jeeli baza danych nie zostaa jeszcze uruchomiona, bufor systemu operacyjnego bdzie zwykle wystarczajco dokadny do oszacowania wartoci parametru. Po uruchomieniu bazy danych wikszo pamici przeznaczonej dla bazy danych zwykle i tak bdzie zaalokowana na potrzeby jej bufora. Parametr effective_cache_size nie powoduje alokacji jakiejkolwiek pamici. Jest uywany wycznie po to, by okreli sposรณb wykonywania zapyta, i jego ogรณlne oszacowanie jest wystarczajce do wikszoci celรณw. Kiedy jednak warto ta bdzie zbyt wysoka, wykonywanie zapyta moe skutkowa zakรณceniami w buforze zarรณwno bazy danych, jak i systemu operacyjnego

159


Wysoko wydajny PostgreSQL 9.0

wynikajcymi z koniecznoci odczytania ogromnej liczby bloków wymaganych do wykonania zapytania, które bardzo atwo zmieci si w pamici RAM. Bardzo rzadko zdarza si, aby parametr ten by optymalizowany na poziomie klienta, nawet jeli jest to moliwe.

synchronous_commit W rozdziale 2. obcienie zwizane z oczekiwaniem, a fizyczny dysk zakoczy operacj zatwierdzania, wskazano jako potencjalne wskie gardo podczas zatwierdzania transakcji. Jeeli czytelnik nie posiada podtrzymywanego bateryjnie bufora zapisu, który mógby przypieszy takie operacje, ale koniecznie chce przypieszy operacje zatwierdzania transakcji, rodzi si pytanie, w jaki sposób mona to zrobi. Standardowym podejciem jest wyczenie opcji synchronous_commit, która czasami nazywana jest opcj wczajc asynchroniczne zatwierdzenia. Powoduje ona zgromadzenie w wiksz grup operacji zatwierdzenia w czstotliwoci okrelonej przez powizany z ni parametr wal_writer_delay. Ustawienia domylne gwarantuj realne zatwierdzenie transakcji na dysku po upywie co najwyej 600 milisekund od chwili zatwierdzenia transakcji przez klienta. W trakcie tego okresu czasu, który mona skróci, liczc si jednoczenie ze spadkiem szybkoci, niezatwierdzone dane nie bd odzyskane po ewentualnej awarii serwera. Warto zwróci uwag, e opisywany parametr mona wyczy dla pojedynczego klienta na czas trwania jego sesji, zamiast wycza go dla caego serwera. Wyczenie dla klienta odbywa si za pomoc polecenia SET: SET LOCAL synchronous_commit TO OFF;

W ten sposób czytelnik dysponuje opcj stosowania rónych fizycznych gwarancji zatwierdzania dla odmiennych typów danych wstawianych do bazy danych. Aktywnie monitorowana tabela — do której dane s najczciej wstawiane, a uamek sekundy strat akceptowany — jest dobrym kandydatem dla asynchronicznych zatwierdze. W przypadku rzadziej zapisywanej tabeli przechowujcej rzeczywiste transakcje finansowe preferowanym rozwizaniem jest stosowanie standardowych, synchronicznych zatwierdze.

work_mem Kiedy wykonywane jest zapytanie wymagajce sortowania danych, baza danych szacuje ilo danych koniecznych do uycia i nastpnie porównuje obliczon warto do okrelonej w parametrze work_mem. Jeeli jest wiksza (a warto domylna parametru work_mem wynosi 1 MB), zamiast sortowa dane w pamici, zapisze je na dysku i przeprowadzi operacj sortowania dyskowego. Taka operacja jest znacznie wolniejsza ni sortowanie przeprowadzane w pamici. Dlatego te, w przypadku regularnego sortowania danych i posiadania wolnej pamici, zwikszenie wartoci parametru work_mem moe by jednym z najefektywniejszych sposobów przypieszenia dziaania serwera. Magazyny danych generujce ogromne raporty maj w swoich serwerach gigabajty pamici przypisane parametrowi work_mem.

160


Rozdzia 6. • Optymalizacja konfiguracji serwera

Problem polega na tym, e niekoniecznie mona atwo przewidzie liczb operacji sortowania przeprowadzanych przez klienta, a parametr work_mem jest okrelany dla kadej operacji sortowania, a nie dla kadego klienta. Oznacza to, e ilo pamici uywanej przez work_mem moe by teoretycznie nieograniczona, jeeli liczba klientów jednoczenie przeprowadzajcych sortowanie bdzie wystarczajco dua. W praktyce w typowym zapytaniu nie ma zbyt wielu operacji sortowania, najczciej tylko jedna bd dwie. Ponadto nie wszyscy aktywni klienci bd w tym samym czasie przeprowadzali operacje sortowania. W trakcie okrelania iloci pamici dla parametru work_mem zwykle bierze si pod uwag ilo wolnej pamici RAM po alokacji shared_buffers (ta sama wielko bufora systemu operacyjnego obliczana na potrzeby parametru effective_cache_size), dzieli j przez warto max_connections, a nastpnie bierze tylko cz obliczonej wartoci. Poowa obliczonej liczby bdzie wartoci do du dla parametru work_mem. W takim przypadku w serwerze moe zabrakn pamici, jeeli kady klient bdzie przez cay czas przeprowadza po dwie operacje sortowania, ale prawdopodobiestwo wystpienia takiej sytuacji jest znikome. Obliczenia wartoci work_mem s coraz czciej stosowane w najnowszych wersjach PostgreSQL w celu oszacowania, czy struktura hash moe zosta zbudowana w pamici. Pami jest uywana take przez klienta, a nie jedynie przeznaczona dla operacji sortowania. Przedstawiono po prostu najatwiejszy sposób rozwizywania problemów dotyczcych rodzajów alokacji pamici. Podobnie jak synchronous_commit, parametr work_mem moe by równie ustawiany na poziomie klienta. W ten sposób warto domyln mona zdefiniowa na rednim poziomie i zwiksza pami do sortowania dla uytkowników, którzy wykonuj zapytania generujce ogromne raporty.

random_page_cost Parametr czsto jest optymalizowany, ale jego objanienie wymaga przedstawienia wielu informacji dotyczcych planowania zapyta. Temat ten zosta omówiony w rozdziale 10. Szczególnie we wczeniejszych wersjach PostgreSQL zmniejszenie wartoci parametru random_page_cost poniej wartoci domylnej — na przykad z 4.0 na 2.0 — byo powszechnie stosowanym rozwizaniem. Celem byo zwikszenie prawdopodobiestwa, e planista zapytania wykorzysta zapytania indeksowane zamiast alternatywy w postaci skanowania sekwencyjnego. Poniewa w nowszych wersjach serwera wbudowany jest sprytniejszy planista zapytania, wspomnianej techniki nie naley stosowa. O wiele rozsdniejszym rozwizaniem jest zebranie lepszych danych statystycznych i wykorzystanie parametrów dotyczcych pamici jako podstawowych sposobów wpywania na planist zapyta.

constraint_exclusion Jeeli uywana jest baza danych PostgreSQL w wersji 8.3 lub wczeniejszej, a do partycjonowania danych zastosowano oferowan przez baz danych funkcj tabeli dziedziczenia, parametr constraint_exclusion musi by wczony. Powody takiego stanu rzeczy wyjaniono w rozdziale 15.

161


Wysoko wydajny PostgreSQL 9.0

Poczwszy od wersji 8.4, wartoci domyln parametru constraint_exclusion jest nowe, sprytniejsze ustawienie o nazwie partition, które w wikszoci przypadków sprawdza si doskonale i nie musi by modyfikowane.

Optymalizacje niezalecane W pliku konfiguracyjnym postgresql.conf znajduje si kilka parametrów, dla których w innych poradnikach przedstawiono kiepskie wskazówki lub w serwerze administrowanym przez czytelnika maj ustawione nieprawidowe wartoci. Inne maj nazwy sugerujce uycie wraz z parametrami, które w rzeczywistoci nie istniej. W tym punkcie opisano najczciej spotykane opcje, których optymalizacja jest niezalecana.

fsync Jeeli czytelnik chce zignorowa proces naprawy po wystpieniu awarii, moe to zrobi poprzez wyczenie parametru fsync. W ten sposób warto parametru wal_sync_method nie bdzie miaa znaczenia, poniewa serwer i tak nie wykona adnych wywoa sync mechanizmu WAL. Trzeba w tym miejscu zda sobie spraw, e w przypadku wystpienia jakiejkolwiek awarii przy wyczonym parametrze fsync baza danych prawdopodobnie bdzie uszkodzona i uruchomienie serwera stanie si niemoliwe. Wprawdzie to okropna sytuacja, ale zwikszenie wydajnoci w wyniku wyczenia procesu naprawy po awarii jest tak ogromne, e czytelnik moe natkn si na sugestie wyczenia parametru fsync. Równie nieufnie naley traktowa inne rady pochodzce z tych samych róde, które sugeruj wyczenie parametru fsync, poniewa wyczenie tego parametru jest szalenie niebezpieczne. Jedynym powodem, dla którego taki pomys zyska zwolenników we wczeniejszych wersjach PostgreSQL, by brak innego sposobu na zmniejszenie liczby wywoa fsync — to taki kompromis: nieco wiksza wydajno kosztem mniejszej niezawodnoci. Od wersji 8.3 uytkownicy, zamiast wycza parametr fsync, zrobi lepiej, wyczajc parametr synchronous_commit. Istnieje jedna sytuacja, gdy uycie parametru fsync=off nadal ma sens — to pocztkowe operacje typu bulk-loading. Jeeli do bazy wstawiane s ogromne iloci danych, a sprzt nie jest wyposaony w bateryjnie podtrzymywany bufor zapisu, taka operacja wstawiania danych bdzie trwaa zdecydowanie za dugo, aby uzna j za praktyczn. W takim przypadku wyczenie parametru fsync podczas przeprowadzania operacji wstawiania danych — w przypadku awarii serwera wszystkie dane i tak mona atwo odtworzy — moe by jedynym sposobem przypieszenia caej operacji. Po zakoczeniu procesu wstawiania naley z powrotem wczy parametr fsync. W niektórych systemach parametr fsync jest wyczany w serwerach posiadajcych redundancyjn kopi bazy danych — na przykad w systemach zapasowych uywanych do generowania raportów. Jeeli w takim przypadku dane zostan uszkodzone, zawsze mona przeprowadzi ponown synchronizacj z gównym systemem.

162


Rozdzia 6. • Optymalizacja konfiguracji serwera

full_page_writes Podobnie jak przy fsync, wyczenie parametru full_page_writes zwiksza wydajno za cen wikszego ryzyka uszkodzenia bazy danych. Przed wyczeniem tego parametru naley bardzo dokadnie i ostronie przeanalizowa moliwoci systemu plików oraz uywanego sprztu, aby mie gwarancj, e nie dojdzie do czciowego zapisu stron.

commit_delay i commit_siblings Przed implementacj synchronous_commit podejmowane byy próby dodania tego rodzaju funkcji za pomoc parametrów commit_delay i commit_siblings. W wikszoci przypadków nie s to parametry efektywne do optymalizacji. Uzyskanie realnego przypieszenia poprzez dostosowanie wartoci tych parametrów jest niezwykle trudne, za to bardzo atwo mona doprowadzi do spowolnienia wykonywania kadej transakcji. Jedyny przypadek, kiedy opisywane parametry mog okaza si przydatne, dotyczy systemów o ogromnej iloci operacji wejcia-wyjcia. Ustawienie bardzo maej wartoci opó nienia moe spowodowa przeprowadzanie operacji zapisu w wikszych blokach, co czasami w poczeniu z wiksz wartoci jednostki macierzy RAID okazuje si lepszym rozwizaniem.

max_prepared_transactions Wielu uytkowników po spojrzeniu na nazw tego parametru bdzie przekonanych, e dotyczy transakcji skadowanych, czyli techniki powszechnie stosowanej w celu uniknicia wstawiania zoliwego kodu SQL, i odczuje potrzeb zwikszenia wartoci tego parametru. To jednak bdne zaoenie, omawiany parametr i transakcje skadowane nie s ze sob powizane. Transakcja skadowana to taka, która uywa polecenia PREPARE TRANSACTION w celu uycia dwuetapowego zatwierdzenia (ang. two-phase commit, 2PC). Jeeli czytelnik nie uywa tego polecenia oraz techniki 2PC, moe pozostawi dla tego parametru warto domyln. Natomiast w przypadku uywania funkcji dwuetapowego zatwierdzania konieczno zwikszenia wartoci parametru max_prepared_transaction wystpi prawdopodobnie tylko wtedy, kiedy trzeba bdzie dopasowa j do liczby pocze.

Zapytania wczajce parametry Istnieje moliwo wyczenia wielu technik stosowanych przez planist zapytania, co ma na celu uniknicie uycia niewaciwego typu zapytania. Czasami jest to stosowane jako rodzaj obejcia problemu polegajcego na tym, e PostgreSQL nie obsuguje bezporednich podpowiedzi optymalizatora dotyczcych sposobu wykonania zapytania. Czytelnik móg si spotka z przedstawionym poniej wierszem kodu jako sugerowanym sposobem wymuszenia uycia indeksów zamiast skanowania sekwencyjnego: enable_seqscan = off

Ogólnie rzecz ujmujc, to za praktyka. Zamiast niej, aby podejmowa lepsze decyzje, naley dy do poprawienia informacji przekazywanych optymalizatorowi zapyta. Temat zosta omówiony w rozdziale 10.

163


Wysoko wydajny PostgreSQL 9.0

Optymalizacja ustawie nowego serwera Istnieje kilka sposób poczenia wszystkich przedstawionych dotd informacji w jeden proces optymalizacji ustawie nowego serwera. Wybór najlepszego sposobu zaley od oczekiwa stawianych serwerowi, a take od samego uytkownika — czy chce przeprowadzi samodzieln optymalizacj, czy bdzie stosowa zalecane tutaj wartoci parametrów.

Wskazówki dotyczce serwerów dedykowanych Pocztkow optymalizacj serwera mona sprowadzi do cakiem mechanicznego procesu. Oto on. 1. Dostosowanie rejestracji zdarze w taki sposób, aby dostarczaa wikszej iloci informacji. 2. Ustalenie wielkoci parametru shared_buffers. Naley rozpocz od wartoci równej 25% pamici systemowej. Jeeli czytelnik uywa najnowszych wersji PostgreSQL obsugujcych rozpraszanie punktów kontrolnych i wie, e dane obcienie serwera odniesie korzyci po przydzieleniu buforowi wikszej iloci pamici, moe spróbowa zwikszania wartoci shared_buffers. W przypadku platformy, na której parametr ten nie jest tak uyteczny, jego warto naley odpowiednio dopasowa lub nawet zmniejszy. 3. Rozsdne oszacowanie maksymalnej liczby pocze. Jest to ograniczenie bezwzgldne. Po osigniciu ustalonej liczby pocze próby nawizania poczenia przez nowych klientów bd odrzucane. 4. Uruchomienie serwera z tymi parametrami pocztkowymi. Nastpnie trzeba sprawdzi ilo pamici pozostaej dla bufora systemu plików. 5. Kolejny krok to okrelenie wielkoci parametru effective_cache_size na podstawie wielkoci parametru shared_buffers i bufora systemu operacyjnego. 6. Podzielenie wielkoci bufora systemu operacyjnego przez warto max_connections, a pó niej jeszcze przez dwa. W ten sposób czytelnik otrzymuje rozsdn warto dla parametru work_mem. Jeeli aplikacja w aden sposób nie jest uzaleniona od wydajnoci operacji sortowania, odpowiednie bdzie ustawienie znacznie niszej wartoci parametru work_mem. 7. Ustawienie dla parametru maintenance_work_mem wartoci okoo 50 MB na kady gigabajt pamici RAM. 8. Zwikszenie wartoci parametru checkpoint_segments do przynajmniej 10. Jeeli czytelnik posiada sprzt klasy serwerowej z bateryjnie podtrzymywanym buforem zapisu, warto 32 dla parametru checkpoint_segments bdzie znacznie lepsz wartoci domyln.

164


Rozdzia 6. • Optymalizacja konfiguracji serwera

9. Zmiana wartoci domylnej parametru wal_sync_method. Jeeli uywana jest platforma, na której warto domylna tego parametru jest niebezpieczna, naley zmieni t warto. 10. Warto parametru wal_buffers trzeba zwikszy do 16 MB. 11. Dla baz danych PostgreSQL w wersjach niszych ni 8.4 warto rozway zwikszenie wartoci parametrów default_statistics_target (do 100, warto domylna w nowszych wersjach PostgreSQL) i max_fsm_pages na podstawie informacji o przewidywanym obcieniu dla tej bazy danych. Po skonfigurowaniu pewnej liczby serwerów przeznaczonych do obsugi danej aplikacji czytelnik bdzie mia znacznie lepsze rozeznanie, które wartoci pocztkowe maj sens, aby rozpoczyna z nimi prac. Szczególnie wartoci kocowe parametrów checkpoint_segments i work_mem mog bardzo istotnie odbiega od tutaj zalecanych.

Wskazówki dotyczce serwerów wspódzielonych Jeeli serwer bazy danych wspódzieli sprzt z inn aplikacj — czsto spotykana jest sytuacja umieszczania wielu aplikacji bazodanowych w pojedynczym systemie — podczas optymalizacji nie mona stosowa tak agresywnego podejcia, jakie przedstawiono w poprzednim podrozdziale. W takim przypadku dokadna procedura jest trudna do nakrelenia. Naley podj prób przeprowadzenia optymalizacji wartoci parametrów zwizanych z pamici i zastosowa dolne granice zalecanych wartoci: Q parametrowi shared_buffers naley przydzieli tylko 10% pamici RAM, nawet na platformach, na których normalnie zaleca si przydzielenie wikszej wartoci; Q parametrowi effective_cache_size naley przydzieli 50% lub mniej pamici RAM, prawdopodobnie mniej, jeli wiadomo, e aplikacja bdzie uywa duej iloci pamici; Q trzeba bardzo ostronie podchodzi do zwikszania wartoci parametru work_mem. Inne sugestie przedstawione w poprzednim podrozdziale maj zastosowanie równie tutaj — na przykad uycie wikszych wartoci dla parametru checkpoint_segments i odpowiedni wybór wartoci parametru wal_sync_method nie róni si niczym w obu systemach. Nastpnie trzeba zasymulowa dziaanie aplikacji z penym obcieniem i sprawdzi ilo dostpnej pamici RAM, aby si przekona, czy moliwe jest przydzielenie bazie danych wikszej iloci pamici. Proces moe wymaga kilkakrotnego powtórzenia i na pewno powinien by powizany z przeprowadzaniem testów wydajnoci na poziomie aplikacji, o ile jest taka moliwo. W systemie wspódzielonym nie ma sensu przydzielanie bazie danych wikszej iloci pamici, jeeli aplikacja bd inna warstwa buforujca, na przykad na poziomie puli pocze, nie bdzie efektywnie wykorzystywaa tej pamici. Ta sama idea — uycie rozsdnych wartoci pocztkowych, a nastpnie stopniowe przeprowadzanie optymalizacji na podstawie monitorowania — sprawdza si doskonale take w serwerach dedykowanych.

165


Wysoko wydajny PostgreSQL 9.0

pgtune Od PostgreSQL w wersji 8.4 narzdzie pgtune dostpne na stronie http://pgfoundry.org/projects/ pgtune/ moe by uyte do utworzenia pocztkowego pliku konfiguracyjnego postgresql.conf dla nowego serwera. Narzdzie pozwala uytkownikowi na zasugerowanie przewidywanego rodzaju obcienia bazy danych z zakresu od stacji roboczej programisty a do dedykowanego serwera magazynu danych. Na podstawie tych danych wejciowych oraz parametrów, takich jak ilo pamici RAM zainstalowana w serwerze, narzdzie generuje plik konfiguracyjny wstpnie zoptymalizowany dla najwaniejszych parametrów systemowych, stosuje przy tym metody podobne do omówionych w rozdziale. Uzyskany wynik nie bdzie tak dobry jak zastosowanie wskazówek przedstawionych dla serwera dedykowanego i samodzielne przeprowadzanie pomiarów, ale pozwoli na szybkie rozpoczcie pracy z ogólnie dobr konfiguracj. Kady rozsdnie zmodyfikowany plik konfiguracyjny postgresql.conf bdzie znacznie lepszy od domylnego, który dostrojony jest jedynie pod ktem alokacji jak najmniejszej iloci pamici wspódzielonej.

Podsumowanie W konfiguracji bazy danych PostgreSQL istnieje niemal 200 wartoci, które mona zmodyfikowa; poprawne ustawienie w aplikacji wszystkich moe by cakiem duym wyzwaniem. Wskazówki przedstawione w rozdziale powinny pomóc czytelnikowi w rozpoczciu procesu optymalizacji konfiguracji i unikniciu najczciej spotykanych puapek. Gdy uytkownik napotka problemy, powinny te pokaza, które ustawienia s cenniejsze. Q Wartoci domylne w pliku konfiguracyjnym serwera powoduj zapisywanie

w dzienniku zdarze niewielu informacji i charakteryzuj si wyjtkowo skpymi ustawieniami pamici. W kadym serwerze naley przynamniej przeprowadzi podstawow optymalizacj w celu rozwizania najgorszych problemów. Q Ustawienia parametrów zwizanych z pamici, czyli przede wszystkim shared_buffers i work_mem, powinny by przeprowadzane bardzo ostronie, aby nie doprowadzi do sytuacji, w której systemowi zabraknie pamici. Q W celu przygotowania waciwego planu wykonania zapytania planista zapytania musi

mie prawidowe informacje o pamici oraz dobre dane statystyczne dotyczce tabeli. Q Demon autovacuum ma znaczenie krytyczne dla zapewnienia planicie zapytania odpowiednich informacji. Ponadto demon autovacuum zapewnia tabelom uruchamianie

waciwych procesów konserwacyjnych. Q W wielu przypadkach wprowadzenie zmiany konfiguracyjnej nie wymaga

ponownego uruchomienia serwera, a wiele parametrów mona nawet modyfikowa dla poszczególnych klientów, zapewniajc w ten sposób naprawd dokadn optymalizacj.

166


Skorowidz $PGDATA, 124, 143 2warm, 383 3ware, 45

A ACID, 49 Adaptive Replacement Cache, 105 AFTER, 425 AFTER DELETE ON, 377 AFTER UPDATE ON, 377 Aggregate, 271 agregacja WindowAgg, 274 agresywne uaktualnienia PostgreSQL, 430 aktywno bufora bazy danych, 335 aktywno tworzenia punktu kontrolnego, 335 algorytm clock-sweep, 133 algorytm szybkiego sortowania, 269 alloc_per_second, 339 alokacja pamici wspódzielonej, 119 ALTER TABLE, 189, 425, 435, 440 ALTER TABLE ADD FOREIGN KEY, 417 ALTER TABLE SET STATISTICS, 154 ALTER TABLESPACE, 437 AMD, 36, 57 analiza dzienników zdarze, 203 analiza opó nienia, 219 analiza planu zapytania, 264 analiza pliku dziennika zdarze, 200 analiza zawartoci bufora bazy danych, 136 ANALYZE, 152, 154, 232, 259, 290, 291, 407, 421 cele danych statystycznych, 293 dostosowanie wartoci celu dla poszczególnych kolumn, 294

obszary trudne do oszacowania, 295 róne wartoci, 294 AND, 409 Anti Join, 286 Anticipatory Scheduling, 100 aplikacje PostgreSQL, 31 Append, 275 application_name, 438 ARC, 105 architektura SN, 410 archive_cleanup_command, 436 archive_command, 383, 419 archive_mode, 433 archive_timeout, 383 Areca, 45 array_to_string(), 291 as, 100 ATA, 37 ataki DoS, 148 SQL Injection, 122, 423 atime, 97 auto_explain, 199, 200, 435, 439 auto_explain.log_min_duration, 200 automatyczna analiza, 190 autovacuum, 121, 152, 153, 175, 179, 180, 181, 182, 186, 187, 232, 417, 432, 435 bdy spowodowane brakiem pamici, 187 dugo wykonywane transakcje, 188 monitorowanie procesu, 182 obciony serwer, 187 opcje dla poszczególnych tabel, 184 problemy, 185 rejestrowanie zdarze, 182


Wysoko wydajny PostgreSQL 9.0

autovacuum uruchamianie procesu, 183 wczanie demona w starszych wersjach, 153 autovacuum_cost_limit, 187 autovacuum_freeze_max_age, 175 autovacuum_max_workers, 121, 153, 186, 187 autovacuum_naptime, 186 autovacuum_vacuum_cost_delay, 180, 187 autovacuum_vacuum_cost_limit, 180 autovacuum_vacuum_scale_factor, 183 autovacuum_vacuum_threshold, 183 AVG(), 271

B backend, 145 bariery zapisu, 94 obsuga przez napdy, 94 obsuga przez systemy plików, 95 base, 110 Battery-Backed Write Cache, 50 baza danych, 26 Dell Store 2, 254 Pagila, 254 BBC, 50 BBWC, 50, 53 BEGIN, 169, 326, 416, 418 Berkley Fast File System, 102 bezporednio podczona pami masowa, 46 Binary Tree, 191 blktrace, 349 block_size, 121, 336 blockdev, 97 blok indeksu, 230 blokady, 325 informacje, 327 oczekiwanie na blokad tabeli, 331 oczekiwanie na blokad transakcji, 330 rejestrowanie informacji o blokadach, 332 zakleszczenia, 332 bloki bazy danych, 131 sposoby zapisu zmodyfikowanych bloków, 132 bloki LRU, 132 blokowanie rekordów, 171 bonnie++, 66, 70, 90

444

bonnie++ 2.0, 72 bonnie++ ZCAV, 73 boot_val, 144 B-tree, 191, 245 Btrfs, 93 Bucardo, 388 buffers_backend, 132 buffers_checkpoint, 132, 340 buffers_clean, 132 bufor ARC, 105 bufor bazy danych, 117, 122, 132, 335 analiza zawartoci, 136 dostosowanie wielkoci bufora, 141 generowanie podsumowania, 138 jednostki pamici, 118 konfiguracja ukadu dysków, 124 licznik uycia tabel, 138 naprawa bazy danych po awarii, 128 natenie operacji dyskowych, 135 ograniczenia, 135 ogromne systemy, 136 pami wspódzielona w systemie Unix, 119 pg_buffercache, 123 pocztkowe wskazówki dotyczce wielkoci, 135 podsumowanie zawartoci bufora z uyciem danych procentowych, 139 podwójne buforowanie, 134 przecienie punktu kontrolnego, 134 przegld wielkoci bufora, 141 przegld zawartoci bufora, 137 relacje, 138 rozproszenie uycia bufora, 140 serwer wspódzielony, 136 tworzenie bloku w bazie danych, 126 wczesne wersje, 135 Windows, 135 zapis zmodyfikowanych bloków na dysku, 127 bufor bez wstrzymywania zapisu, 49 wydajno, 52 bufor systemu operacyjnego, 132, 134 bufor z opó nionym zapisem, 49, 50 bufor zapisu, 49, 98 wyczanie, 52


Skorowidz

buforowanie bazy danych, 376 memcached, 376 pgmemcache, 377 buforowanie odczytu, 98 bulk-loading, 415 czyszczenie po operacji wczytania danych, 420 dodawanie ogranicze, 419 metody wczytywania danych, 416 optymalizacja operacji, 417 pominicie optymalizacji mechanizmu WAL, 418 ponowne tworzenie indeksów, 419 przywracanie równolege, 419

C Cacti, 366 PostgreSQL, 366 Windows, 366 Cassandra, 26 cele danych statystycznych, 293 dostosowanie wartoci celu dla poszczególnych kolumn, 294 róne wartoci, 294 cfq, 100, 101 cfs, 224 CHECK, 425 check_postgres, 193, 194, 365 CHECKPOINT, 129 checkpoint_completion_target, 130, 155, 156, 432 checkpoint_segments, 129, 130, 147, 155, 164, 340, 417 checkpoint_timeout, 129, 156, 339, 417 checkpoints_req, 129 chkdsk, 87 clock-sweep, 133 CLUSTER, 125, 185, 189, 192, 239, 243, 433, 440 COMMIT, 52, 64, 65, 75, 416 commit_delay, 163 commit_siblings, 163 Common-Table Expression, 280, 434 Completely Fair Queuing, 100 Completely Fair Scheduler, 224 constraint_exclusion, 161, 298, 403, 407, 434

context, 145 contrib, 27, 125, 199, 201 COPY, 96, 416, 417 CouchDB, 26 COUNT(), 271, 421 CPU governor, 61 cpu_index_tuple_cost, 260, 300 cpu_operator_cost, 260 cpu_tuple_cost, 260 cpuinfo, 61 CREATE DATABASE, 109 CREATE INDEX, 154, 235, 248, 417 CREATE INDEX CONCURRENTLY, 189, 243 CREATE OR REPLACE FUNCTION, 397, 398 CREATE RULE, 399 CREATE TABLE, 435 CREATE TABLE...WITH OIDS, 265 CREATE TEMPORARY TABLE, 111 CREATE TRIGGER, 397 CREATE UNIQUE INDEX, 249 CSV, 197 CTE, 280, 434 ctid, 265 CURRENT ROWS, 437 CURRENT_DATE(), 407 current_setting, 336 current_timestamp(), 325 cursor_tuple_fraction, 298 cust_hist, 287 custom_variable_classes, 200 cykl ycia aplikacji PostgreSQL, 31 cykl ycia bloku bazy danych, 131 cykl ycia widocznoci rekordu, 168 czas dostpu do plików, 97 czas wyszukiwania, 76 czstotliwo kreowania punktów kontrolnych, 129 czyszczenie bufora, 257 czyszczenie po operacji wczytania danych, 420

D dane statystyczne, 152, 290, 315 cele danych statystycznych, 293 dane dotyczce caej bazy danych, 324

445


Wysoko wydajny PostgreSQL 9.0

dane statystyczne dane dotyczce indeksu, 322 dane dotyczce tabel, 230, 318 histogram, 291 pg_stats, 290 przegldanie, 290 szacowanie, 290 widoki, 315 zakres sprawdzanych danych, 291 DAS, 46 data_directory, 124 Database Connection Pool, 375 DBCP, 375 dbt, 227 dd, 69 DDF, 44 DDL, 151 DDR SDRAM, 57 deadline, 100, 101 deadlock_timeout, 332, 333 debugger PL/pgSQL, 424 default_statistics_target, 154, 165, 293, 294, 434 DEFERRABLE, 425, 438 dekodowanie informacji o blokadzie, 327 DELETE, 172, 176, 298, 299, 400 Dell Store 2, 254 demon autovacuum, 152, 181 Denial Of Service, 148 Direct Attached Storage, 46 Direct Memory Access, 43 dirty_background_ratio, 99 dirty_ratio, 99 DISCARD ALL, 372 Disk Data Format, 44 DISTINCT, 272, 273 DMA, 43 dmesg, 95 DoS, 148 dostp sekwencyjny, 63 dostrajanie systemów plików, 96 dowizania symboliczne, 108 DROP INDEX, 241 DROP TABLE, 169, 384 drop_caches, 258 drzewo katalogów bazy danych, 109

446

DTrace, 32, 428, 435 DTrace in FreeBSD, 429 dual-channel, 60 dynamiczne wywoywanie funkcji, 398 dyski twarde, 37 bariery zapisu, 94 bonnie++, 70 dd, 69 dostp sekwencyjny, 63 hdtune, 65 IOPS, 68 konfiguracja, 85 liczba operacji wejcia-wyjcia na sekund, 61 liczba wykonywanych operacji zatwierdzania, 64 macierz RAID, 38 maksymalna wielko systemu plików, 85 narzdzia do testowania wydajnoci, 65 NCQ, 95 nieprzewidywalna wydajno w Windows, 69 niezawodno, 41 obsuga bdów, 40 oczekiwana wydajno dysku, 80 odczytywanie bloków danych, 69 oprogramowanie firmware, 42 optymalizacja pojemnoci, 63 powody niskiej wydajnoci, 81 Random Access, 68 schemat partycjonowania, 86 short stroking, 63 spindle, 62 SSD, 42 swobodny dostp, 61 redni czas dostpu, 62 test_fsync, 64 testy typu short stroking, 67 testy wydajnoci, 61, 77 wyniki testu wydajnoci, 78 zapisywanie bloków danych, 69 ZCAV, 63 dziennik zapisu z wyprzedzeniem, 128 dziennik zatwierdze, 133 dzienniki zdarze zapyta, 194


Skorowidz

E effective_cache_size, 159, 161, 164, 165, 283, 295, 296 effective_io_concurrency, 434 EFI, 86 elevator, 100 emulacja DTrace, 429 enable_bitmapscan, 303 enable_hashagg, 303 enable_hashjoin, 303, 305 enable_indexscan, 303 enable_material, 303 enable_mergejoin, 303 enable_nestloop, 303 enable_seqscan, 163, 303, 305 enable_sort, 303 enable_tidscan, 303 EPQA, 205 eSATA, 41 EVERY(), 271 EXCEPT, 278 EXCEPT ALL, 278 exclusion constraints, 439 EXISTS, 286, 300 EXPLAIN, 152, 200, 231, 241, 256, 259, 436 czyszczenie bufora, 257 dane wyjciowe, 437 dane wyjciowe w postaci czytelnej dla komputera, 263 graficzne przedstawienie danych, 262 narzdzia analizy danych, 262, 264 obcienie zwizane z pomiarem, 256 rozbudowane dane wyjciowe, 263 rozgrzany bufor, 257 struktura wz贸w planu zapytania, 259 zimny bufor, 257 EXPLAIN ANALYZE, 230, 236, 256, 257 EXPLAIN BUFFERS, 436 EXPLAIN VERBOSE, 263, 435 ext2, 88 ext3, 89, 341 journal, 90 ordered, 89, 90 poziomy ksigowania, 89 writeback, 89, 90

ext4, 91, 341 ext4 Howto, 91 Extensible Firmware Interface, 86 external merge sort, 269 external SATA, 41 EXTRACT, 280 Extreme Memory Profile, 60

F faszywa macierz RAID, 46 FAT32, 87, 107 fdatasync, 50 Fiber Channel, 45 filler, 225 fillfactor, 244 FILLFACTOR, 432 find, 28 fio, 78 Firewire, 41 fizyczna wydajno dysku, 61 FLUSH CACHE, 95 FOLLOWING, 437 Force Unit Access, 95 forcedirectio, 103 format CSV dziennik贸w zdarze, 197, 198 Free Space Map, 150, 188 freebehind, 103 FreeBSD, 102, 104 from_collapse_limit, 288 FrozenXID, 175 fsck, 87, 88 FSM, 150, 194 wyczerpanie mapy, 188 fstab, 91 fsync, 50, 77, 95, 114, 162, 418 fsync_writethrough, 107 FTS, 250 FUA, 95 full_page_writes, 128, 163, 210 Full-Text Search, 250 funkcje, 397 funkcje agregujce, 271 funkcje Window, 311, 437

447


Wysoko wydajny PostgreSQL 9.0

G Generalized Inverted Index, 246 Generalized Search Tree, 247 generate_series(), 59, 310 generowanie wartoci hash, 408 Genetic Query Optimizer, 289, 437 genetyczny optymalizator zapyta, 289 GEQO, 289, 437 geqo_threshold, 289 getconf, 119 GIN, 246 GiST, 247 global, 110 Golconde, 390 gprof, 32, 427 GPT, 86 GridSQL, 411 GROUP BY, 272, 276 Gruop, 276 GUID, 108 GUID Partition Table, 86

H harmonogram operacji wejcia-wyjcia, 100 Hash Join, 285, 286, 300, 302, 304 Hash Semi Join, 277, 286 HashAggregate, 272 HashSetOp, 278 hashtext(), 408, 409 hdparm, 52 hdtune, 65, 68 Heap Only Tuples, 178, 432 heap_blks_hit, 233 HighPoint, 46 HOT, 173, 178, 319, 432 hot spare, 112 Hot Standby, 374, 381, 436 optymalizacja funkcji, 384 Hot Swap, 388 hstore, 250, 439 htop, 357 Hyperic HQ, 368

448

I identyfikator krotki, 265 identyfikator obiektu, 125, 265 idx_blks_hit, 233 idx_tup_fetch, 322 idx_tup_read, 322 ilo miejsca na dysku, 333 implementacja procesu vacuum, 177 IN, 277 indeks, 229, 230, 419 dane statystyczne, 322 fillfactor, 244 indeks bazujcy na wyraeniu, 249 indeks czciowy, 249 indeks dla operacji sortowania, 248 indeks GIN, 246 indeks GiST, 247 indeks hash, 246 indeks wielokolumnowy, 248 klastrowanie, 243 czenie indeks贸w, 237 naprawa, 243 operacje wejcia-wyjcia, 323 sposoby korzystania z indeks贸w, 247 tworzenie, 235, 241 tworzenie wsp贸biene, 243 unikalno indeksu, 242 indeks B-tree, 37, 191, 245 klasy operatora tekstowego, 245 indeksowanie bazy danych, 229 blok indeksu, 230 FTS, 250 klastry, 239, 243 klucz podstawowy, 233 liczniki bufora, 241 pene skanowanie tabeli, 234 indeksowanie bazy danych, 229 planowanie zmiany planu, 238 ponowne indeksowanie, 244 rodzaje indeks贸w, 245 skanowanie indeksowane, 238 skanowanie sekwencyjne, 238 sposoby indeksowania, 230 wielko zapytania na dysku, 230


Skorowidz

wyszukiwanie, 233 wyszukiwanie penego tekstu, 250 wyszukiwanie za pomoc nieefektywnego indeksu, 235 informacje o blokadach, 327, 332 informowanie o wystpieniu problemu, 363 initdb, 109, 119 INITIALLY DEFERRED, 425 INITIALLY IMMEDIATE, 425 INNER JOIN, 289 Input/Output Per Second, 61 INSERT, 64, 298, 397, 400 instalacja moduu contrib z kodu r贸dowego, 28 instalacja pg_buffercache, 123 Intel, 36, 57 internal, 145 INTERSECT, 278 INTERSECT ALL, 278 INVALID, 243 IOPS, 61, 68 iostat, 32, 69, 346, 347, 349, 354 przykady dobrej wydajnoci, 349 przykady przecionego systemu, 352 iotop, 349 iozone, 78 ipcs, 120 IS NOT NULL, 437

J Java, 375 JBOD, 53 JBoss, 375 JDBC, 375, 411 jednostka FUA, 95 jednostka pamici, 118 jednostka pamici masowej, 109 jzyk PL/pgSQL, 424, 438 JFS, 93 JOIN, 287 join_collapse_limit, 287 JSON, 263 Just a Bunch of Disks, 53

K katalogi bazy danych, 109 kernel.sem, 120 kill, 146 klastrowanie indeksu, 243 fillfactor, 244 klastry, 239 klucz podstawowy, 233, 242 klucze zewntrzne, 424 klustsize, 103 kamstwa dysku twardego, 49 kolejno zcze, 287 kolekcjoner danych statystycznych, 426 konfiguracja dysk贸w twardych, 48, 85 konfiguracja przekazywania danych mechanizmu WAL, 383 konfiguracja rejestracji zdarze, 194 log_line_prefix, 195 rejestrowanie CSV, 197 rejestrowanie trudnych zapyta, 199 syslog, 197 zapytania obejmujce wiele wierszy, 196 zbi贸r dziennik贸w zdarze, 195 konfiguracja serwera, 143 autovacuum, 152 checkpoint_completion_target, 156 checkpoint_segments, 155 checkpoint_timeout, 156 commit_delay, 163 commit_siblings, 163 constraint_exclusion, 161 default_statistics_target, 154 effective_cache_size, 159 enable_seqscan, 163 fsync, 162 full_page_writes, 163 interakcja z uywan konfiguracj, 144 kontekst do przeprowadzania zmian, 144 listen_addresses, 148 log_line_prefix, 150 log_min_duration_statement, 152 log_statement, 151 maintenance_work_mem, 153

449


Wysoko wydajny PostgreSQL 9.0

konfiguracja serwera max_connections, 148 max_prepared_transactions, 163 optymalizacja ustawie nowego serwera, 164 optymalizacje niezalecane, 162 pami wspódzielona, 149 pgtune, 166 poczenia z baz danych, 147 ponowne wczytywanie pliku konfiguracyjnego, 146 punkty kontrolne, 155 random_page_cost, 161 rejestrowanie zdarze, 150 shared_buffers, 149 synchronous_commit, 160 umieszczanie ustawie w komentarzach, 146 ustawienia domylne, 144 ustawienia na poziomie klienta, 159 ustawienia na poziomie serwera, 147 WAL, 156 wal_buffers, 156 wal_sync_method, 157 work_mem, 160 wskazówki dotyczce serwerów dedykowanych, 164 wskazówki dotyczce serwerów wspódzielonych, 165 zapytania wczajce parametry, 163 zerowanie ustawie, 144 konfiguracja ukadu dysków, 124 konflikty podczas blokowania rekordów, 171 konserwacja, 167 kontekst do przeprowadzania zmian, 144 kontrola wspóbienoci, 167 kontrolery dysków, 43, 45 monitorowanie, 51 niezawodno, 48 konwersja podzapytania, 277 kopia zapasowa, 382 koszt odczytu, 260 koszt przetworzenia pojedynczego wpisu w indeksie, 260 koszt przetworzenia prostego operatora lub funkcji, 260

450

koszty oszacowane, 262 koszty rzeczywiste, 262 kSar, 359 ksigowanie, 87, 89

L Least Recently Used, 132 LEFT JOIN, 288, 289 libevent, 375 liczba obsugiwanych pocze, 149 liczba operacji wejcia-wyjcia na sekund, 61 liczba wykonywanych operacji zatwierdzania, 64 fsync, 77 liczba operacji zatwierdzania w Windows, 65 liczba wykonywanych operacji INSERT, 64 test_fsync, 64 liczniki bufora, 241 liczniki puli pocze, 372 liczniki uycia tabel, 138 LIKE, 245 Limit, 270 LIMIT, 249, 270, 435 Linux, 88 Linux Software RAID, 44 Linux SystemTap, 429 LISTEN/NOTIFY, 438 listen_addresses, 148 listy IN, 277 locate, 28, 114 log_autovacuum_min_duration, 181, 182 log_checkpoints, 130, 341 log_destination, 150, 194, 197, 198 log_directory, 150, 194, 195 log_duration, 199 log_filename, 150, 194, 195 log_line_prefix, 150, 194, 195, 203, 205, 439 log_lock_waits, 332 log_min_duration_statement, 152, 199, 203 log_min_messages, 182 log_statement, 151, 199 log_temp_files, 111, 269, 297, 439 logging_collector, 194, 195, 198, 203


Skorowidz

Londiste, 387 LRU, 132 LSI MegaRAID, 45 LVM, 82, 95

czenie indeksów, 237, 267 czenie zbiorów rekordów, 265 identyfikator krotki, 265 identyfikator obiektu, 265 mapa bitowa skanowania indeksu, 267 skanowanie indeksu, 266, 267 skanowanie sekwencyjne, 266

M macierz RAID, 38, 112 DDF, 44 faszywa macierz RAID, 46 JBOD, 53 konfiguracja dysków, 112 powody niskiej wydajnoci, 81 programowa macierz RAID, 44 sprztowa macierz RAID, 44 wskazówki dotyczce konfiguracji dysków, 114 maintenance_work_mem, 153, 154, 164, 186, 187, 417 maksymalna wielko systemu plików, 85 Mammoth Replicator, 390 Management Information Base, 369 mapa bitowa skanowania indeksu, 267, 268 mapowanie sposobu widzenia fizycznych dysków przez system, 82 Master Boot Record, 86 materializacja, 279 materializacja zczenia Merge Join, 284 Materialize, 437 MAX(), 271, 431 max_connections, 121, 148, 324 max_fsm_pages, 150, 153, 165, 181, 189, 434 max_fsm_relations, 150, 189, 434 max_locks_per_transaction, 121 max_prepared_transactions, 121, 163 max_standby_archive_delay, 385

max_standby_streaming_delay, 385 maxphys, 103 MBR, 86 MCV, 286 mechanizm kontroli wspóbienoci, 167 mechanizm WAL, 382 MegaRAID, 45 memcached, 376 memtest86+, 56 Meneder zada, 360 menedery kolejki replikacji, 386 Merge Join, 280, 283, 304 materializacja zczenia, 284 metadane systemu plików, 86 metody replikacji, 391 metody wczytywania danych, 416 mikkie dowizania symboliczne, 109 migracja partycjonowanej uywanej tabeli, 401 MIN(), 271, 431 mirroring, 39 mk-query-digest, 206 model MVCC, 325 model wykonania zstpujcego, 270 moduy contrib, 27 instalacja z kodu ródowego, 28 pg_buffercache, 29 uywanie moduu, 29 wyszukiwanie moduów, 28 modyfikacja parametrów bazy danych, 144 MongoDB, 26 Monitor systemu Windows, 360 liczniki, 361 zapisywanie danych, 362 monitorowanie, 343, 439 baza danych, 315 dane, 193 dzienniki zdarze zapyta, 194 kontroler dyskowy, 51 monitorowanie pod ktem przerwania usug, 363 poziom wykorzystania pamici, 358 proces demona autovacuum, 182 strony indeksu, 193 Most Common Values, 286 MRTG, 364 Multi Router Traffic Grapher, 364

451


Wysoko wydajny PostgreSQL 9.0

Multiversion Concurrency Control, 167 Munin, 366 MVCC, 167, 325 tryb Read Committed, 174 wady mechanizmu, 174 zalety mechanizmu, 174 MySQL, 26

N n_distinct_inherited, 295 n_tup_hot_upd, 179 n_tup_upd, 179 nadmuchane indeksy, 191 pomiar nadmuchania indeksu, 191 Nagios, 193, 364 PostgreSQL, 365 rejestrowanie liczników, 364 Windows, 366 napdy SSD, 42 naprawa bazy danych po awarii, 128 dziennik zapisu z wyprzedzeniem, 128 punkty kontrolne, 128 naprawa indeksu, 243 narzdzia monitorujce system Unix, 343 system Windows, 360 narzdzia suce do analizy planu, 264 narzdzia SNMP, 369 NAS, 46 natenie operacji wejcia-wyjcia, 130 Native Command Queuing, 95 NCQ, 95 Nested Loop, 278, 280 Network Attached Storage, 46 niewyjanione operacje zapisu, 422 niezawodne kontrolery, 48 niezawodno dysku twardego, 41 No Operation, 100 noatime, 108 nodiratime, 97 noop, 100 NOT DEFERRABLE, 425 NOT EXISTS, 286 NOT NULL, 242

452

NTFS, 87, 107 dostrajanie zachowania operacji montowania systemu plików, 108 null, 242 numerowanie rekordów, 309

O Object Identification Number, 265 Object Identifier, 125 Object-Relational Mapper, 437 obsuga barier zapisu napd, 94 system plików, 95 obsuga bdów na dyskach, 40 oczekiwana wydajno dysku, 80 oczekiwanie na blokad tabeli, 331 oczekiwanie na blokad transakcji, 330 odczyt z wyprzedzeniem, 96 odporno na awarie, 383 odtworzenie serwera na podstawie plików WAL innego serwera, 382 odzyskiwanie danych po awarii systemu plików, 86 OFFSET, 271, 306, 307, 435 ograniczenia, 419 ograniczenia SQL, 309 ogromne przecienie klucza zewntrznego, 424 ogromne przecienie mechanizmu zbierajcego dane statystyczne, 426 OID, 125, 265 oid2name, 125, 126 okno, 311 okrelanie wielkoci bufora zapisu, 98 OLTP, 22, 105, 226 OmniPITR, 383 Online Transaction Processing, 22, 105 OOM, 441 operacja bulk-loading, 415 operacja czyszczenia na podstawie kosztów, 179 operacja sync, 50 operacje ustawiania, 278 operacje wejcia-wyjcia indeksu, 323


Skorowidz

operacje wejcia-wyjcia tabel, 320 operacje zapisu, 422 OProfile, 32, 428 oprogramowanie, 30 oprogramowanie firmware, 42 oprogramowanie trendów, 362, 363 optymalizacja wydajnoci, 32 Hot Standby, 384 konfiguracja serwera, 143 operacja bulk-loading, 417 optymalizacja z uyciem danych statystycznych dotyczcych zapisu w tle, 339 pojemno dysku twardego, 63 ustawienia nowego serwera, 164 optymalizacja zapyta, 253 constraint_exclusion, 298 cursor_tuple_fraction, 298 dane statystyczne, 290 DELETE, 298 effective_cache_size, 295 EXPLAIN, 256 INSERT, 298 koszty oszacowane, 262 koszty rzeczywiste, 262 czenie zbiorów rekordów, 265 obliczanie kosztu, 260 OFFSET, 306 ograniczenia SQL, 309 poprawianie zapyta, 299 poszukiwanie odpowiednika zapytania, 300 przetwarzanie wzów, 268 rozwizywanie bdów optymalizatora, 305 SELECT, 298 struktura wzów planu zapytania, 259 unikanie planu restrukturyzacji, 306 UPDATE, 298 w peni buforowane zbiory danych, 300 work_mem, 297 wyczanie funkcji optymalizatora, 301 zewntrzne róda problemów, 309 zczenia, 281 optymalizator GEQO, 289 ORDER BY, 248, 249, 268, 270 ORM, 437 overcommit, 98

P Pagila, 254 pami, 37 DDR SDRAM, 57 pami dla bufora bazy danych, 117 pami wspódzielona, 149 SPD, 60 testy wydajnoci, 55 tryb dwukanaowy, 60 XMP, 60 parametry konfiguracyjne, 143 parametry planowania zapytania, 295 partition, 434 partycje, 405 partycjonowanie danych, 393 bdy, 407 tworzenie partycji, 405 zalety partycjonowania, 406 partycjonowanie o zasigu tabeli, 393 lista partycjonowania, 395 migracja partycjonowanej uywanej tabeli, 401 plany zapyta dla pustej partycji, 399 pole klucza uywanego do partycjonowania, 394 przekierowywanie polece INSERT do partycji, 397 reguy partycjonowania, 398 tworzenie partycji, 396, 405 uaktualnianie wyzwalacza, 400 wielkoci partycji, 395 zapytania partycjonowane, 403 zmiana daty, 400 partycjonowanie poziome, 408 generowanie wartoci hash, 408 GridSQL, 411 PL/Proxy, 408 Sharding, 410 parzysto, 38 pdflush, 98 pene skanowanie tabeli, 234 PERC, 45 perfmon, 360 ptle zagniedone, 281 materializacja zczenia Merge Join, 284 wewntrzne skanowanie indeksu, 282

453


Wysoko wydajny PostgreSQL 9.0

pg_archivecleanup, 436 pg_autovacuum, 181 pg_buffercache, 29, 37, 122, 125, 134, 201, 340, 433 instalacja, 123 pg_buffercache.sql, 28 pg_bulkload, 417 pg_class, 125 pg_clog, 110, 133, 326, 422 pg_column_size(), 333 pg_ctl, 146, 150, 439 pg_database, 125 pg_database_size(), 333 pg_default, 109 pg_dump, 23 pg_dumpall, 23 pg_freespacemap, 194 pg_hba.conf, 148, 371 pg_indexes_size(), 334, 439 pg_last_xlog_receive_location(), 436 pg_last_xlog_replay_location(), 436 pg_locks, 318, 326, 327, 328, 330, 332 pg_migrator, 24 pg_multixact, 110 pg_prepared_xacts, 318 pg_relation_size(), 139, 333, 334 pg_reload_conf(), 146 pg_restore, 24, 435 pg_settings, 118, 144, 147, 336 pg_size_pretty(), 333 pg_sleep(), 231 pg_start_backup, 382 pg_stat_activity, 188, 318, 324, 325, 328, 330, 372, 432, 433, 438 pg_stat_all_tables, 181, 318 pg_stat_bgwriter, 130, 132, 134, 316, 317, 318, 335, 336, 337, 340, 363, 426, 432 pg_stat_database, 317, 324 pg_stat_reset(), 233, 317 pg_stat_reset_shared(), 317, 439 pg_stat_reset_single_function_counters(), 317, 427, 439 pg_stat_reset_single_table_counters(), 317, 427, 439 pg_stat_statements, 201, 202, 435, 440 pg_stat_sys_tables, 182, 318

454

pg_stat_tables, 141 pg_stat_tmp, 110 pg_stat_user_functions, 435 pg_stat_user_indexes, 322, 323 pg_stat_user_tables, 131, 179, 182, 190, 230, 316, 318, 324, 426, 432, 433 pg_statio_user_tables, 230, 320, 324 pg_stats, 290 pg_stop_backup, 382 pg_subtrans, 110, 422 pg_table_size(), 139, 334, 439 pg_tblspc, 110 pg_total_relation_size(), 139, 334 pg_twophase, 110 pg_upgrade, 24, 25, 440 pg_xlog, 103, 110, 155 pgAdmin III, 184, 262 pgbench, 28, 59, 137, 201, 209, 344, 433, 439 analiza opรณ nienia, 219 definicja skryptu zapytania, 211 definicja tabeli, 210 inicjalizacja tabel, 211 konfiguracja serwera bazy danych, 213 ograniczenia programu, 224 powody otrzymywania bdnych wynikรณw i rรณnic, 222 programistyczne wersje PostgreSQL, 223 skrypt transakcji, 211 test przeprowadzajcy jedynie zapytania SELECT, 217 test szybkoci wstawiania danych, 225 test transakcji TPC-B-like, 218 testy domylne, 209 uruchamianie, 214 uyteczno wynikรณw, 223 wtki worker, 224 wasne testy, 225 wykrywanie skali wielkoci bazy danych, 210 wyniki graficzne, 216 wyniki testรณw, 217 pgbench_accounts, 141, 210, 212, 319 pgbench_accounts_key, 140 pgbench_accounts_pkey, 141 pgbench_branches, 210, 212, 319, 320 pgbench_history, 210, 212, 320, 321


Skorowidz

pgbench_tellers, 210, 319, 320 pgbench-tools, 216 konfiguracja, 216 pgBouncer, 374 PgCluster, 390 pgfincore, 134 pgFouine, 189, 203 format danych wyjciowych, 204 pgFoundry, 30 pgiosim, 78 pgloader, 416, 417 pgmemcache, 377 pgpool, 389 pgpool-II, 373, 389 r贸wnowaenie obcienia dla skalowania replikacji, 374 pgsi, 206 pgstat_bgwriter, 130 pgstat_bgwriter.buffers_alloc, 131 pgstat_bgwriter.checkpoints_req, 129 pgstat_bgwriter.checkpoints_timed, 129 pgstatspack, 367 pgstattuple, 194 pgtune, 166 PITR, 382, 419 PITRtools, 383 PL/pgSQL, 424, 438 PL/Proxy, 408 skalowanie, 410 plan zapytania, 256 plan zapyta dla pustej partycji, 399 wzy, 259 plik dziennika zdarze, 200 pliki tymczasowe, 111 podtrzymywany bateryjnie bufor zapisu, 50 podw贸jnie buforowane dane, 133 Point-in-time recovery, 382 pole kontekstu, 145 polecenia skadowane, 423 poczenia z baz danych, 147, 324 pomiar nadmuchania indeksu, 191 pominicie optymalizacji mechanizmu WAL, 418 ponowne indeksowanie, 244 ponowne wczytywanie pliku konfiguracyjnego, 146 poprawianie zapyta, 299

postgres, 196 PostgreSQL, 21 uaktualnienie bezporednie, 24 uaktualnienie do nowszej g贸wnej wersji, 23 wersje, 23, 429 wydajno wyda, 22 PostgreSQL 8.1, 22, 431 PostgreSQL 8.2, 432 PostgreSQL 8.3, 25, 432 PostgreSQL 8.4, 434 PostgreSQL 9.0, 24, 436 PostgreSQL System Impact, 206 postgresql.conf, 118, 143, 439 komentarze, 146 postgresql-contrib, 28 Postgres-XC, 390 postmaster, 145 poszukiwanie odpowiednika zapytania, 300 PQA, 205 PRECEDING, 437 PREPARE, 423 PREPARE TRANSACTION, 318 PRIMARY KEY, 232 problemy zwizane z wydajnoci, 421 wersje PostgreSQL, 429 procesor, 36 testy wydajnoci, 55, 59 profilowanie, 32 dyskowe operacje wejcia-wyjcia, 349 profilowanie bazy danych, 427 DTrace, 428 gprof, 427 OProfile, 428 Visual Studio, 428 programowa macierz RAID, 44 programowanie bazy danych, 438 programowanie CTE, 434 projekt dbt, 227 projekty replikacji, 389 Promise, 46 protokoy SMART, 40 SNMP, 363 Streaming Replication, 384 XMP, 60 prstat, 356

455


Wysoko wydajny PostgreSQL 9.0

przecienie klucz zewntrzny, 424 mechanizm zbierajcy dane statystyczne, 426 punkt kontrolny, 134 przegld wielkoci bufora, 141 przegld zawartoci bufora, 137 przekierowywanie polece INSERT do partycji, 397 przetwarzanie punkt贸w kontrolnych, 128 przetwarzanie wz贸w, 268 Aggregate, 271 Append, 275 CTE, 280 Gruop, 276 HashAggregate, 272 Limit, 270 Nested Loop, 278, 280 OFFSET, 271 operacje ustawiania, 278 Result, 274 Sort, 268 sortowanie, 268 Subplan, 277 Subquery Scan, 277 Unique, 273 WindowAgg, 274 przywracanie r贸wnolege, 419 przywr贸cenie do pewnego punktu w czasie, 382 ps, 355, 426 pset, 231 psql, 59 pula pocze, 371 liczba pocze, 372 liczniki, 372 pgBouncer, 374 pgpool-II, 373 serwer aplikacji, 375 punkty kontrolne, 128 aktywno tworzenia, 335 natenie operacji wejcia-wyjcia, 130 przecienie, 134 rozproszenie, 130 tworzenie, 129 ustawienia, 155

456

Q QUERY EXECUTE...USING, 423 quicksort, 269 quote_literal, 424

R RAID, 38, 112 RAID 0, 39 RAID 1, 39, 112 RAID 1+0, 39 RAID 10, 39 RAID 5, 39 RAID 6, 39 RAM, 37 Random Access, 68 random_page_cost, 161, 239, 260, 262, 300 Read Committed, 171 Reconnoiter, 368 redirect_stderr, 195 REDO, 48 Redundant Array of Independent Disks, 38 reguy partycjonowania, 398 REINDEX, 125, 189, 192, 243, 320, 406, 440 ReiserFS, 93 rejestrowanie CSV, 197 rejestrowanie danych wydajnoci, 363 rejestrowanie informacji o blokadach, 332 rejestrowanie trudnych zapyta, 199 rejestrowanie zdarze, 150, 194 zdarzenia procesu demona autovacuum, 182 relatime, 97 replikacja, 24, 381, 388, 436 Bucardo, 388 Hot Standby, 381, 384 konfiguracja za pomoc danych mechanizmu WAL, 383 Londiste, 387 menedery kolejki replikacji, 386 pgpool-II, 389 projekty replikacji, 389 skalowanie odczytu, 388 Slony, 387 Streaming Replication, 384


Skorowidz

RESET, 144 reset_val, 144 resource fork, 334 Result, 274 ROLLBACK, 170, 176, 401 Round Robin Database tool, 364 row_number(), 311 rozgrzany bufor, 257 rozproszenie punktów kontrolnych, 130 rozproszenie uycia bufora, 140 rozwizywanie bdów optymalizatora, 305 rozwizywanie problemów zwizanych z wydajnoci, 33 równowaenie obcienia pgpool-II dla skalowania replikacji, 374 RPM, 38 RRDtool, 364 Rubyrep, 390 runtime(), 328

S SAN, 46, 47 sar, 357 graficzna prezentacja danych, 359 SAS, 38 SATA, 38 SATA RAID, 45 schemat partycjonowania, 86 segmap_percent, 103 segmapsize, 103 sekwencyjny dostp, 61 SELECT, 59 semafory jdra, 120 Semi Join, 307 Seq Scan, 266, 270 seq_page_cost, 260, 261, 300, 432 Serial ATA, 38 Serial Attached SCSI, 38 Serial Presence Detect, 60 serializacja, 172 serwer dedykowany, 164 serwer wspódzielony, 165 serwer zapasowy, 382 session_line_num, 198 SET, 269 SET CONSTRAINTS, 425

Sharding, 410 Shared Nothing, 410 shared_buffers, 32, 117, 121, 134, 135, 149, 159, 164, 255, 295, 320, 336, 340, 341, 440 shared_preload_libraries, 200 short stroking, 63, 67 SHOW, 118, 147 sighup, 145, 146 SIGHUP, 146 Simple Network Management Protocol, 363 single-channel, 60 skala wielkoci bazy danych, 210 skalowanie odczytu, 388 skalowanie replikacji, 374 skalowanie za pomoc PL/Proxy, 410 skalowanie za pomoc replikacji, 381 skanowanie CTE, 280 skanowanie indeksu, 238, 266, 267 skanowanie mapy bitowej indeksu, 434 skanowanie sekwencyjne, 238, 266 Slony, 374, 387 SMART, 40 SN, 410 SNMP, 363 narzdzia, 369 SNMP MIB, 369 soft updates, 104 Solaris, 102 Solid State Drive, 42 Sort, 268 sortowanie, 248 sortowanie zewntrzne przez scalanie, 269 SPD, 60 spindle, 61, 62 sposoby zapisu zmodyfikowanych bloków, 132 sprawdzanie wydajnoci bazy danych, 209 sprzt, 35 dyski twarde, 37 konfiguracja dysków, 48 kontrolery dysków, 43 pami, 37 procesor, 36 testy wydajnoci, 55 wydatki na zakup sprztu, 35 sprztowa macierz RAID, 44 SQL Injection, 423 SQLite, 26

457


Wysoko wydajny PostgreSQL 9.0

SSD, 42 Standby, 382 Staplr, 369 Statistic Collector, 315 stats_block_level, 182 stats_reset_on_server_start, 317 stats_row_level, 153, 182 stats_start_collector, 153, 182 stats_temp_directory, 435 STDDEV(), 271 Storage Area Network, 46 STREAM, 56 platformy sprztowe, 57 Streaming Replication, 384, 385 stream-scaling, 57 stripe, 82 striped z parzystoci, 39 striping, 39 struktura wz贸w planu zapytania, 259 Subplan, 277 Subquery Scan, 277 SUM(), 271 superuser, 145 superuser_reserved_connections, 153 swappiness, 98 swapping, 98 sygna SIGHUP, 146 symlink, 108 SYNCHRONIZE CACHE, 95 synchronous_commit, 160, 418, 432 sysbench, 65, 75 czas wyszukiwania, 76 liczba operacji zatwierdzania za pomoc fsync, 77 sysctl, 120 sysctl.conf, 98, 120 Sysinternals, 360 syslog, 197 sysstat, 357, 358 system plik贸w, 85 bariery zapisu, 95 Btrfs, 93 buforowanie odczytu, 98 czas dostpu do plik贸w, 97 dostrajanie, 96 ext2, 88

458

ext3, 89 ext4, 91 FAT32, 107 FreeBSD, 102, 104 JFS, 93 ksigowanie, 87, 88, 89 Linux, 88 maksymalna ilo danych, 85 metadane, 86 naprawa, 87 NTFS, 107 odczyt z wyprzedzeniem, 96 odzyskiwanie danych po awarii, 86 okrelanie wielkoci bufora zapisu, 98 ReiserFS, 93 Solaris, 102 swapping, 98 UFS, 102 UFS2, 104 winda harmonogramu operacji wejcia-wyjcia, 100 Windows, 107 XFS, 91, 96 ZFS, 105 szacowanie wielkoci pamici wsp贸dzielonej, 121 szybkie sortowanie, 269

redni czas dostpu, 62

T tabele, 318 dane statystyczne, 318 operacje wejcia-wyjcia, 320 partycjonowanie danych, 393 table_stats, 233 tablespace, 109 technika HOT, 173, 178 technika TOAST, 139 temp_tablespaces, 111, 433 test_fsync, 64, 65 testowanie pamici, 56 testowanie wydajnoci dysku, 65


Skorowidz

testy OLTP, 22 testy szybkoci wstawiania danych, 225 testy TPC-H, 26 testy transakcji TPC-B-like, 218 testy wydajnoci, 32, 227 PL/pgSQL, 424 Transaction Processing Performance Council, 226 testy wydajnoci sprztu, 55 dysk, 61, 77 memtest86+, 56 pami, 55 procesor, 55, 59 TEXT, 25 The Database Test, 227 TID, 265 timeofday(), 325 timing, 59 TOAST, 139, 321, 334 Tomcat, 375 top, 355 zamienniki, 356 top-down, 270 TPC, 209, 227 TPC-B, 209 TPC-B (sort of), 211 TPC-B-like, 211, 218, 223 TPC-C, 227 TPC-H, 26, 227 TPS, 22, 219, 344 track_functions, 424 transaction id, 326 Transaction Per Second, 22 Transaction Processing Performance Council, 209, 226 Transactions Per Second, 219, 344 transakcje, 433 transakcje skadowane, 122, 318 transakcje wirtualne, 326 trendy, 362, 363 przechowywanie historycznych danych trend贸w, 363 TRUNCATE, 125, 419 trway identyfikator, 326 tryb JBOD, 53

tworzenie blok w bazie danych, 126 indeks, 235, 241 przykadowe dane, 232 punkty kontrolne, 129 tworzenie partycji, 396, 405 tworzenie dynamiczne, 406 tworzenie zgodnie z harmonogramem, 405 txid_current(), 168, 176, 433 txid_current_snapshot(), 168, 433

U uaktualnianie wyzwalacza, 400 uaktualnienia, 169 uaktualnienie do nowszej g贸wnej wersji, 23 uaktualnienie bezporednie, 24 uaktualnienie do PostgreSQL 8.3, 25 uaktualnienie mniej znaczcych wersji, 25 UFS, 102 ufs:freebehind, 103 UFS1, 102 UFS2, 104 unikalno indeksu, 242 UNION, 275 Unique, 273 UNIQUE, 425 Unix File System, 102 UPDATE, 170, 171, 172, 173, 176, 200, 201, 298, 299 update_process_title, 355 uruchamianie pgbench, 214 proces demona autovacuum, 183 urzdzenia, 347 NAS, 46, 47 SAN, 46, 47 USB, 41 user, 145 ustawienia na poziomie klienta, 159 usunicia, 173 usuwanie zcze, 288 uuid-ossp, 29 uycie pamici przez wyzwalacz, 425 uywanie moduu contrib, 29

459


Wysoko wydajny PostgreSQL 9.0

V vacuum, 176, 179, 180 autovacuum, 181 bdy spowodowane brakiem pamici, 187 HOT, 178 implementacja procesu, 177 odzyskanie wolnego miejsca na dysku, 177 operacja czyszczenia na podstawie koszt贸w, 179 problemy, 185 proces vacuum, 177 strony brudne, 180 strony pominite, 180 strony trafione, 180 VACUUM, 150, 152, 435 VACUUM ANALYZE, 232 VACUUM FULL, 178, 185, 189, 191, 192, 433, 440 VACUUM VERBOSE, 150, 189 vacuum_cost_delay, 180 vacuum_cost_page_dirty, 180 vacuum_cost_page_hit, 180 vacuum_cost_page_miss, 180 vacuum_defer_cleanup_age, 385 vacuum_freeze_max_age, 175 vacuum_freeze_min_age, 175, 418, 420 VARIANCE(), 271 vfs.hirunningspace, 104 vfs.read_max, 104 Visual Studio, 428 vm.overcommit_memory, 98 vm.swappiness, 98 vmstat, 32, 69, 344, 346

W WAL, 48, 49, 88, 90, 128, 338, 347, 382 konfiguracja przekazywania danych, 383 ustawienia, 156 wal_block_size, 121 wal_buffers, 118, 121, 156, 165, 418 wal_level, 436 wal_sync, 158 wal_sync_method, 50, 51, 65, 157, 158, 165 wal_writer_delay, 160

460

walmgr, 383 wartoci hash, 408 wartoci null, 242 wskie gardo, 32 wczytywanie pliku konfiguracyjnego, 146 wersje PostgreSQL, 21, 429 wewntrzne skanowanie indeksu, 282 wzy planu zapytania, 259 WHERE, 171, 266, 281, 287, 407 widoczno transakcji, 167 cykl yciowy widocznoci rekordu, 168 konflikty podczas blokowania rekord贸w, 171 serializacja, 172 uaktualnienia, 169 usunicie, 173 vacuum, 176 wewntrzne mechanizmy okrelajce widoczno, 168 xmax, 168 xmin, 168 zerowanie identyfikatora transakcji, 174 widoki danych statystycznych, 315 pg_stat_bgwriter, 316 pg_stat_user_tables, 316 widoki kumulacyjne, 317 widoki zmaterializowane, 427 Widoki ywe, 317 wielko zapytania na dysku, 230 winda harmonogramu operacji wejcia-wyjcia, 100 Window, 311, 434, 437 kumulowanie wyniku, 311 numerowanie, 311 WindowAgg, 274 Windows, 107 WITH, 434 WITH RECURSIVE, 434 wolne wykonywanie funkcji i polece skadowanych, 423 work_mem, 111, 117, 160, 269, 296, 297, 418 Write-Ahead Log, 48, 156, 382 writeback, 107 written_per_sec, 339, 340 wsp贸biene tworzenie indeksu, 243 wyb贸r wersji PostgreSQL, 23


Skorowidz

wyczerpanie mapy Free Space Map, 188 wydajno bazy danych, 209 wydajno bufora bez wstrzymywania zapisu, 52 wydajno dysku, 61 wydajno wyda PostgreSQL, 22 wydajno zapyta IN, 277 wydatki na zakup sprztu, 35 wykorzystanie dysku, 333 wykorzystanie pamici, 358 wykrywanie skali wielkoci bazy danych, 210 wyczanie bufor zapisu w napdzie, 52 funkcje optymalizatora, 301 wymuszanie kolejnoci zcze, 287 wyniki testów pgbench, 217 wyszukiwanie, 233 wyszukiwanie za pomoc nieefektywnego indeksu, 235 wyszukiwanie moduów contrib, 28 wyzwalacze, 397, 438 AFTER, 425 uycie pamici, 425

X XFS, 91, 96, 341 XID, 168, 175, 326, 327 xmax, 168, 173, 174 xmin, 168, 174 XML, 263 XMP, 60

Y YAML, 263

zbiór dzienników zdarze, 195 ZCAV, 63 Zenoss, 368 zerowanie danych statystycznych, 426 zerowanie identyfikatora transakcji, 174 zewntrzne dyski twarde, 41 zewntrzne programy do wczytywania danych, 416 ZFS, 44, 105 zfs_nocacheflush, 106 zimny bufor, 257 zliczanie rekordów, 421 zczenia, 281 Anti Join, 286 genetyczny optymalizator zapyta, 289 GEQO, 289 Hash Join, 285, 300, 302 Hash Semi, 277, 286 INNER JOIN, 289 kolejno zcze, 287 LEFT JOIN, 289 Merge Join, 280, 283 ptle zagniedone, 281 ptle zagniedone wraz z wewntrznym skanowaniem indeksu, 282 Semi Join, 307 usuwanie zcze, 288 wymuszanie kolejnoci zcze, 287 zczenia zewntrzne, 437 zmaterializowane widoki, 427 znormalizowane lady wykonywanych zapyta, 201 zrzucanie zawartoci bazy danych do pliku, 24, 25 zwikszenie parametrów pamici wspódzielonej w systemie Unix, 119

Z zakleszczenia, 332 zakup sprztu, 35 zapis migawek pg_stat_bgwriter, 337 zapis w tle, 132, 335, 339 zapis zmodyfikowanych bloków na dysku, 127 zapytania, 253 zapytania obejmujce wiele wierszy, 196 zapytania partycjonowane, 403

461


Wysoko wydajny PostgreSQL 9.0  

Masz w rękach kompletny podręcznik, przeznaczony dla średnio i bardzo zaawansowanych administratorów baz danych, którzy już używają PostgreS...

Advertisement