Wysoko wydajny PostgreSQL 9 0 wyssql

• 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

O recenzentach

Wprowadzenie

Rozdzia 1. Wersje PostgreSQL

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

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

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

102

Solaris UFS

102

FreeBSD UFS2

104

ZFS

105

Systemy plików w Windows

107

FAT32

107

NTFS

107

Konfiguracja dysku dla PostgreSQL

108

Dowizania symboliczne

108

Tablespace

109

Drzewo katalogów bazy danych

109

Macierze dyskowe, RAID i konfiguracja dysków

112

Podsumowanie

115

Spis treci

Rozdzia 5. Pami dla bufora bazy danych

117

Jednostki pamici w pliku konfiguracyjnym postgresql.conf

118

Zwikszenie parametrów pamici wspódzielonej w systemie Unix

w celu zdefiniowania wikszego bufora

119

Semafory jdra

120

Oszacowanie wielkoci pamici wspódzielonej

121

Przegld bufora bazy danych

122

Instalacja pg_buffercache w bazie danych

123

Konfiguracja ukadu dysków

124

Utworzenie nowego bloku w bazie danych

126

Zapis zmodyfikowanych bloków na dysku

127

Naprawa bazy danych po awarii a wielko bufora

128

Podstawy przetwarzania punktów kontrolnych

128

Dziennik zapisu z wyprzedzeniem a proces naprawy po awarii

128

Tworzenie punktów kontrolnych

129

Cykl ycia bloku bazy danych

131

Bufor bazy danych kontra bufor systemu operacyjnego

132

Podwójnie buforowane dane

133

Przecienie punktu kontrolnego

134

Pocztkowe wskazówki dotyczce wielkoci

135

Analiza zawartoci bufora

136

Zapytania pozwalajce na przegld zawartoci bufora

137

Przegld wielkoci bufora i jej dostosowanie

141

Podsumowanie

141

Rozdzia 6. Optymalizacja konfiguracji serwera

143

Interakcja z uywan konfiguracj

144

Ustawienia domylne i sposoby ich zerowania

144

Dozwolony kontekst do przeprowadzania zmian

144

Ponowne wczytywanie pliku konfiguracyjnego

146

Ustawienia na poziomie serwera

147

Poczenia z baz danych

147

Pami wspódzielona

149

Rejestrowanie zdarze

150

Polecenie VACUUM i dane statystyczne

152

Punkty kontrolne

155

Ustawienia mechanizmu WAL

156

Replikacja WAL i PITR

159

Ustawienia na poziomie klienta

159

Optymalizacje niezalecane

162

Optymalizacja ustawie nowego serwera

164

Wskazówki dotyczce serwerów dedykowanych

164

Wskazówki dotyczce serwerów wspódzielonych

165

pgtune

166

Podsumowanie

166

Wysoko wydajny PostgreSQL 9.0

Rozdzia 7. Rutynowa konserwacja

167

Widoczno transakcji wraz z kontrol wspóbienoci

167

Wewntrzne mechanizmy okrelajce widoczno

168

Uaktualnienia

169

Konflikty podczas blokowania rekordów

171

Usunicie

173

Zalety mechanizmu MVCC

174

Wady mechanizmu MVCC

174

Wyzerowanie identyfikatora transakcji

174

Vacuum

176

Implementacja procesu vacuum

177

Operacja czyszczenia na podstawie kosztów

179

Demon autovacuum

181

Powszechnie spotykane problemy z vacuum i autovacuum

185

Automatyczna analiza

190

Nadmuchane indeksy

191

Pomiar nadmuchania indeksu

191

Szczegóowe monitorowanie stron indeksu i danych

193

Monitorowanie dzienników zdarze zapyta

194

Podstawowa konfiguracja rejestracji zdarze w PostgreSQL

194

Rejestrowanie trudnych zapyta

199

Analiza pliku dziennika zdarze

200

Podsumowanie

207

Rozdzia 8. Sprawdzanie wydajnoci bazy danych

209

Domylne testy pgbench

209

Definicja tabeli

210

Wykrywanie skali wielkoci bazy danych

210

Definicja skryptu zapytania

211

Konfiguracja serwera bazy danych pod ktem pgbench

213

Rczne uruchamianie pgbench

214

Wyniki graficzne generowane za pomoc pgbench-tools

216

Konfiguracja pgbench-tools

216

Przykadowe wyniki testów pgbench

217

Test przeprowadzajcy jedynie zapytania SELECT

217

Test transakcji TPC-B-like

218

Analiza opónienia

219

Powody otrzymywania bdnych wyników i rónic

222

Programistyczne wersje PostgreSQL

223

Wtki worker i ograniczenia programu pgbench

224

Wasne testy pgbench

225

Test szybkoci wstawiania danych

225

Testy wydajnoci Transaction Processing Performance Council

226

Podsumowanie

228

Spis treci

Rozdzia 9. Indeksowanie bazy danych

229

Przegld sposobów indeksowania

230

Dane statystyczne suce do pomiaru wielkoci zapytania na dysku i bloku indeksu

230

Uruchomienie przykadu

231

Konfiguracja przykadowych danych

232

Proste wyszukiwania za pomoc indeksów

233

Pene skanowanie tabeli

234

Tworzenie indeksu

235

Wyszukiwanie za pomoc nieefektywnego indeksu

235

czenie indeksów

237

Przejcie ze skanowania indeksowanego na sekwencyjne

238

Klastry kontra indeksy

239

Polecenie Explain oraz liczniki bufora

241

Tworzenie indeksu i jego obsuga

241

Zapewnienie unikalnoci indeksów

242

Wspóbiene tworzenie indeksu

243

Klastrowanie indeksu

243

Ponowne indeksowanie

244

Rodzaje indeksów

245

B-tree

245

Hash

246

GIN

246

GiST

247

Zaawansowane sposoby korzystania z indeksów

247

Indeksy wielokolumnowe

248

Indeksy dla operacji sortowania

248

Indeksy czciowe

249

Indeksy bazujce na wyraeniu

249

Indeksowanie na potrzeby wyszukiwania penego tekstu

250

Podsumowanie

250

Rozdzia 10. Optymalizacja zapyta

253

Przykadowe zbiory danych

253

Pagila

254

Dell Store 2

254

Podstawy polecenia EXPLAIN

256

Obcienie zwizane z pomiarem

256

Zachowanie przy zimnym i rozgrzanym buforze

257

Struktura wzów planu zapytania

259

Podstawy obliczania kosztu

260

Narzdzia analizy danych polecenia EXPLAIN

262

Graficzne przedstawienie danych EXPLAIN

262

Rozbudowane dane wyjciowe

263

Dane wyjciowe EXPLAIN w postaci czytelnej dla komputera

263

Narzdzia suce do analizy planu

264

Wysoko wydajny PostgreSQL 9.0

czenie zbiorów rekordów

265

Identyfikator krotki

265

Skanowanie sekwencyjne

266

Skanowanie indeksu

266

Mapa bitowa i skanowanie indeksu

267

Przetwarzanie wzów

268

Wze Sort

268

Wze Limit

270

Wze Aggregate

271

Wze HashAggregate

272

Wze Unique

273

Wze Result

274

Wze Append

275

Wze Group

276

Wzy Subquery Scan i Subplan

277

Operacje ustawiania

278

Materializacja

279

Skanowanie CTE

280

Zczenia

281

Ptle zagniedone

281

Zczenie Merge Join

283

Zczenia Hash Join

285

Dane statystyczne

290

Przegldanie i szacowanie za pomoc danych statystycznych

290

Cele danych statystycznych

293

Obszary trudne do oszacowania

295

Inne parametry planowania zapytania

295

effective_cache_size

295

work_mem

297

constraint_exclusion

298

cursor_tuple_fraction

298

Wykonywanie innych typów zapyta

298

Poprawianie zapyta

299

Optymalizacja dla w peni buforowanych zbiorów danych

300

Poszukiwanie odpowiednika zapytania

300

Wyczanie funkcji optymalizatora

301

Rozwizywanie bdów optymalizatora

305

Unikanie planu restrukturyzacji za pomoc OFFSET

306

Zewntrzne róda problemów

309

Ograniczenia SQL

309

Numerowanie rekordów w SQL

309

Uywanie funkcji Window do numerowania

311

Uywanie funkcji Window do kumulowania wyniku

311

Podsumowanie

313

Spis treci

Rozdzia 11. Dane statystyczne i dziaanie bazy danych

315

Widoki danych statystycznych

315

Widoki kumulacyjne i ywe

317

Dane statystyczne tabel

318

Operacje wejcia-wyjcia tabel

320

Dane statystyczne indeksu

322

Operacje wejcia-wyjcia indeksu

323

Dane statystyczne dotyczce caej bazy danych

324

Poczenia i aktywno

324

Blokady

325

Transakcje wirtualne

326

Dekodowanie informacji o blokadzie

327

Oczekiwanie na blokad transakcji

330

Oczekiwanie na blokad tabeli

331

Rejestrowanie informacji o blokadach

332

Wykorzystanie dysku

333

Bufor, zapis w tle oraz aktywno tworzenia punktu kontrolnego

335

Zapis migawek pg_stat_bgwriter

337

Optymalizacja z uyciem danych statystycznych dotyczcych zapisu w tle

339

Podsumowanie

341

Rozdzia 12. Monitorowanie i trendy

343

Narzdzia monitorujce w systemie Unix

343

Przykadowa konfiguracja

344

vmstat

344

iostat

347

top

355

sysstat i sar

357

Narzdzia monitorujce dla Windows

360

Meneder zada

360

Monitor systemu Windows

360

Oprogramowanie trendów

362

Rodzaje monitorowania i oprogramowanie trendów

363

Nagios

364

Cacti

366

Munin

366

Inne pakiety trendów

367

Podsumowanie

369

Rozdzia 13. Pula pocze i buforowanie

371

Pula pocze

371

Liczniki puli pocze

372

pgpool-II

373

pgBouncer

374

Wysoko wydajny PostgreSQL 9.0

Buforowanie bazy danych

376

memcached

376

pgmemcache

377

Podsumowanie

378

Rozdzia 14. Skalowanie za pomoc replikacji

381

Hot Standby

381

Terminologia

382

Konfiguracja przekazywania danych mechanizmu WAL

383

Protokó Streaming Replication

384

Optymalizacja funkcji Hot Standby

384

Menedery kolejki replikacji

386

Slony

387

Londiste

387

Skalowanie odczytu za pomoc oprogramowania replikacji bazujcego na kolejce

388

Wymagania aplikacji specjalnych

388

Bucardo

388

pgpool-II

389

Inne interesujce projekty replikacji

389

Podsumowanie

391

Rozdzia 15. Partycjonowanie danych

393

Partycjonowanie o zasigu tabeli

393

Okrelenie pola klucza uywanego do partycjonowania

394

Wielkoci partycji

395

Tworzenie partycji

396

Przekierowywanie polece INSERT do partycji

397

Plany zapyta dla pustej partycji

399

Zmiana daty i uaktualnianie wyzwalacza

400

Migracja partycjonowanej uywanej tabeli

401

Zapytania partycjonowane

403

Tworzenie nowych partycji

405

Zalety partycjonowania

406

Bdy czsto popeniane podczas partycjonowania

407

Partycjonowanie poziome za pomoc PL/Proxy

408

Generowanie wartoci hash

408

Skalowanie za pomoc PL/Proxy

410

Skalowanie za pomoc GridSQL

411

Podsumowanie

412

Rozdzia 16. Unikanie najczciej spotykanych problemów

415

Operacja bulk-loading

415

Metody wczytywania danych

416

Optymalizacja operacji bulk-loading

417

Pominicie optymalizacji mechanizmu WAL

418

Spis treci

Ponowne utworzenie indeksów i dodanie ogranicze

419

Przywracanie równolege

419

Czyszczenie po operacji wczytania danych

420

Najczstsze problemy zwizane z wydajnoci

421

Zliczanie rekordów

421

Niewyjanione operacje zapisu

422

Wolne wykonywanie funkcji i polece skadowanych

423

Testy wydajnoci PL/pgSQL

424

Ogromne przecienie klucza zewntrznego

424

Uycie pamici przez wyzwalacz

425

Ogromne przecienie mechanizmu zbierajcego dane statystyczne

426

Zmaterializowane widoki

427

Profilowanie bazy danych

427

gprof

427

OProfile

428

Visual Studio

428

DTrace

428

Problemy wydajnoci w poszczególnych wersjach

429

Agresywne uaktualnienia PostgreSQL

430

8.1

431

8.2

432

8.3

432

8.4

434

9.0

436

Podsumowanie

441

Skorowidz

443

Optymalizacja

konfiguracji serwera

Podstawowe ustawienia optymalizacyjne PostgreSQL znajduj si w zwykym pliku teksto-
wym 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 rodowi-
skowej

$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 ka-
dego parametru, nacisk zosta pooony na udzielenie wskazówek dotyczcych ustawiania naj-
waniejszych 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 doty-
czce przyszych wersji bazy danych PostgreSQL, który byy niedostpne w trakcie przygoto-
wywania tego rozdziau.

Wysoko wydajny PostgreSQL 9.0

144

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 mody-
fikacj 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 polece-
nia dane wyjciowe bd zawieray wszystkie parametry serwera):

Rozdzia 6. • Optymalizacja konfiguracji serwera

145

W oficjalnym podrczniku uytkownika pole kontekstu (

context

) nie jest zbyt dobrze udoku-

mentowane. Poniej przedstawiono wic znaczenie rónych stosowanych ustawie w kolejnoci
od najtrudniejszego do najatwiejszego do zmiany.

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.

postmaster

. Ustawienia s uaktualniane jedynie podczas penego uruchamiania serwera.

Do tej kategorii zaliczaj si wszystkie opcje dotyczce pamici wspódzielonej.

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”.

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

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.

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 — wyda-
waoby 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.

Wysoko wydajny PostgreSQL 9.0

146

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 00:00:00 /home/postgres/inst/bin/
´postgres -D /home/postgres/data/
$ kill -HUP 11185

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 wy-
czony w dziaajcym serwerze? Konkretna odpowied zaley od wersji uywanego serwera.
Przyjmijmy zaoenie, e plik postgresql.conf zosta uruchomiony wraz z ustawionym nast-
pujcym 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

Rozdzia 6. • Optymalizacja konfiguracji serwera

147

Parametr

checkpoint_segments

jest ustawieniem kontekstu

sighup

. Od PostgreSQL 8.3 powy-

sza zmiana spowoduje powrót do wartoci domylnej serwera (

boot_val

). W wersji 9.0 w dzien-

niku 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 war-

to 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 wielo-
krotnego 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 nawi-
zywania poczenia z baz danych. Pena lista wspomnianych parametrów zostaa przedstawiona
na stronie http://www.postgresql.org/docs/current/static/runtime-config-connection.html.

Wysoko wydajny PostgreSQL 9.0

148

listen_addresses

W kadej instalacji wymagajcej obsugi pocze pochodzcych z systemów zdalnych konieczna
jest modyfikacja parametru

listen_addresses

pozwalajcego na obsug takich pocze. Domyl-

nie 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 doty-
czcym wydajnoci. Filtrowanie pocze za pomoc dokadniej skonfigurowanego parametru

listen_addresses

moe by znacznie bardziej efektywne ni pozwolenie na nawizanie po-

czenia 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 przyjmo-
wanie 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 war-
toci (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.

Rozdzia 6. • Optymalizacja konfiguracji serwera

149

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 wspomnia-
nych 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 zosta-
nie pami w obszarze Desktop Heap, obsuonych bdzie jedynie okoo 125 pocze. Wicej informa-
cji 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.

Wysoko wydajny PostgreSQL 9.0

150

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 para-
metrów

max_fsm_pages

max_fsm_relations

w pliku konfiguracyjnym s wystarczajce, powinno

by czci regularnych operacji konserwacyjnych w tych wersjach serwera PostgreSQL. Ope-
racj 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

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 bezpo-
rednio w pliku konfiguracyjnym postgresql.conf. Jeeli w celu rcznego uruchomienia ser-
wera 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]: '

Rozdzia 6. • Optymalizacja konfiguracji serwera

151

Powyszy parametr powoduje umieszczenie w kadym wierszu dziennika zdarze takich infor-
macji jak:

: znacznik czasu;

: nazwa uytkownika bazy danych;

: nazwa zdalnego komputera, z którego nawizano poczenie;

: nazwa bazy danych, z któr nawizano poczenie;

: 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:

none

. Nie s rejestrowane adne informacje na poziomie polece.

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.

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.

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 zwi-
zanych 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.

Wysoko wydajny PostgreSQL 9.0

152

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” pole-
ce, 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 zna-

le 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 doda-
wania, 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

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 usuwa-
nia 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 stoso-

wania 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.

Rozdzia 6. • Optymalizacja konfiguracji serwera

153

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 obsza-
rze 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 — zale-
cane jest równie uycie parametru

superuser_reserved_connections

zezwalajcego na dziaa-

nie 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 ekspery-
mentó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

ustawia-

nej dla kadego klienta. Warto pamita, e przynajmniej parametr

autovacuum_max_workers

Wysoko wydajny PostgreSQL 9.0

154

(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 obci-

enie 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 Postgre-
SQL 8.4 zostaa zwikszona do 100. Stosowanie wikszej wartoci byo popularne take w star-
szych wersjach bazy danych w celu ogólnego poprawienia zachowania zapyta. Indeksy korzy-
stajce z operatora

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 dodat-
kowe 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 insta-
lacji 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 staty-
stycznych, 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

Rozdzia 6. • Optymalizacja konfiguracji serwera

155

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 obsu-
guje 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

112 MB

144 MB

160 MB

336 MB

416 MB

480 MB

1040 MB

1296 MB

1504 MB

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 nast-
pujcy: 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.

Wysoko wydajny PostgreSQL 9.0

156

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 rozpra-
szania 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.

Rozdzia 6. • Optymalizacja konfiguracji serwera

157

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 bufo-
rowany, 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 poten-

cjalnym 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 naj-
bardziej 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 prawi-
dowo i gwarantuje wykonywanie bezpiecznych operacji zapisu w bazie danych bez spowal-
niania innych aplikacji, co ma miejsce w przypadku cakowitego wyczenia bufora zapisu
w dysku twardym.

Wysoko wydajny PostgreSQL 9.0

158

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 bez-
piecznego.

Na innych platformach optymalizacja parametru

wal_sync_method

moe by znacznie bardziej

skomplikowana. Teoretycznie istnieje moliwo poprawienia wydajnoci operacji zapisu w sys-
temach z rodziny Unix poprzez zmian dowolnej metody zapisu uywajcej par

write

fsync

lub

write

fdatasync

na stosujc zapis prawdziwie synchroniczny. Mona si przekona, po wyda-

niu 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 pli-
kó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.

Rozdzia 6. • Optymalizacja konfiguracji serwera

159

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 polece-
nie

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 pew-

nych 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:

w systemach z rodziny Unix oszacowanie wielkoci bufora systemu plików wymaga
dodania wartoci

free

cached

wywietlanych przez polecenia

free

top

;

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 wystarcza-
jco 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 wystar-
czajce do wikszoci celów. Kiedy jednak warto ta bdzie zbyt wysoka, wykonywanie zapy-
ta moe skutkowa zakóceniami w buforze zarówno bazy danych, jak i systemu operacyjnego

Wysoko wydajny PostgreSQL 9.0

160

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 okrelo-
nej przez powizany z ni parametr

wal_writer_delay

. Ustawienia domylne gwarantuj realne

zatwierdzenie transakcji na dysku po upywie co najwyej 600 milisekund od chwili zatwier-
dzenia 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 zatwierdza-
nia 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 sto-
sowanie 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 para-
metrze

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, zwik-
szenie wartoci parametru

work_mem

moe by jednym z najefektywniejszych sposobów przy-

pieszenia dziaania serwera. Magazyny danych generujce ogromne raporty maj w swoich
serwerach gigabajty pamici przypisane parametrowi

work_mem

Rozdzia 6. • Optymalizacja konfiguracji serwera

161

Problem polega na tym, e niekoniecznie mona atwo przewidzie liczb operacji sortowania
przeprowadzanych przez klienta, a parametr

work_mem

jest okrelany dla kadej operacji sor-

towania, a nie dla kadego klienta. Oznacza to, e ilo pamici uywanej przez

work_mem

moe

by teoretycznie nieograniczona, jeeli liczba klientów jednoczenie przeprowadzajcych sor-
towanie 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 przeprowa-
dzali 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 obli-

czonej liczby bdzie wartoci do du dla parametru

work_mem

. W takim przypadku w ser-

werze 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 pro-
stu 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 infor-
macji 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 partycjono-
wania danych zastosowano oferowan przez baz danych funkcj tabeli dziedziczenia, parametr

constraint_exclusion

musi by wczony. Powody takiego stanu rzeczy wyjaniono w rozdziale 15.

Wysoko wydajny PostgreSQL 9.0

162

Poczwszy od wersji 8.4, wartoci domyln parametru

constraint_exclusion

jest nowe, spryt-

niejsze 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 uru-

chomienie 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

, ponie-

wa 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 kom-

promis: 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 ope-

racje 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 przy-
pieszenia caej operacji. Po zakoczeniu procesu wstawiania naley z powrotem wczy
parametr

fsync

W niektórych systemach parametr

fsync

jest wyczany w serwerach posiadajcych redun-

dancyjn kopi bazy danych — na przykad w systemach zapasowych uywanych do genero-
wania raportów. Jeeli w takim przypadku dane zostan uszkodzone, zawsze mona przepro-
wadzi ponown synchronizacj z gównym systemem.

Rozdzia 6. • Optymalizacja konfiguracji serwera

163

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

commit_siblings

. W wikszoci przypadków nie s to

parametry efektywne do optymalizacji. Uzyskanie realnego przypieszenia poprzez dostosowa-
nie 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. Usta-
wienie 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 dopaso-

wa 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 podpo-
wiedzi 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.

Wysoko wydajny PostgreSQL 9.0

164

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.

Dostosowanie rejestracji zdarze w taki sposób, aby dostarczaa wikszej iloci

informacji.

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.

Rozsdne oszacowanie maksymalnej liczby pocze. Jest to ograniczenie bezwzgldne.

Po osigniciu ustalonej liczby pocze próby nawizania poczenia przez nowych
klientów bd odrzucane.

Uruchomienie serwera z tymi parametrami pocztkowymi. Nastpnie trzeba sprawdzi

ilo pamici pozostaej dla bufora systemu plików.

Kolejny krok to okrelenie wielkoci parametru

effective_cache_size

na podstawie

wielkoci parametru

shared_buffers

i bufora systemu operacyjnego.

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

Ustawienie dla parametru

maintenance_work_mem

wartoci okoo 50 MB na kady

gigabajt pamici RAM.

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.

Rozdzia 6. • Optymalizacja konfiguracji serwera

165

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 czy-
telnik bdzie mia znacznie lepsze rozeznanie, które wartoci pocztkowe maj sens, aby rozpo-
czyna z nimi prac. Szczególnie wartoci kocowe parametrów

checkpoint_segments

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 podroz-
dziale. 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:

parametrowi

shared_buffers

naley przydzieli tylko 10% pamici RAM, nawet

na platformach, na których normalnie zaleca si przydzielenie wikszej wartoci;

parametrowi

effective_cache_size

naley przydzieli 50% lub mniej pamici RAM,

prawdopodobnie mniej, jeli wiadomo, e aplikacja bdzie uywa duej iloci pamici;

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 dostp-
nej 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 mo-
liwo. W systemie wspódzielonym nie ma sensu przydzielanie bazie danych wikszej iloci
pamici, jeeli aplikacja bd inna warstwa buforujca, na przykad na poziomie puli po-
cze, nie bdzie efektywnie wykorzystywaa tej pamici. Ta sama idea — uycie rozsd-
nych wartoci pocztkowych, a nastpnie stopniowe przeprowadzanie optymalizacji na pod-
stawie monitorowania — sprawdza si doskonale take w serwerach dedykowanych.

Wysoko wydajny PostgreSQL 9.0

166

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 pomia-
ró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 zmodyfi-
kowa; 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 napo-
tka problemy, powinny te pokaza, które ustawienia s cenniejsze.

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.

Ustawienia parametrów zwizanych z pamici, czyli przede wszystkim

shared_buffers

work_mem

, powinny by przeprowadzane bardzo ostronie, aby nie doprowadzi

do sytuacji, w której systemowi zabraknie pamici.

W celu przygotowania waciwego planu wykonania zapytania planista zapytania musi
mie prawidowe informacje o pamici oraz dobre dane statystyczne dotyczce tabeli.

Demon

autovacuum

ma znaczenie krytyczne dla zapewnienia planicie zapytania

odpowiednich informacji. Ponadto demon

autovacuum

zapewnia tabelom uruchamianie

waciwych procesów konserwacyjnych.

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.

Skorowidz

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

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

444

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

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

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

445

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

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

dane statystyczne, 152, 290, 315

cele danych statystycznych, 293
dane dotyczce caej bazy danych, 324

Wysoko wydajny PostgreSQL 9.0

446

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

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

447

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

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

Wysoko wydajny PostgreSQL 9.0

448

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

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

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

449

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

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

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

Wysoko wydajny PostgreSQL 9.0

450

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

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

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,

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

451

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

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

Wysoko wydajny PostgreSQL 9.0

452

Multiversion Concurrency Control, 167
Munin, 366
MVCC, 167, 325

tryb Read Committed, 174
wady mechanizmu, 174
zalety mechanizmu, 174

MySQL, 26

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

NTFS, 87, 107

dostrajanie zachowania operacji

montowania systemu plików, 108

null, 242
numerowanie rekordów, 309

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

453

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

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

Wysoko wydajny PostgreSQL 9.0

454

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

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

455

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

Wysoko wydajny PostgreSQL 9.0

456

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

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

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

457

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

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

Wysoko wydajny PostgreSQL 9.0

458

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

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

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

459

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

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

Wysoko wydajny PostgreSQL 9.0

460

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

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

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

461

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

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

YAML, 263

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

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,

zwikszenie parametrów pamici

wspódzielonej w systemie Unix, 119

Wyszukiwarka

Podobne podstrony:
Wysoko wydajny PostgreSQL 9 0 wyssql
Wysoko wydajny PostgreSQL 9 0
Wysoko wydajny PostgreSQL 9 0 2
informatyka wysoko wydajny postgresql 9 0 gregory smith ebook
Wysoko wydajny PostgreSQL 9 0
Windows Server 2003 Wysoko wydajne rozwiazania w23wys
Windows Server 2003 Wysoko wydajne rozwiazania w23wys
Wysoko wydajne sieci TCP IP 2
Wysoko wydajne sieci TCP IP
informatyka wysoko wydajne mysql optymalizacja archiwizacja replikacja wydanie ii pelna lista autoro
Wysoko wydajne sieci TCP IP tcpwyd

więcej podobnych podstron