informatyka wysoko wydajny postgresql 9 0 gregory smith ebook

IdĨ do

• Spis treĞci
• Przykáadowy rozdziaá
• Skorowidz

• Katalog online

• Dodaj do koszyka

• Zamów cennik

• Zamów informacje

o nowoĞciach

• Fragmenty ksiąĪek

online

Helion SA
ul. KoĞciuszki 1c
44-100 Gliwice
tel. 32 230 98 63
e-mail: helion@helion.pl

Katalog ksiąĪek

Twój koszyk

Cennik i informacje

Czytelnia

Kontakt

• Zamów drukowany

katalog

Wysoko wydajny
PostgreSQL 9.0

Autor: Gregory Smith
Tłumaczenie: Robert Górczyński
ISBN: 978-83-246-3062-2
Tytuł oryginału:

PostgreSQL 9.0 High Performance

Format: 170×230, stron: 464

Poznaj najlepsze techniki zwiększania wydajności PostgreSQL i sprawdzone

rozwiązania najczęściej spotykanych problemów!

• Jak dobierać komponenty serwera, aby maksymalnie wykorzystać jego możliwości?
• Jak przeprowadzać testy wydajności całego systemu, od sprzętu po aplikację?
• Jak skutecznie indeksować bazę danych i optymalizować zapytania?

Mający za sobą już ponad piętnaście lat rozwoju PostgreSQL jest dziś potężnym systemem baz
danych typu open source, o sprawdzonej architekturze i reputacji narzędzia niezawodnego oraz
nieprzeciętnie wydajnego. Współdziała on ze wszystkimi popularnymi systemami operacyjnymi
i jest w pełni zgodny z warunkami ACID. Te zalety sprawiają, że można go używać jako magazynu
danych dla aplikacji oraz jako bazy danych dla aplikacji sieciowych. Jednak osiągnięcie maksymalnej
wydajności PostgreSQL nie jest wcale zadaniem łatwym, a w trakcie korzystania z jego serwerów
można napotkać powtarzające się trudności, zwłaszcza gdy wzrasta obciążenie serwera,
a wymagania stają się coraz większe. Jeśli zatem nie chcesz tygodniami dochodzić do właściwych
rozwiązań swoich problemów – oto książka, w której znajdziesz całą potrzebną Ci wiedzę.

Masz w rękach kompletny podręcznik, przeznaczony dla średnio i bardzo zaawansowanych
administratorów baz danych, którzy już używają PostgreSQL lub dopiero zamierzają to zrobić.
Najpierw zapoznasz się z najnowszymi wersjami tej platformy oraz dowiesz się, jak dobierać
komponenty serwera, aby optymalnie wykorzystać możliwości systemu.
Dzięki tej książce:

• Poznasz najlepsze praktyki pozwalające na obsłużenie wymagających aplikacji
• Odkryjesz, dlaczego sprzęt komputerowy nadaje się (lub nie) dla wysoko wydajnych

aplikacji bazodanowych

• Zrozumiesz, na czym polegają kompromisy związane z szybkością i niezawodnością

działania

• Zoptymalizujesz system operacyjny, aby osiągnąć najlepszą wydajność bazy danych
• Przeprowadzisz testy wydajności całego systemu, od sprzętu komputerowego po aplikację
• Przeanalizujesz rzeczywiste przykłady, co pozwoli Ci poznać wpływ różnych ustawień

parametrów serwera na wydajność

• Będziesz skutecznie monitorować zdarzenia zachodzące na serwerze, zarówno w bazie

danych, jak i poza nią

• Znajdziesz najlepsze dodatki, rozszerzające podstawowe możliwości bazy danych PostgreSQL
• Dowiesz się, jak przygotować replikację systemów za pomocą najnowszych funkcji

wprowadzonych w PostgreSQL 9.0

Zoptymalizuj swój serwer PostgreSQL i unikaj problemów,

które mogą zmniejszyć jego wydajność!

Spis tre"ci

O autorze

O recenzentach

Wprowadzenie

Rozdzia# 1. Wersje PostgreSQL

Wydajno"$ we wcze"niejszych wydaniach PostgreSQL

Wybór odpowiedniej wersji

Uaktualnienie do nowszej g"ównej wersji

PostgreSQL czy inna baza danych?

Narz%dzia PostgreSQL

Modu"y contrib w PostgreSQL

pgFoundry

Dodatkowe oprogramowanie zwi#zane z PostgreSQL

Cykl &yciowy aplikacji PostgreSQL

Optymalizacja wydajno"ci w praktyce

Podsumowanie

Rozdzia# 2. Sprz%t dla bazy danych

Zrównowa&enie wydatków na zakup sprz%tu

Procesor

Pami$%

Dyski twarde

Kontrolery dysków

Niezawodne kontrolery i konfiguracja dysków

Bufor zapisu

Wp"yw bufora bez wstrzymywania zapisu na wydajno&%

Podsumowanie

Wysoko wydajny PostgreSQL 9.0

Rozdzia# 3. Testy wydajno"ci sprz%tu dla bazy danych

Testy wydajno"ci procesora i pami%ci

memtest86+

Testowanie pami$ci za pomoc# narz$dzia STREAM

Testy wydajno&ci procesora

Powody wolnego dzia"ania procesora i pami$ci

Fizyczna wydajno"$ dysku

Swobodny dost$p i liczba operacji wej&cia-wyj&cia na sekund$

Dost$p sekwencyjny i ZCAV

Liczba wykonywanych operacji zatwierdzania

Narz%dzia do testowania wydajno"ci dysku

hdtune

bonnie++

sysbench

Skomplikowane testy wydajno&ci dysku twardego

Przyk#adowe wyniki testu wydajno"ci 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 ksi$gowaniem

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

Dowi#zania symboliczne

108

Tablespace

109

Drzewo katalogów bazy danych

109

Macierze dyskowe, RAID i konfiguracja dysków

112

Podsumowanie

115

Spis tre"ci

Rozdzia# 5. Pami%$ dla bufora bazy danych

117

Jednostki pami%ci w pliku konfiguracyjnym postgresql.conf

118

Zwi%kszenie parametrów pami%ci wspó#dzielonej w systemie Unix

w celu zdefiniowania wi%kszego bufora

119

Semafory j#dra

120

Oszacowanie wielko&ci pami$ci wspó"dzielonej

121

Przegl'd bufora bazy danych

122

Instalacja pg_buffercache w bazie danych

123

Konfiguracja uk"adu 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

Przeci#'enie punktu kontrolnego

134

Pocz#tkowe wskazówki dotycz#ce wielko&ci

135

Analiza zawarto"ci bufora

136

Zapytania pozwalaj#ce na przegl#d zawarto&ci bufora

137

Przegl#d wielko&ci bufora i jej dostosowanie

141

Podsumowanie

141

Rozdzia# 6. Optymalizacja konfiguracji serwera

143

Interakcja z u&ywan' konfiguracj'

144

Ustawienia domy&lne i sposoby ich zerowania

144

Dozwolony kontekst do przeprowadzania zmian

144

Ponowne wczytywanie pliku konfiguracyjnego

146

Ustawienia na poziomie serwera

147

Po"#czenia 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 dotycz'ce serwerów dedykowanych

164

Wskazówki dotycz'ce 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ó#bie&no"ci

167

Wewn$trzne mechanizmy okre&laj#ce widoczno&%

168

Uaktualnienia

169

Konflikty podczas blokowania rekordów

171

Usuni$cie

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 wydajno"ci bazy danych

209

Domy"lne testy pgbench

209

Definicja tabeli

210

Wykrywanie skali wielko&ci bazy danych

210

Definicja skryptu zapytania

211

Konfiguracja serwera bazy danych pod k#tem pgbench

213

R%czne uruchamianie pgbench

214

Wyniki graficzne generowane za pomoc' pgbench-tools

216

Konfiguracja pgbench-tools

216

Przyk#adowe wyniki testów pgbench

217

Test przeprowadzaj#cy jedynie zapytania SELECT

217

Test transakcji TPC-B-like

218

Analiza opó)nienia

219

Powody otrzymywania b#%dnych wyników i ró&nic

222

Programistyczne wersje PostgreSQL

223

W#tki worker i ograniczenia programu pgbench

224

W#asne testy pgbench

225

Test szybko&ci wstawiania danych

225

Testy wydajno"ci Transaction Processing Performance Council

226

Podsumowanie

228

Spis tre"ci

Rozdzia# 9. Indeksowanie bazy danych

229

Przegl'd sposobów indeksowania

230

Dane statystyczne s"u'#ce do pomiaru wielko&ci zapytania na dysku i bloku indeksu

230

Uruchomienie przyk"adu

231

Konfiguracja przyk"adowych danych

232

Proste wyszukiwania za pomoc# indeksów

233

Pe"ne skanowanie tabeli

234

Tworzenie indeksu

235

Wyszukiwanie za pomoc# nieefektywnego indeksu

235

*#czenie indeksów

237

Przej&cie ze skanowania indeksowanego na sekwencyjne

238

Klastry kontra indeksy

239

Polecenie Explain oraz liczniki bufora

241

Tworzenie indeksu i jego obs#uga

241

Zapewnienie unikalno&ci indeksów

242

Wspó"bie'ne 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 cz$&ciowe

249

Indeksy bazuj#ce na wyra'eniu

249

Indeksowanie na potrzeby wyszukiwania pe"nego tekstu

250

Podsumowanie

250

Rozdzia# 10. Optymalizacja zapyta(

253

Przyk#adowe zbiory danych

253

Pagila

254

Dell Store 2

254

Podstawy polecenia EXPLAIN

256

Obci#'enie zwi#zane z pomiarem

256

Zachowanie przy zimnym i rozgrzanym buforze

257

Struktura w%z#ów planu zapytania

259

Podstawy obliczania kosztu

260

Narz%dzia analizy danych polecenia EXPLAIN

262

Graficzne przedstawienie danych EXPLAIN

262

Rozbudowane dane wyj&ciowe

263

Dane wyj&ciowe EXPLAIN w postaci czytelnej dla komputera

263

Narz$dzia s"u'#ce 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 w%z#ów

268

W$ze" Sort

268

W$ze" Limit

270

W$ze" Aggregate

271

W$ze" HashAggregate

272

W$ze" Unique

273

W$ze" Result

274

W$ze" Append

275

W$ze" Group

276

W$z"y Subquery Scan i Subplan

277

Operacje ustawiania

278

Materializacja

279

Skanowanie CTE

280

Z#'czenia

281

P$tle zagnie'd'one

281

Z"#czenie Merge Join

283

Z"#czenia Hash Join

285

Dane statystyczne

290

Przegl#danie 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 pe"ni buforowanych zbiorów danych

300

Poszukiwanie odpowiednika zapytania

300

Wy"#czanie funkcji optymalizatora

301

Rozwi#zywanie b"$dów optymalizatora

305

Unikanie planu restrukturyzacji za pomoc# OFFSET

306

Zewn$trzne )ród"a problemów

309

Ograniczenia SQL

309

Numerowanie rekordów w SQL

309

U'ywanie funkcji Window do numerowania

311

U'ywanie funkcji Window do kumulowania wyniku

311

Podsumowanie

313

Spis tre"ci

Rozdzia# 11. Dane statystyczne i dzia#anie bazy danych

315

Widoki danych statystycznych

315

Widoki kumulacyjne i &ywe

317

Dane statystyczne tabel

318

Operacje wej&cia-wyj&cia tabel

320

Dane statystyczne indeksu

322

Operacje wej&cia-wyj&cia indeksu

323

Dane statystyczne dotycz'ce ca#ej bazy danych

324

Po#'czenia 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 u'yciem danych statystycznych dotycz#cych zapisu w tle

339

Podsumowanie

341

Rozdzia# 12. Monitorowanie i trendy

343

Narz%dzia monitoruj'ce w systemie Unix

343

Przyk"adowa konfiguracja

344

vmstat

344

iostat

347

top

355

sysstat i sar

357

Narz%dzia monitoruj'ce dla Windows

360

Mened'er 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 po#'cze( i buforowanie

371

Pula po#'cze(

371

Liczniki puli po"#cze(

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

Mened&ery kolejki replikacji

386

Slony

387

Londiste

387

Skalowanie odczytu za pomoc# oprogramowania replikacji bazuj#cego na kolejce

388

Wymagania aplikacji specjalnych

388

Bucardo

388

pgpool-II

389

Inne interesuj'ce projekty replikacji

389

Podsumowanie

391

Rozdzia# 15. Partycjonowanie danych

393

Partycjonowanie o zasi%gu tabeli

393

Okre&lenie pola klucza u'ywanego do partycjonowania

394

Wielko&ci 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 u'ywanej tabeli

401

Zapytania partycjonowane

403

Tworzenie nowych partycji

405

Zalety partycjonowania

406

B"$dy cz$sto pope"niane podczas partycjonowania

407

Partycjonowanie poziome za pomoc' PL/Proxy

408

Generowanie warto&ci hash

408

Skalowanie za pomoc# PL/Proxy

410

Skalowanie za pomoc# GridSQL

411

Podsumowanie

412

Rozdzia# 16. Unikanie najcz%"ciej spotykanych problemów

415

Operacja bulk-loading

415

Metody wczytywania danych

416

Optymalizacja operacji bulk-loading

417

Pomini$cie optymalizacji mechanizmu WAL

418

Spis tre"ci

Ponowne utworzenie indeksów i dodanie ogranicze(

419

Przywracanie równoleg"e

419

Czyszczenie po operacji wczytania danych

420

Najcz%stsze problemy zwi'zane z wydajno"ci'

421

Zliczanie rekordów

421

Niewyja&nione operacje zapisu

422

Wolne wykonywanie funkcji i polece( sk"adowanych

423

Testy wydajno&ci PL/pgSQL

424

Ogromne przeci#'enie klucza zewn$trznego

424

U'ycie pami$ci przez wyzwalacz

425

Ogromne przeci#'enie mechanizmu zbieraj#cego dane statystyczne

426

Zmaterializowane widoki

427

Profilowanie bazy danych

427

gprof

427

OProfile

428

Visual Studio

428

DTrace

428

Problemy wydajno"ci 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 zwyk$ym pliku teksto-
wym o nazwie postgresql.conf umieszczonym w strukturze katalogów bazy danych. Struktura
katalogów w systemach z rodziny Unix cz#sto okre'lana jest przy u(yciu zmiennej 'rodowi-
skowej

$PGDATA

, a wi#c 'cie(ka dost#pu 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 dost#pnej na stronie http://www.postgresql.
org/docs/current/static/runtime-config.html. Jednak tutaj, zamiast opisywania znaczenia ka(-
dego parametru, nacisk zosta$ po$o(ony na udzielenie wskazówek dotycz"cych ustawiania naj-
wa(niejszych warto'ci z perspektywy u(ytkownika zainteresowanego optymalizacj" wydajno'ci.
Rozdzia$ nale(y wi#c potraktowa) jako uzupe$nienie materia$u umieszczonego w oficjalnej
dokumentacji, a nie jej zamiennik.

Inne 1ród$o informacji na omawiany tutaj temat znajduje si# w artykule „Tuning Your PostgreSQL
Server” dost#pnym na stronie http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server,
w którym pewne informacje s" identyczne z przedstawionymi w rozdziale. Struktura artyku$u
wiki powoduje, (e jest on aktualizowany na bie("co i mo(e zawiera) pewne informacje doty-
cz"ce przysz$ych wersji bazy danych PostgreSQL, który by$y niedost#pne w trakcie przygoto-
wywania tego rozdzia$u.

Wysoko wydajny PostgreSQL 9.0

144

Interakcja z u&ywan' 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 niedost#pno'ci serwera jedynie z powodu
rutynowych zmian konfiguracyjnych, jak i zagwarantowania, (e czytelnik przeprowadza mody-
fikacj# w$a'ciwych parametrów, gdy zmiana ma zosta) wprowadzona natychmiast.

Ustawienia domy"lne i sposoby ich zerowania

Baza danych ma dwa rodzaje ustawie8, które mo(na okre'li) jako „ustawienia domy'lne”
w zale(no'ci od kontekstu. Jednym z nich s" ustawienia domy'lne powoduj"ce ustalenie przez
serwer pewnych warto'ci, je(eli u(ytkownik 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 warto'ci te mo(na sprawdzi) w kolumnie

boot_val

w widoku

pg_settings

. Wi#cej 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 warto'ci domy'lne, powrót do wspomnianych warto'ci domy'lnych nast#puje w wyniku
wydania polecenia

RESET

. Dzia$anie tego polecenia zosta$o omówione na stronie http://www.

postgresql.org/docs/current/static/sql-reset.html. Te warto'ci domy'lne mo(na przejrze)
w kolumnie

reset_val

znajduj"cej si# w widoku

pg_settings

Dozwolony kontekst do przeprowadzania zmian

Ka(de ustawienie konfiguracyjne ma powi"zany z nim kontekst, w ramach którego mo(e zosta)
zmienione. Najlepszym sposobem okre'lenia dozwolonego kontekstu do przeprowadzania zmian
jest bezpo'rednie zapytanie bazy danych. W przedstawionym poni(ej przyk$adzie pokazano po
jednym wpisie dla ka(dego rodzaju kontekstu (w rzeczywisto'ci po wydaniu poni(szego polece-
nia dane wyj'ciowe b#d" zawiera$y wszystkie parametry serwera):

Rozdzia% 6. • Optymalizacja konfiguracji serwera

145

W oficjalnym podr#czniku u(ytkownika pole kontekstu (

context

) nie jest zbyt dobrze udoku-

mentowane. Poni(ej przedstawiono wi#c znaczenie ró(nych stosowanych ustawie8 w kolejno'ci
od najtrudniejszego do naj$atwiejszego do zmiany.

internal

. Ustawienia te w du(ej mierze s" wewn#trznymi ustawieniami bazy

danych okre'lonymi w trakcie jej kompilacji. Wy'wietlane s" w celu dostarczenia
u(ytkownikowi informacji, ale nie mog" zosta) zmienione bez ponownej kompilacji
serwera.

postmaster

. Ustawienia s" uaktualniane jedynie podczas pe$nego uruchamiania serwera.

Do tej kategorii zaliczaj" si# wszystkie opcje dotycz"ce pami#ci wspó$dzielonej.

sighup

. Wys$anie sygna$u HUP do serwera spowoduje ponowne odczytanie pliku

konfiguracyjnego postgresql.conf, a wszelkie zmiany wprowadzone do tego parametru
b#d" natychmiast zastosowane. Wi#cej informacji na ten temat znajduje si# w kolejnym
punkcie zatytu$owanym „Ponowne wczytywanie pliku konfiguracyjnego”.

backend

. Ustawienia oznaczone za pomoc" tej w$a'ciwo'ci s" podobne do ustawie8

sighup

, z wyj"tkiem faktu, (e wprowadzone zmiany nie maj" wp$ywu na ju( istniej"ce

sesje bazy danych. Tylko sesje uruchomione po wprowadzeniu zmian b#d" stosowa$y
nowe ustawienia. Istnieje niewiele parametrów oznaczonych omawian" w$a'ciwo'ci",
wi#kszo') z nich wp$ywa jedynie na dzia$ania podejmowane w trakcie uruchamiania
i zamykania sesji. Ostatnia opcja tej grupy (

log_connections

) nie mo(e dzia$a) wstecz,

to znaczy nie ma mo(liwo'ci rozpocz#cia rejestrowania zdarze8 ju( nawi"zanego
po$"czenia. Zdarzenia b#d" rejestrowane tylko dla nowych po$"cze8 ustanowionych
po w$"czeniu opcji

log_connections

superuser

. Ustawienia tej grupy mog" by) modyfikowane w dowolnym momencie

przez ka(dego superu(ytkownika bazy danych (z regu$y u(ytkownika, który utworzy$
baz# danych, czyli bardzo cz#sto „postgres”). Aktywowanie zmiany nie wymaga
pe$nego, ponownego wczytania pliku konfiguracyjnego. Wi#kszo') ustawie8 tej grupy
jest powi"zana z rejestrowaniem w plikach dzienników zdarze8 ró(nych aspektów
polece8 wykonywanych przez serwer.

user

. Te parametry poszczególni u(ytkownicy mog" dostosowa) w dowolnym momencie

swojej sesji. Wprowadzone zmiany dotycz" jedynie danej sesji. Wi#kszo') parametrów
zmienia sposób wykonywania zapyta8, co pozwala na przeprowadzenie optymalizacji
w ramach sesji.

Na podstawie powy(szej sesji mo(na si# przekona), (e udzielenie odpowiedzi na — wyda-
wa$oby si# — proste pytanie, jaka jest bie("ca warto')

work_mem

, mo(e by) bardzo trudne,

w zale(no'ci od wybranego kontekstu. Pocz"tkowo warto') ta mo(e by) warto'ci" okre'lon"
w pliku konfiguracyjnym postgresql.conf, nast#pnie mo(e by) zmieniona w wyniku ponownego
wczytania konfiguracji, a na ko8cu znów zmieniona przez u(ytkownika przed wykonaniem
zapytania.

Wysoko wydajny PostgreSQL 9.0

146

Ponowne wczytywanie pliku konfiguracyjnego

Istniej" trzy sposoby pozwalaj"ce bazie danych na ponowne wczytanie konfiguracji w celu
uaktualnienia warto'ci zaliczaj"cych si# do grupy

sighup

. Je(eli czytelnik jest po$"czony z baz"

danych jako superu(ytkownik, mo(na u(y) funkcji

pg_reload_conf()

w nast#puj"cy sposób:

postgres=# SELECT pg_reload_conf();
pg_reload_conf
----------------
t

Sygna$

SIGHUP

mo(na wys$a) równie( r#cznie 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

mo(na wysy$a) do serwera przy u(yciu narz#dzia

pg_ctl

$ pg_ctl reload
server signaled

Niezale(nie od u(ytego sposobu, po wys$aniu sygna$u

SIGHUP

w dziennikach zdarze8 bazy danych

znajdzie si# nast#puj"cy komunikat:

LOG: received SIGHUP, reloading configuration files

Nast#pnie, za pomoc" polece8, takich jak

SHOW

, lub po przejrzeniu widoku

pg_settings

mo(na

potwierdzi), (e zmiany zosta$y wprowadzone zgodnie z oczekiwaniami.

Umieszczanie ustawie% w komentarzach

Co si# stanie w sytuacji, gdy pewien parametr zosta$ r#cznie ustawiony, ale musi by) wy$"-
czony w dzia$aj"cym serwerze? Konkretna odpowied1 zale(y od wersji u(ywanego serwera.
Przyjmijmy za$o(enie, (e plik postgresql.conf zosta$ uruchomiony wraz z ustawionym nast#-
puj"cym parametrem:

checkpoint_segments = 30

W celu wy$"czenia tego parametru trzeba wyedytowa) plik konfiguracyjny, a parametr umie'ci)
w komentarzu:

#checkpoint_segments = 30

Nast#pnie 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 warto'ci domy'lnej serwera (

boot_val

). W wersji 9.0 w dzien-

niku zdarze8 zostanie ponadto umieszczony nast#puj"cy komunikat:

LOG: received SIGHUP, reloading configuration files
LOG: parameter "checkpoint_segments" removed from configuration file, reset
to default

U(ycie warto'ci domy'lnej mo(na potwierdzi) za pomoc" polecenia

SHOW

$ psql -x -c "show checkpoint_segments"
-[ RECORD 1 ]-------+--
checkpoint_segments | 3

Je(eli u(ywany serwer to PostgreSQL w wersji 8.2 lub wcze'niejszej, wprowadzona zmiana nie
spowoduje (adnego efektu, to znaczy parametr

checkpoint_segments

nadal b#dzie mia$ war-

to') 30. Dopiero po pe$nym, ponownym uruchomieniu serwera nast"pi przywrócenie warto'ci
domy'lnej, czyli 3.

Poniewa( takie zachowanie jest skomplikowane i uzale(nione od u(ywanej wersji serwera,
do'wiadczeni administratorzy PostgreSQL zwykle dwukrotnie sprawdzaj" parametry, które
maj" zamiar zmodyfikowa). Do sprawdzenia u(ywaj" 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 mo(liwo') do$"czenia dodatkowych plików
konfiguracyjnych z poziomu g$ównego pliku postgresql.conf. W przypadku takiego rozwi"zania
skutek jest taki sam jak wstawienie zawarto'ci okre'lonego pliku we wskazanym miejscu.
W widoku

pg_settings

mo(na pozna) nazw# pliku, z którego pochodzi dany parametr, wraz

z numerem wiersza zawieraj"cego aktywn" wersj#. Warto te( pami#ta), (e w przypadku wielo-
krotnego ustawiania tego samego parametru pod uwag# zawsze brane jest tylko ostatnie jego
wyst"pienie.

Ustawienia na poziomie serwera

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

Po&'czenia z baz' danych

Istnieje wiele parametrów konfiguracyjnych okre'laj"cych sposoby zdalnego i lokalnego nawi"-
zywania po$"czenia z baz" danych. Pe$na lista wspomnianych parametrów zosta$a przedstawiona
na stronie http://www.postgresql.org/docs/current/static/runtime-config-connection.html.

Wysoko wydajny PostgreSQL 9.0

148

listen_addresses

W ka(dej instalacji wymagaj"cej obs$ugi po$"cze8 pochodz"cych z systemów zdalnych konieczna
jest modyfikacja parametru

listen_addresses

pozwalaj"cego na obs$ug# takich po$"cze8. Domy'l-

nie dozwolone s" jedynie po$"czenia lokalne pochodz"ce od u(ytkownika zalogowanego do
tego samego systemu, w którym znajduje si# baza danych. Powszechnie stosowanym podej'ciem
jest akceptacja po$"cze8 przychodz"cych z ka(dego miejsca. W tym celu w g$ównym pliku
konfiguracyjnym trzeba umie'ci) poni(szy wiersz:

listen_addresses = '*'

Aby kontrolowa), kto mo(e nawi"za) po$"czenie, trzeba przeprowadzi) konfiguracj# pliku
pg_hba.conf, co zosta$o omówione na stronie http://www.postgresql.org/docs/current/static/
auth-pg-hba-conf.html. Stosowanie takiego podej'cia wi"(e si# z pewnym problemem doty-
cz"cym wydajno'ci. Filtrowanie po$"cze8 za pomoc" dok$adniej skonfigurowanego parametru

listen_addresses

mo(e by) znacznie bardziej efektywne ni( pozwolenie na nawi"zanie po$"-

czenia wszystkim klientom. Zezwolenie klientowi na po$"czenie, a nast#pnie jego odrzucenie
w wyniku wpisu znajduj"cego si# w pliku konfiguracyjnym pg_hba.conf powoduje niepotrzebne
zu(ycie pewnych zasobów serwera i nara(a system na niebezpiecze8stwo przeprowadzenia
w ten sposób ataku typu odmowa us$ugi — DoS (ang. Denial Of Service) — przez z$o'liwego
u(ytkownika.

W praktyce tylko niewielka liczba serwerów PostgreSQL pozwala na bezpo'rednie przyjmo-
wanie zapyta8 pochodz"cych z internetu. Normalnie s" one filtrowane przez port domy'lny
PostgreSQL (5432) na poziomie zapory sieciowej, co stanowi najefektywniejsze podej'cie i jest
cz#sto stosowan" implementacj" mechanizmu wspó$dzielonej ochrony tak(e innych aplikacji.
W systemie pod$"czonym do internetu, takim jak na przyk$ad klastry zawieraj"ce bazy danych
dla us$ug „w chmurach”, nale(y upewni) si# o stosowaniu wszystkich trzech warstw ochrony. Na
poziomie zapory sieciowej warto okre'li), kto mo(e nawi"za) po$"czenie z serwerem, dodatkowo
zmniejszy) list# nas$uchiwanych adresów za pomoc" opcji

listen_addresses

, a tak(e ograniczy)

u(ytkownikom dost#p do bazy danych za pomoc" pliku konfiguracyjnego pg_hba.conf.

max_connections

Jednym z parametrów, dla którego czytelnik najcz#'ciej b#dzie ustawia$ warto') (z regu$y 100)
w pliku konfiguracyjnym postgresql.conf wygenerowanym przez

initdb

, jest

max_connections

Poniewa(, jak wspomniano w poprzednim rozdziale, ka(de po$"czenie wykorzystuje niewielk"
ilo') pami#ci wspó$dzielonej, w systemach domy'lnie u(ywaj"cych niewielkiej ilo'ci pami#ci
wspó$dzielonej nawi"zanie wi#kszej ilo'ci po$"cze8 nie zostanie nawet dozwolone. W zwi"zku
z powy(szym, podobnie jak w przypadku parametru

shared_buffers

, po utworzeniu klastra

bazy danych i okre'leniu w domy'lnym pliku konfiguracyjnym najwi#kszej dopuszczalnej war-
to'ci (do 100) przeprowadzane s" pewne badania. W praktyce ilo') pami#ci niewspó$dzielonej
u(ywanej przez ka(dego klienta podczas przeprowadzania operacji, takich jak sortowanie, jest
wprawdzie znacznie wi#ksza, ale ilo'ci wykorzystywanej pami#ci wspó$dzielonej nie mo(na
pomin").

Rozdzia% 6. • Optymalizacja konfiguracji serwera

149

Wa(ne jest, aby w tym parametrze nie ustawia) warto'ci wy(szej ni( konieczna. Istnieje wiele
wad wynikaj"cych z ustawienia wy(szej warto'ci parametru

max_connections

. Jedna z nich to

marnowanie pami#ci wspó$dzielonej, ale to problem, którym nale(y si# najmniej przejmowa),
poniewa( ilo') pami#ci wspó$dzielonej wykorzystywanej przez ka(de po$"czenie pozostaje
niewielka.

Jednak s" inne zasoby wykorzystywane przez klienta, na przyk$ad alokacja pami#ci dla operacji
sortowania (kontrolowana za pomoc" parametru

work_mem

omówionego dalej, w tym rozdziale),

która z regu$y obejmuje ogromny blok pami#ci. Je(eli dozwolona b#dzie obs$uga wi#kszej liczby
po$"cze8, to by bezpiecznie oszcz#dza) pami#), trzeba równie( zmniejszy) warto'ci wspomnia-
nych ustawie8, tak aby zminimalizowa) niebezpiecze8stwo alokacji wi#kszej ilo'ci pami#ci ni(
dost#pna.

Ze wzgl$du na problemy zwi*zane z alokacj* zasobów, serwery PostgreSQL w Windows mog* mie1
bardzo ograniczon* liczb$ obs2ugiwanych po2*cze4. Bardzo cz$sto zdarza si$, 7e zanim wyczerpana zosta-
nie pami$1 w obszarze Desktop Heap, obs2u7onych b$dzie jedynie oko2o 125 po2*cze4. Wi$cej informa-
cji na temat tego problemu oraz potencjalne sposoby jego rozwi*zania mo7na znale?1 na stronie

http://wiki.postgresql.org/wiki/Running_&_Installing_PostgreSQL_On_Native_Windows

Wreszcie, nawi"zywanie po$"cze8 w bazie danych PostgreSQL nale(y uwa(a) za operacj#
intensywnie wykorzystuj"c" zasoby. Celem bazy danych nie jest dzia$alno') w charakterze
komponentu nawi"zuj"cego po$"czenie z baz" danych, przeprowadzaj"cego uwierzytelnianie
i dotarcie do punktu, w którym zapytanie b#dzie wykonane jako stosunkowo niewielka operacja.
Ogólnie rzecz ujmuj"c, obci"(enie zwi"zane z nawi"zaniem kilkuset po$"cze8 staje si# w"skim
gard$em podczas dzia$ania serwera. Dok$adna liczba po$"cze8, po przekroczeniu której staj"
si# one obci"(eniem, zale(y od u(ywanego sprz#tu i konfiguracji serwera. Je(eli czytelnik ma
zamiar obs$ugiwa) jednocze'nie tysi"ce zapyta8, nie mo(e zastosowa) podej'cia, w którym
ka(dy klient bezpo'rednio nawi"zuje po$"czenie z baz" danych. W takim przypadku najcz#'ciej
stosowanym rozwi"zaniem problemu skalowalno'ci jest u(ycie oprogramowania obs$uguj"cego
pul# po$"cze8 mi#dzy aplikacj" i baz" danych. Temat ten zosta$ omówiony w rozdziale 13.

Pami*+ wspó&dzielona

W$a'ciwe ustawienie warto'ci parametrów zwi"zanych z pami#ci" wspó$dzielon" jest wa(ne,
poniewa( ich zmiana zawsze wymaga pe$nego, ponownego uruchomienia serwera bazy
danych — serwer nie ma mo(liwo'ci dynamicznej ponownej alokacji pami#ci 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)

Przestrze8 pozosta$a w wyniku operacji usuwania b"d1 modyfikacji danych jest umieszczana
przez polecenie

VACUUM

w przestrzeni FSM (ang. Free Space Map). Nowe operacje alokacji

wykorzystuj" przestrze8 pochodz"c" z FSM, zamiast alokowa) now" przestrze8 na dysku.

Od wydania PostgreSQL 8.4 przestrze8 FSM jest przechowywana na dysku, a tym samym
automatycznie skaluje swoj" wielko'). W PostgreSQL do wersji 8.3 przestrze8 FSM by$a
przechowywana w pami#ci wspó$dzielonej, co wymaga$o dok$adnego monitorowania ilo'ci tej
pami#ci i potencjalnie prowadzi$o do zwi#kszenia jej zu(ycia. Upewnienie si#, (e warto'ci para-
metrów

max_fsm_pages

max_fsm_relations

w pliku konfiguracyjnym s" wystarczaj"ce, powinno

by) cz#'ci" regularnych operacji konserwacyjnych w tych wersjach serwera PostgreSQL. Ope-
racj# t# mo(na przeprowadzi) r#cznie b"d1 wyda) polecenie

VACUUM

VERBOSE

przeprowadzaj"ce

pomiar bie("cego u(ycia pami#ci wspó$dzielonej w bardziej zautomatyzowany sposób. Wi#cej
informacji na ten temat przedstawiono w rozdzia$ach 5. i 7.

Rejestrowanie zdarze%

Ogólne ustawienia dotycz"ce rejestracji zdarze8 s" wa(ne, ale w pewnym sensie pozostaj" poza
zakresem tematycznym tej ksi"(ki. Czytelnik mo(e by) zmuszony do ustawienia parametrów,
takich jak

log_destination

log_directory

log_filename

, w sposób zgodny z systemem oraz

wymaganiami administratora u(ywanego 'rodowiska. Parametry te maj" domy'lnie ustawione
rozs"dne warto'ci pozwalaj"ce na rozpocz#cie pracy w wi#kszo'ci systemów. W rozdziale 7.
zostanie poruszony problem dostosowania omawianych parametrów w celu przeprowadzenia
rejestracji zdarze8 w plikach CSV, co mo(e by) u(yteczne podczas pomiaru czasu wykonywania
zapyta8.

W wi#kszo'ci systemów Unix bardzo cz#sto zdarza si#, (e opcje dotycz"ce rejestracji zdarze8
bazy danych s" ustawiane w skryptach uruchamiaj"cych i zatrzymuj"cych serwer, a nie bezpo-
'rednio w pliku konfiguracyjnym postgresql.conf. Je(eli w celu r#cznego uruchomienia ser-
wera stosowane jest polecenie

pg_ctl

, czytelnik mo(e odkry), (e rejestracja zdarze8 nast#puje

poprzez ich bezpo'rednie wy'wietlenie na ekranie. W takim przypadku, aby dowiedzie) si#,
o co chodzi, trzeba spojrze) do skryptu uruchamiaj"cego serwer w zwyk$y sposób (najcz#'ciej
/etc/init.d/postgresql). W wi#kszo'ci przypadków do polecenia

pg_ctl

wystarczy doda) opcj#

-l

nazwa_pliku

, która powoduje przekierowanie danych wyj'ciowych do standardowego po$o(enia.

log_line_prefix

Warto') domy'lna opcji

log_line_prefix

jest pusta, a to zdecydowanie niepo("dane. Warto')

dobra na pocz"tek b#dzie mia$a nast#puj"c" posta):

log_line_prefix='%t:%r:%u@%d:[%p]: '

Rozdzia% 6. • Optymalizacja konfiguracji serwera

151

Powy(szy parametr powoduje umieszczenie w ka(dym wierszu dziennika zdarze8 takich infor-
macji jak:

: znacznik czasu;

: nazwa u(ytkownika bazy danych;

: nazwa zdalnego komputera, z którego nawi"zano po$"czenie;

: nazwa bazy danych, z któr" nawi"zano po$"czenie;

: identyfikator procesu po$"czenia.

Na pocz"tku mo(e nie by) takie oczywiste, po co zosta$y zastosowane powy(sze warto'ci
domy'lne, a zw$aszcza identyfikator procesu. Jednak po próbie rozwi"zania kilku problemów
zwi"zanych z wydajno'ci" konieczno') zapisania w pliku dziennika zdarze8 wymienionych
informacji stanie si# bardziej oczywista i czytelnik b#dzie zadowolony z faktu posiadania tych
informacji.

Inne podej'cie warte rozwa(enia to ustawienie warto'ci parametru

log_line_prefix

w taki

sposób, aby dzienniki zdarze8 by$y zgodne z programem pgFouine, omówionym w rozdziale 7.
Jest to rozs"dny, przeznaczony do ogólnego rejestrowania zdarze8 prefiks, a wiele witryn i tak
ostatecznie stosuje pewne mechanizmy analizy zapyta8.

log_statement

Oto opcje do zastosowania w tym parametrze:

none

. Nie s" rejestrowane (adne informacje na poziomie polece8.

ddl

. Rejestrowane s" jedynie polecenia DDL (ang. Data Definition Language),

na przyk$ad

CREATE

lub

DROP

. Takie ustawienie mo(na zastosowa) nawet w systemie

produkcyjnym i jest przydatne podczas wychwytywania najwa(niejszych zmian
przypadkowo lub celowo wprowadzonych przez administratorów.

mod

. Rejestrowane s" wszystkie polecenia modyfikuj"ce warto'), czyli praktycznie

wszystkie, poza prostymi poleceniami

SELECT

. Je(eli obci"(enie w serwerze to

przede wszystkim polecenia

SELECT

przeprowadzaj"ce niewielk" ilo') zmian w danych,

praktycznym rozwi"zaniem mo(e by) pozostawienie tej opcji w$"czonej przez ca$y czas.

all

. Rejestrowane s" wszystkie polecenia. Ogólnie rzecz ujmuj"c, pozostawienie tej

opcji w$"czonej w serwerze produkcyjnym jest niepraktyczne, ze wzgl#du na obci"(enie
powodowane przez operacj# rejestrowania zdarze8. Gdy jednak serwer jest na tyle
pot#(ny, aby poradzi) sobie z takim obci"(eniem, pozostawienie tej opcji w$"czonej
przez ca$y czas mo(e okaza) si# pomocne.

Rejestrowanie polece8 to u(yteczna technika pozwalaj"ca na wyszukiwanie problemów zwi"-
zanych z wydajno'ci". Analiza informacji zebranych po ustawieniu parametru

log_statement

i powi"zanych 1róde$ informacji szczegó$owych na poziomie polece8 mo(e ukaza) prawdziw"
przyczyn# wielu rodzajów problemów wydajno'ci. Zebrane w ten sposób informacje mo(na
po$"czy) z odpowiednimi narz#dziami 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, u(ycie parametru

log_min_duration_statement

pozwoli na rejestrowanie tylko tych polece8, których wykonanie

przekroczy ustalony czas. Warto') jest podawana w milisekundach, tak wi#c parametr mo(na
ustawi) w nast#puj"cy sposób:

log_min_duration_statement=1000

Powy(sze polecenie powoduje rejestracj# w dzienniku zdarze8 tylko polece8 wykonywanych
d$u(ej ni( sekund#. Parametr mo(e by) u(yteczny do wyszukiwania 1róde$ „odstaj"cych” pole-
ce8, których wykonanie trwa znacznie d$u(ej ni( pozosta$ych.

Je(eli u(ywany jest PostgreSQL w wersji 8.4 lub nowszej, zamiast tej funkcji preferowanym
rozwi"zaniem mo(e by) modu$

auto_explain

. Wi#cej informacji na temat modu$u mo(na zna-

le1) na stronie http://www.postgresql.org/docs/8.4/static/auto-explain.html. Modu$ umo(liwia
sprawdzenie operacji wykonywanych przez powolne zapytania po przejrzeniu powi"zanych
z nimi planów

EXPLAIN

Polecenie VACUUM i dane statystyczne

Baza danych PostgreSQL wymaga dwóch podstawowych form regularnej obs$ugi podczas doda-
wania, uaktualniania i usuwania danych.

Polecenie

VACUUM

powoduje usuni#cie 'mieci po starych transakcjach, $"cznie z usuni#ciem

informacji, które nie s" d$u(ej widoczne, oraz zwrócenie zwolnionego miejsca, tak aby mog$o
by) ponownie wykorzystane. Im wi#cej w bazie danych wykonywanych polece8

UPDATE

DELETE

tym cz#'ciej 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

przegl"da tabele w bazie danych i zbiera na ich temat dane statystyczne —

informacje, takie jak liczba posiadanych rekordów b"d1 liczba odmiennych warto'ci w tabelach.
Wiele aspektów planowania zapytania zale(y od prawid$owego zebrania tych danych.

Wi#cej 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 d$u(szej perspektywie znaczenie krytyczne dla bazy
danych, od wydania PostgreSQL 8.1 w serwerze umieszczono demon

autovacuum

, który dzia$a

w tle i zajmuje si# wspomnianym zadaniem. Aktywacja demona nast#puje po wykonaniu w bazie
danych liczby zmian przekraczaj"cej warto') obliczon" na podstawie wielko'ci tabeli.

Rozdzia% 6. • Optymalizacja konfiguracji serwera

153

Parametr dla demona

autovacuum

jest w$"czony domy'lnie w PostgreSQL 8.3, a warto') domy'lna

jest ustalona w sposób wystarczaj"cy do dzia$ania mniejszej bazy danych i wymaga jedynie
niewielkiej r#cznej modyfikacji. Ogólnie rzecz bior"c, trzeba uwa(a), aby ilo') danych w obsza-
rze FSM nie przekracza$a warto'ci ustalonej przez parametr

max_fsm_pages

. Od PostgreSQL 8.4

opisane wymaganie nie stanowi ju( powodu do zmartwie8 dla u(ytkownika.

W&'czanie demona autovacuum w starszych wersjach

Je(eli demon

autovacuum

jest dost#pny, ale nie jest w$"czony domy'lnie, jak ma to miejsce

w bazach danych PostgreSQL 8.1 i 8.2, istnieje kilka powi"zanych z nim parametrów, które
musz" by) w$"czone w celu zapewnienia jego prawid$owej pracy. Wi#cej 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 ostrze(eniem przedstawionym w dokumentacji — zale-
cane jest równie( u(ycie parametru

superuser_reserved_connections

zezwalaj"cego na dzia$a-

nie demonów

autovacuum

w wymienionych wersjach bazy danych.

Demon

autovacuum

dost#pny w wersjach 8.1 i 8.2 nie jest a( tak wydajny jak dostarczany

w wersjach 8.3 i nowszych. Uzyskanie odpowiedniego balansu zapewniaj"cego prawid$ow"
obs$ug# bazy danych bez zbyt du(ego obci"(enia serwera b#dzie wymaga$o pewnych ekspery-
mentów i dopasowywania warto'ci. Poniewa( jest to tylko jeden proces, pozostawienie go, by
dzia$a$ w tle, gdy serwer jest zaj#ty, b#dzie mniejszym obci"(eniem dla serwera. Zagadnienie to
nie b#dzie tutaj obszernie omawiane. Ogólnie rzecz bior"c, znacznie lepszym rozwi"zaniem
jest po'wi#cenie czasu na uaktualnienie bazy danych PostgreSQL do wydania zawieraj"cego
nowsz" wersj# demona

autovacuum

ni( próba dostosowania starszej wersji. Szczególnie dotyczy

to sytuacji, kiedy równocze'nie wyst#puj" inne problemy z wydajno'ci", których nie mo(na tak
$atwo rozwi"za) w starszej wersji serwera.

maintenance_work_mem

Kilka operacji w serwerze bazy danych wymaga pami#ci roboczej dla operacji wi#kszych ni(
zwyk$e sortowanie. Polecenia

VACUUM

CREATE INDEX

oraz

ALTER TABLE ADD FOREIGN KEY

mog"

alokowa) maksymaln" ilo') pami#ci okre'lon" przez parametr

maintenance_work_mem

. Jest ma$o

prawdopodobne, aby wiele sesji przeprowadza$o jednocze'nie tego rodzaju operacje. Dla tego
parametru mo(na okre'li) warto') znacznie wy(sz" ni( w standardowej opcji

work_mem

ustawia-

nej dla ka(dego klienta. Warto pami#ta), (e przynajmniej parametr

autovacuum_max_workers

Wysoko wydajny PostgreSQL 9.0

154

(dla którego od wersji 8.3 warto') domy'lna wynosi 3) zaalokuje t# ilo') pami#ci, dlatego te(
podczas okre'lania tej warto'ci nale(y uwa(a) na takie sesje (prawdopodobnie z jedn" lub
dwiema sesjami wykonuj"cymi operacj#

CREATE INDEX

Przy za$o(eniu, (e liczba demonów

autovacuum

nie zosta$a zwi#kszona, typowe wysokie ustawienie

omawianej warto'ci w nowoczesnym serwerze b#dzie mia$o warto') 5% ca$kowitej ilo'ci pami#ci
RAM. Tak wi#c nawet pi#) procesów nie wykorzysta wi#cej ni( jedn" czwart" dost#pnej pami#ci
RAM. Oznacza to, (e

maintenance_work_mem

wykorzystuje oko$o 50 MB pami#ci na ka(dy dost#pny

gigabajt pami#ci RAM w serwerze.

default_statistics_target

PostgreSQL podejmuje decyzje dotycz"ce sposobu wykonywania zapyta8 na podstawie danych
statystycznych zebranych dla ka(dej tabeli i przechowywanych w bazie danych. Tego rodzaju
informacje s" zbierane podczas analizy tabel za pomoc" polecenia

ANALYZE

lub demona

autovacuum

. W ka(dym przypadku ilo') informacji zbierana w trakcie analizy jest okre'lana przez

parametr

default_statistics_target

. Zwi#kszenie warto'ci tego parametru wyd$u(a analiz#.

Analiza regularnie przeprowadzana przez demon

autovacuum

w tle stanowi coraz wi#ksze obci"-

(enie podczas konserwacji bazy danych. Jednak brak odpowiednich danych statystycznych
dotycz"cych tabeli skutkuje ryzykiem u(ycia niew$a'ciwego planu wykonywania zapyta8
wzgl#dem tej tabeli.

Warto') domy'lna wymienionej opcji z regu$y jest bardzo niska (to znaczy 10), ale w Postgre-
SQL 8.4 zosta$a zwi#kszona do 100. Stosowanie wi#kszej warto'ci by$o popularne tak(e w star-
szych wersjach bazy danych w celu ogólnego poprawienia zachowania zapyta8. Indeksy korzy-
staj"ce z operatora

dzia$aj" znacznie lepiej, gdy opisywany parametr ma warto') wy(sz" ni(

100, a nie ni(sz", co wi"(e si# ze zdefiniowan" na sta$e zmian" sposobu ich dzia$ania po u(yciu
warto'ci wi#kszej ni( 100 dla tego parametru.

Warto zwróci) uwag#, (e zwi#kszenie warto'ci parametru

default_statistics_target

skutkuje

ogólnym spowolnieniem systemu, je(eli 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 wydajno'ci pokazuj", (e baza danych PostgreSQL w wersji 8.4 jest nieco wolniejsza
od 8.3, je(eli obie stosuj" warto'ci domy'lne parametrów. W niektórych przypadkach po insta-
lacji wersji 8.4 mo(na zmniejszy) warto') wymienionego parametru. Ustawianie wyj"tkowo
du(ej warto'ci parametru

default_statistics_target

jest odradzane, ze wzgl#du na generowane

wówczas ogromne obci"(enie dla bazy danych.

Je(eli w tabeli znajduje si# kolumna, o której wiadomo, (e potrzebuje lepszych danych staty-
stycznych, mo(na wzgl#dem tej kolumny wykona) polecenie

ALTER TABLE SET STATISTICS

w celu dostosowania dla niej warto'ci parametru. Takie rozwi"zanie jest lepsze ni( zwi#kszanie
warto'ci domy'lnej parametru dla ca$ego systemu, gdy( wtedy ka(da tabela „p$aci” za wymaganie
jednej kolumny w bazie danych. Zazwyczaj kolumny wymagaj"ce do prawid$owej pracy naprawd#
du(ej ilo'ci danych statystycznych musz" mie) warto') parametru

default_statistics_target

równ" 1000 (w nowszych wersjach PostgreSQL zwi#kszono j" do 10000), aby zmiana by$a

Rozdzia% 6. • Optymalizacja konfiguracji serwera

155

widoczna. Jest to warto') du(o wi#ksza ni( ilo') danych statystycznych konieczna do zebrania
w ka(dej tabeli bazy danych.

Punkty kontrolne

Sposób dzia$ania mechanizmu punktów kontrolnych i dotycz"ce go parametry przedstawiono
w poprzednim rozdziale. W tym miejscu nacisk po$o(ono na powszechnie stosowane praktyki
ustawiania warto'ci pocz"tkowych dla tych parametrów.

checkpoint_segments

Ka(dy 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 mo(e by) w u(yciu w danym momencie, mo(na obliczy) ze wzoru:

(2 + checkpoint_completion_target) * checkpoint_segments + 1

Warto zwróci) uwag#, (e baza danych PostgreSQL w wersjach wcze'niejszych ni( 8.3 nie obs$u-
guje rozproszonych punktów kontrolnych, ale nadal mo(na u(y) powy(szego wzoru i po prostu
dla brakuj"cej warto'ci wykorzysta) poni(szy fragment kodu:

checkpoint_completion_target=0

Wynik to ca$kowita wielko') wszystkich segmentów mechanizmu WAL, które mog" znale1)
si# na dysku. Pozwala to zarówno na ustalenie ilo'ci zajmowanego miejsca na dysku twardym,
jak i oszacowanie ilo'ci czasu potrzebnego na przeprowadzenie naprawy po awarii bazy danych.
Oczekiwany wzrost wielko'ci dziennika zdarze8

pg_xlog

zosta$ przedstawiony w poni(szej

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 mo(na wyci"gn") na podstawie przedstawionych tutaj danych, jest nast#-
puj"cy: na ka(de 32 segmenty punktów kontrolnych trzeba si# liczy) z akumulacj" oko$o 1 GB
danych mechanizmu WAL. Poniewa( w przypadku takiej ilo'ci danych naprawa bazy danych
po awarii mo(e zaj") sporo czasu, warto') 32 to najwi#ksza, jak" warto zastosowa) w powa(nym,
produkcyjnym serwerze bazy danych. Warto') domy'lna 3 jest jednak dla wi#kszo'ci systemów
stanowczo za ma$a, nawet w niewielkich instalacjach nale(y rozwa(y) jej zwi#kszenie do 10.

Wysoko wydajny PostgreSQL 9.0

156

Warto') wi#ksz" ni( 32 stosuje si# zazwyczaj tylko w mniejszych serwerach przeprowadzaj"cych
operacje typu bulk-loading, poniewa( mo(e to znacznie zwi#kszy) wydajno'), a czas naprawy
bazy danych po ewentualnej awarii jest nieistotny. Bazy danych, które regularnie przeprowadzaj"
operacje bulk-loading, mog" wymaga) wi#kszej warto'ci parametru

checkpoint_segments

checkpoint_timeout

Warto') domy'lna tego parametru wynosz"ca 5 minut jest wystarczaj"ca dla wi#kszo'ci instalacji.
Je(eli system nie nad"(a z operacjami zapisu i zwi#kszono warto') parametru

checkpoint_

segments

w taki sposób, (e parametr

checkpoint_timeout

sta$ si# podstawowym sposobem

inicjowania operacji tworzenia punktu kontrolnego, rozs"dne b#dzie rozwa(enie zwi#kszenia
warto'ci tak(e dla parametru

checkpoint_timeout

. Ustalenie przerwy w d$ugo'ci dziesi#ciu

minut lub nawet wi#cej mi#dzy tworzeniem punktów kontrolnych nie jest niebezpieczne, po
prostu wyd$u(a czas naprawy bazy danych po ewentualnej awarii. Poniewa( jest to jeden
z parametrów, które maj" wp$yw na d$ugo') czasu niedost#pno'ci bazy danych po awarii, jego
warto') nale(y ustawia) bardzo ostro(nie.

checkpoint_completion_target

Po zwi#kszeniu warto'ci parametru

checkpoint_segments

do przynajmniej 10 rozs"dne wydaje

si# równie( zwi#kszenie warto'ci parametru

checkpoint_competion_target

do jego praktycznego

maksimum wynosz"cego 0,9. W ten sposób uzyskiwane jest maksymalne rozproszenie punktów
kontrolnych, co przynajmniej teoretycznie oznacza mniejsze obci"(enie zwi"zane z operacjami
wej'cia-wyj'cia. Jednak w niektórych sytuacjach utrzymywanie warto'ci domy'lnej 0,5 nadal
b#dzie lepszym rozwi"zaniem, poniewa( zmniejsza prawdopodobie8stwo, (e operacje zapisu
jednego punktu kontrolnego zaz#bi" si# z operacjami drugiego.

Wydaje si# nieprawdopodobne, aby warto') poni(ej 0,5 by$a w ogóle efektywna dla rozpra-
szania punktów kontrolnych. Co wi#cej, o ile liczba segmentów nie jest naprawd# ogromna, ma$e
zmiany warto'ci parametru maj" niewielkie znaczenie. Jedyne sensowne podej'cie polega na
wypróbowaniu obu warto'ci (0,5 i 0,9) w aplikacji i sprawdzeniu na poziomie monitorowania
systemu operacyjnego, która powoduje mniejsze obci"(enie zwi"zane z operacjami wej'cia-
-wyj'cia.

Ustawienia mechanizmu WAL

Mechanizm WAL (ang. Write-Ahead Log) u(ywany w PostgreSQL zosta$ omówiony w rozdziale 5.

wal_buffers

Dokumentacja parametru

wal_buffers

sugeruje, (e warto') domy'lna wynosz"ca 64 kB jest

wystarczaj"ca tak d$ugo, dopóki pojedyncza transakcja nie przekracza wymienionej warto'ci.

Rozdzia% 6. • Optymalizacja konfiguracji serwera

157

Jednak w praktyce testy wydajno'ci intensywnie wykorzystuj"ce operacje zapisu pokazuj", (e
optymaln" wydajno') mo(na osi"gn") po ustawieniu znacznie wi#kszej warto'ci, co najmniej
1 MB lub wi#cej. Jedyn" wad" jest zwi#kszony poziom wykorzystania pami#ci wspó$dzielonej.
Bior"c po uwag#, (e nie ma potrzeby, aby wi#cej ni( pojedynczy segment WAL musia$ by) bufo-
rowany, a tak(e ilo') pami#ci instalowan" w nowoczesnych serwerach, parametrowi

wal_buffers

mo(na obecnie przydzieli) znacznie wi#ksz" warto'):

wal_buffers=16MB

Po ustawieniu powy(szej warto'ci mo(na zapomnie) o parametrze

wal_buffers

jako poten-

cjalnym w"skim gardle lub komponencie, który pó1niej trzeba optymalizowa). W przypadku
niewielkiej ilo'ci pami#ci w serwerze mo(na rozwa(y) u(ycie mniejszej warto'ci.

wal_sync_method

W rozdziale 2. wyja'niono, jak wa(ne jest skonfigurowanie serwera w taki sposób, aby unika$
wykorzystywania nietrwa$ych buforów zapisu. Jednym z celów parametru

wal_sync_method

jest

optymalizacja zachowania podczas korzystania z nietrwa$ych buforów zapisu.

Zachowanie domy'lne jest w pewien sposób odmienne od wi#kszo'ci opcji. Podczas kompilacji
kodu 1ród$owego serwera rozwa(ane s" ró(ne mo(liwe sposoby zapisu. Jeden, uznany za naj-
bardziej efektywny, staje si# pó1niej stosowany domy'lnie 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 warto'ci,
takich jak

shared_buffers

Przed zmian" czegokolwiek nale(y za pomoc" polecenia

SHOW

sprawdzi), co w u(ywanej przez

czytelnika platformie zosta$o wykryte jako najszybsza, bezpieczna metoda. W systemie Linux
wynik jest nast#puj"cy:

postgres=# show wal_sync_method;
wal_sync_method
-----------------
fdatasync

Z kolei na platformach Windows i Mac OS X istnieje specjalny parametr gwarantuj"cy, (e
system operacyjny wyczy'ci wszystkie bufory zapisu. Na wspomnianych platformach warto'ci"
bezpieczn", która w$"cza takie zachowanie, jest:

wal_sync_method=fsync_writethrough

Je(eli ustawienie takie jest dost#pne, naprawd# nale(y je wykorzysta)! Pracuje ono prawi-
d$owo i gwarantuje wykonywanie bezpiecznych operacji zapisu w bazie danych bez spowal-
niania innych aplikacji, co ma miejsce w przypadku ca$kowitego wy$"czenia bufora zapisu
w dysku twardym.

Wysoko wydajny PostgreSQL 9.0

158

Jednak powy(sze ustawienie nie b#dzie funkcjonowa$o na wszystkich platformach. Warto
pami#ta), (e po zmianie warto'ci domy'lnej na przedstawion" powy(ej nast"pi pewien spadek
wydajno'ci. Dzieje si# tak zawsze podczas przej'cia z buforowania niebezpiecznego do bez-
piecznego.

Na innych platformach optymalizacja parametru

wal_sync_method

mo(e by) znacznie bardziej

skomplikowana. Teoretycznie istnieje mo(liwo') poprawienia wydajno'ci operacji zapisu w sys-
temach z rodziny Unix poprzez zmian# dowolnej metody zapisu u(ywaj"cej par

write

fsync

lub

write

fdatasync

na stosuj"c" zapis prawdziwie synchroniczny. Mo(na si# przekona), po wyda-

niu polecenia

SHOW

, (e na platformach obs$uguj"cych bezpieczne zachowanie zapisu

DSYNC

jest

to opcja stosowana domy'lnie:

wal_sync_method=open_datasync

Jednak tak(e w tym przypadku opcja ta nie jest jawnie podana w pliku konfiguracyjnym. Je(eli
tak jest na u(ywanej przez czytelnika platformie, mo(na przeprowadzi) jedynie niewielk"
optymalizacj#. Warto')

open_datasync

to ogólnie optymalne podej'cie, a kiedy wymieniona opcja

jest dost#pna, pozwala nawet na bezpo'rednie u(ywanie urz"dze8 wej'cia-wyj'cia, a tak(e
pomijanie bufora systemu operacyjnego.

W systemie Linux sytuacja jest prawdopodobnie najbardziej skomplikowana. Jak przedstawiono
we wcze'niejszym fragmencie kodu, platforma Linux domy'lnie u(ywa metody

fdatasync

. Za

pomoc" poni(szego polecenia mo(na w$"czy) tryb synchronicznych operacji zapisu:

wal_sync_method=open_sync

Ponadto w wielu przypadkach mo(na odkry), (e metoda ta dzia$a szybciej — czasami nawet
znacznie szybciej — ni( okre'lona domy'lnie. Jednak bezpiecze8stwo jej stosowania zale(y
od u(ywanego systemu plików. W wi#kszo'ci systemów Linux domy'lnym systemem plików
jest ext3, który w wielu przypadkach nie obs$uguje bezpiecznych operacji zapisu

O_SYNC

, co

mo(e doprowadzi) do uszkodzenia danych. Przyk$ady niebezpiecze8stw takiego ustawienia na
platformie Linux przedstawiono w w"tku „PANIC caused by open_sync on Linux” znajduj"cym
si# na stronie http://archives.postgresql.org/pgsql-hackers/2007-10/msg01310.php. Istniej" dowody,
(e w ostatnich wersjach j"dra (2.6.32) ten problem nie istnieje, je'li u(ywany jest system pli-
ków ext4, ale takie rozwi"zanie nie zosta$o jeszcze intensywnie przetestowane na poziomie
bazy danych.

W ka(dym przypadku podczas przeprowadzania w$asnych testów warto'ci parametru

wal_sync_method

nale(y wykona) równie( test polegaj"cy na „wyci"gni#ciu z gniazda sieciowego

wtyczki przewodu zasilaj"cego serwer”. Spowoduje to nag$e odci#cie zasilania serwera i pozwoli
na sprawdzenie, czy nast"pi$a utrata jakichkolwiek danych w wyniku stosowania testowanej
metody. Zalecane jest równie( przeprowadzenie d$ugotrwa$ych testów przy du(ym obci"(eniu,
aby znale1) sporadyczne b$#dy, które mog" doprowadzi) do awarii.

Rozdzia% 6. • Optymalizacja konfiguracji serwera

159

Replikacja WAL i PITR

Parametry

archive_mode

archive_command

oraz

archive_timeout

zosta$y omówione w rozdziale 14.

Ustawienia na poziomie klienta

Wprawdzie wszystkie parametry omawiane w tym podrozdziale mog" by) dostosowane na
poziomie klienta, po("dane jest ustawienie dla nich odpowiednich warto'ci pocz"tkowych
w g$ównym pliku konfiguracyjnym. Gdy trzeba zmieni) warto') parametru w poszczególnych
klientach, zawsze mo(na j" wprowadzi) na czas trwania sesji, wykorzystuj"c do tego polece-
nie

SET

effective_cache_size

Jak wspomniano w poprzednim rozdziale, baza danych PostgreSQL u(ywa zarówno w$asnej
dedykowanej jej pami#ci (

shared_buffers

), jak i korzysta z bufora systemu plików. W pew-

nych sytuacjach, podczas podejmowania decyzji dotycz"cych efektywno'ci u(ycia indeksu
b"d1 nie, baza danych porównuje obliczone przez siebie wielko'ci wzgl#dem efektywnej sumy
wszystkich wymienionych buforów. Warto') t# spodziewa si# znale1) w parametrze

effective_

cache_size

Ta sama regu$a, wedle której warto') parametru

shared_buffers

powinna wynosi) oko$o 25%

ilo'ci pami#ci systemowej, mówi tak(e, (e warto') parametru

effective_cache_size

powinna

wynosi) od 50 do 75% ilo'ci pami#ci RAM. Aby znacznie dok$adniej oszacowa) warto'ci, trzeba
na pocz"tek przyjrze) si# buforowi systemu plików:

w systemach z rodziny Unix oszacowanie wielko'ci bufora systemu plików wymaga
dodania warto'ci

free

cached

wy'wietlanych przez polecenia

free

top

;

w systemach Windows nale(y wy'wietli) okno Mened(era zada8 Windows, przej')
na zak$adk# Wydajno56 i odczyta) warto') w linii Bufor systemu.

Po przyj#ciu, (e baza danych zosta$a ju( uruchomiona, do obliczonych warto'ci trzeba doda)
jeszcze warto')

shared_buffers

, w ten sposób otrzyma si#

effective_cache_size

. Je(eli baza

danych nie zosta$a jeszcze uruchomiona, bufor systemu operacyjnego b#dzie zwykle wystarcza-
j"co dok$adny do oszacowania warto'ci parametru. Po uruchomieniu bazy danych wi#kszo')
pami#ci przeznaczonej dla bazy danych zwykle i tak b#dzie zaalokowana na potrzeby jej bufora.

Parametr

effective_cache_size

nie powoduje alokacji jakiejkolwiek pami#ci. Jest u(ywany

wy$"cznie po to, by okre'li) sposób wykonywania zapyta8, i jego ogólne oszacowanie jest wystar-
czaj"ce do wi#kszo'ci celów. Kiedy jednak warto') ta b#dzie zbyt wysoka, wykonywanie zapy-
ta8 mo(e skutkowa) zak$óceniami w buforze zarówno bazy danych, jak i systemu operacyjnego

Wysoko wydajny PostgreSQL 9.0

160

wynikaj"cymi z konieczno'ci odczytania ogromnej liczby bloków wymaganych do wykonania
zapytania, które bardzo $atwo zmie'ci si# w pami#ci RAM.

Bardzo rzadko zdarza si#, aby parametr ten by$ optymalizowany na poziomie klienta, nawet je'li
jest to mo(liwe.

synchronous_commit

W rozdziale 2. obci"(enie zwi"zane z oczekiwaniem, a( fizyczny dysk zako8czy operacj#
zatwierdzania, wskazano jako potencjalne w"skie gard$o podczas zatwierdzania transakcji. Je(eli
czytelnik nie posiada podtrzymywanego bateryjnie bufora zapisu, który móg$by przy'pieszy)
takie operacje, ale koniecznie chce przy'pieszy) operacje zatwierdzania transakcji, rodzi
si# pytanie, w jaki sposób mo(na to zrobi). Standardowym podej'ciem jest wy$"czenie opcji

synchronous_commit

, która czasami nazywana jest opcj" w$"czaj"c" asynchroniczne zatwierdzenia.

Powoduje ona zgromadzenie w wi#ksz" grup# operacji zatwierdzenia w cz#stotliwo'ci okre'lo-
nej przez powi"zany z ni" parametr

wal_writer_delay

. Ustawienia domy'lne gwarantuj" realne

zatwierdzenie transakcji na dysku po up$ywie co najwy(ej 600 milisekund od chwili zatwier-
dzenia transakcji przez klienta. W trakcie tego okresu czasu, który mo(na skróci), licz"c si#
jednocze'nie ze spadkiem szybko'ci, niezatwierdzone dane nie b#d" odzyskane po ewentualnej
awarii serwera.

Warto zwróci) uwag#, (e opisywany parametr mo(na wy$"czy) dla pojedynczego klienta na
czas trwania jego sesji, zamiast wy$"cza) go dla ca$ego serwera. Wy$"czenie 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" najcz#'ciej wstawiane, a u$amek sekundy strat akceptowany — jest
dobrym kandydatem dla asynchronicznych zatwierdze8. W przypadku rzadziej zapisywanej
tabeli przechowuj"cej rzeczywiste transakcje finansowe preferowanym rozwi"zaniem jest sto-
sowanie standardowych, synchronicznych zatwierdze8.

work_mem

Kiedy wykonywane jest zapytanie wymagaj"ce sortowania danych, baza danych szacuje ilo')
danych koniecznych do u(ycia i nast#pnie porównuje obliczon" warto') do okre'lonej w para-
metrze

work_mem

. Je(eli jest wi#ksza (a warto') domy'lna parametru

work_mem

wynosi 1 MB),

zamiast sortowa) dane w pami#ci, zapisze je na dysku i przeprowadzi operacj# sortowania
dyskowego. Taka operacja jest znacznie wolniejsza ni( sortowanie przeprowadzane w pami#ci.
Dlatego te(, w przypadku regularnego sortowania danych i posiadania wolnej pami#ci, zwi#k-
szenie warto'ci parametru

work_mem

mo(e by) jednym z najefektywniejszych sposobów przy-

'pieszenia dzia$ania serwera. Magazyny danych generuj"ce ogromne raporty maj" w swoich
serwerach gigabajty pami#ci przypisane parametrowi

work_mem

Rozdzia% 6. • Optymalizacja konfiguracji serwera

161

Problem polega na tym, (e niekoniecznie mo(na $atwo przewidzie) liczb# operacji sortowania
przeprowadzanych przez klienta, a parametr

work_mem

jest okre'lany dla ka(dej operacji sor-

towania, a nie dla ka(dego klienta. Oznacza to, (e ilo') pami#ci u(ywanej przez

work_mem

mo(e

by) teoretycznie nieograniczona, je(eli liczba klientów jednocze'nie przeprowadzaj"cych sor-
towanie b#dzie wystarczaj"co du(a.

W praktyce w typowym zapytaniu nie ma zbyt wielu operacji sortowania, najcz#'ciej tylko
jedna b"d1 dwie. Ponadto nie wszyscy aktywni klienci b#d" w tym samym czasie przeprowa-
dzali operacje sortowania. W trakcie okre'lania ilo'ci pami#ci dla parametru

work_mem

zwykle

bierze si# pod uwag# ilo') wolnej pami#ci 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 nast#pnie bierze tylko cz#') obliczonej warto'ci. Po$owa obli-

czonej liczby b#dzie warto'ci" do') du(" dla parametru

work_mem

. W takim przypadku w ser-

werze mo(e zabrakn") pami#ci, je(eli ka(dy klient b#dzie przez ca$y czas przeprowadza$ po dwie
operacje sortowania, ale prawdopodobie8stwo wyst"pienia takiej sytuacji jest znikome.

Obliczenia warto'ci

work_mem

s" coraz cz#'ciej stosowane w najnowszych wersjach PostgreSQL

w celu oszacowania, czy struktura hash mo(e zosta) zbudowana w pami#ci. Pami#) jest u(ywana
tak(e przez klienta, a nie jedynie przeznaczona dla operacji sortowania. Przedstawiono po pro-
stu naj$atwiejszy sposób rozwi"zywania problemów dotycz"cych rodzajów alokacji pami#ci.

Podobnie jak

synchronous_commit

, parametr

work_mem

mo(e by) równie( ustawiany na poziomie

klienta. W ten sposób warto') domy'ln" mo(na zdefiniowa) na 'rednim poziomie i zwi#ksza)
pami#) do sortowania dla u(ytkowników, którzy wykonuj" zapytania generuj"ce ogromne raporty.

random_page_cost

Parametr cz#sto jest optymalizowany, ale jego obja'nienie wymaga przedstawienia wielu infor-
macji dotycz"cych planowania zapyta8. Temat ten zosta$ omówiony w rozdziale 10. Szczególnie
we wcze'niejszych wersjach PostgreSQL zmniejszenie warto'ci parametru

random_page_cost

poni(ej warto'ci domy'lnej — na przyk$ad z 4.0 na 2.0 — by$o powszechnie stosowanym
rozwi"zaniem. Celem by$o zwi#kszenie prawdopodobie8stwa, (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 nale(y stosowa). O wiele rozs"dniejszym rozwi"zaniem jest zebranie lepszych
danych statystycznych i wykorzystanie parametrów dotycz"cych pami#ci jako podstawowych
sposobów wp$ywania na planist# zapyta8.

constraint_exclusion

Je(eli u(ywana jest baza danych PostgreSQL w wersji 8.3 lub wcze'niejszej, a do partycjono-
wania danych zastosowano oferowan" przez baz# danych funkcj# tabeli dziedziczenia, parametr

constraint_exclusion

musi by) w$"czony. Powody takiego stanu rzeczy wyja'niono w rozdziale 15.

Wysoko wydajny PostgreSQL 9.0

162

Pocz"wszy od wersji 8.4, warto'ci" domy'ln" parametru

constraint_exclusion

jest nowe, spryt-

niejsze ustawienie o nazwie

partition

, które w wi#kszo'ci 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 nieprawid$owe warto'ci. Inne maj" nazwy sugeruj"ce u(ycie wraz
z parametrami, które w rzeczywisto'ci nie istniej". W tym punkcie opisano najcz#'ciej spotykane
opcje, których optymalizacja jest niezalecana.

fsync

Je(eli czytelnik chce zignorowa) proces naprawy po wyst"pieniu awarii, mo(e to zrobi) poprzez
wy$"czenie parametru

fsync

. W ten sposób warto') parametru

wal_sync_method

nie b#dzie mia$a

znaczenia, poniewa( serwer i tak nie wykona (adnych wywo$a8

sync

mechanizmu WAL.

Trzeba w tym miejscu zda) sobie spraw#, (e w przypadku wyst"pienia jakiejkolwiek awarii
przy wy$"czonym parametrze

fsync

baza danych prawdopodobnie b#dzie uszkodzona i uru-

chomienie serwera stanie si# niemo(liwe. Wprawdzie to okropna sytuacja, ale zwi#kszenie
wydajno'ci w wyniku wy$"czenia procesu naprawy po awarii jest tak ogromne, (e czytelnik
mo(e natkn") si# na sugestie wy$"czenia parametru

fsync

. Równie nieufnie nale(y traktowa)

inne rady pochodz"ce z tych samych 1róde$, które sugeruj" wy$"czenie parametru

fsync

, ponie-

wa( wy$"czenie tego parametru jest szalenie niebezpieczne.

Jedynym powodem, dla którego taki pomys$ zyska$ zwolenników we wcze'niejszych wersjach
PostgreSQL, by$ brak innego sposobu na zmniejszenie liczby wywo$a8

fsync

— to taki kom-

promis: nieco wi#ksza wydajno') kosztem mniejszej niezawodno'ci. Od wersji 8.3 u(ytkownicy,
zamiast wy$"cza) parametr

fsync

, zrobi" lepiej, wy$"czaj"c parametr

synchronous_commit

Istnieje jedna sytuacja, gdy u(ycie parametru

fsync=off

nadal ma sens — to pocz"tkowe ope-

racje typu bulk-loading. Je(eli do bazy wstawiane s" ogromne ilo'ci danych, a sprz#t nie jest
wyposa(ony w bateryjnie podtrzymywany bufor zapisu, taka operacja wstawiania danych b#dzie
trwa$a zdecydowanie za d$ugo, aby uzna) j" za praktyczn". W takim przypadku wy$"czenie
parametru

fsync

podczas przeprowadzania operacji wstawiania danych — w przypadku awarii

serwera wszystkie dane i tak mo(na $atwo odtworzy) — mo(e by) jedynym sposobem przy-
'pieszenia ca$ej operacji. Po zako8czeniu procesu wstawiania nale(y z powrotem w$"czy)
parametr

fsync

W niektórych systemach parametr

fsync

jest wy$"czany w serwerach posiadaj"cych redun-

dancyjn" kopi# bazy danych — na przyk$ad w systemach zapasowych u(ywanych do genero-
wania raportów. Je(eli w takim przypadku dane zostan" uszkodzone, zawsze mo(na przepro-
wadzi) ponown" synchronizacj# z g$ównym systemem.

Rozdzia% 6. • Optymalizacja konfiguracji serwera

163

full_page_writes

Podobnie jak przy

fsync

, wy$"czenie parametru

full_page_writes

zwi#ksza wydajno') za cen#

wi#kszego ryzyka uszkodzenia bazy danych. Przed wy$"czeniem tego parametru nale(y bardzo
dok$adnie i ostro(nie przeanalizowa) mo(liwo'ci systemu plików oraz u(ywanego sprz#tu, aby
mie) gwarancj#, (e nie dojdzie do cz#'ciowego zapisu stron.

commit_delay i commit_siblings

Przed implementacj"

synchronous_commit

podejmowane by$y próby dodania tego rodzaju funkcji

za pomoc" parametrów

commit_delay

commit_siblings

. W wi#kszo'ci przypadków nie s" to

parametry efektywne do optymalizacji. Uzyskanie realnego przy'pieszenia poprzez dostosowa-
nie warto'ci tych parametrów jest niezwykle trudne, za to bardzo $atwo mo(na doprowadzi) do
spowolnienia wykonywania ka(dej transakcji. Jedyny przypadek, kiedy opisywane parametry
mog" okaza) si# przydatne, dotyczy systemów o ogromnej ilo'ci operacji wej'cia-wyj'cia. Usta-
wienie bardzo ma$ej warto'ci opó1nienia mo(e spowodowa) przeprowadzanie operacji zapisu
w wi#kszych blokach, co czasami w po$"czeniu z wi#ksz" warto'ci" jednostki macierzy RAID
okazuje si# lepszym rozwi"zaniem.

max_prepared_transactions

Wielu u(ytkowników po spojrzeniu na nazw# tego parametru b#dzie przekonanych, (e dotyczy
transakcji sk$adowanych, czyli techniki powszechnie stosowanej w celu unikni#cia wstawiania
z$o'liwego kodu SQL, i odczuje potrzeb# zwi#kszenia warto'ci tego parametru. To jednak b$#dne
za$o(enie, omawiany parametr i transakcje sk$adowane nie s" ze sob" powi"zane. Transakcja
sk$adowana to taka, która u(ywa polecenia

PREPARE TRANSACTION

w celu u(ycia dwuetapowego

zatwierdzenia (ang. two-phase commit, 2PC). Je(eli czytelnik nie u(ywa tego polecenia oraz
techniki 2PC, mo(e pozostawi) dla tego parametru warto') domy'ln". Natomiast w przypadku
u(ywania funkcji dwuetapowego zatwierdzania konieczno') zwi#kszenia warto'ci parametru

max_prepared_transaction

wyst"pi prawdopodobnie tylko wtedy, kiedy trzeba b#dzie dopaso-

wa) j" do liczby po$"cze8.

Zapytania w&'czaj'ce parametry

Istnieje mo(liwo') wy$"czenia wielu technik stosowanych przez planist# zapytania, co ma na
celu unikni#cie u(ycia niew$a'ciwego typu zapytania. Czasami jest to stosowane jako rodzaj
obej'cia problemu polegaj"cego na tym, (e PostgreSQL nie obs$uguje bezpo'rednich podpo-
wiedzi optymalizatora dotycz"cych sposobu wykonania zapytania. Czytelnik móg$ si# spotka)
z przedstawionym poni(ej wierszem kodu jako sugerowanym sposobem wymuszenia u(ycia
indeksów zamiast skanowania sekwencyjnego:

enable_seqscan = off

Ogólnie rzecz ujmuj"c, to z$a praktyka. Zamiast niej, aby podejmowa) lepsze decyzje, nale(y
d"(y) do poprawienia informacji przekazywanych optymalizatorowi zapyta8. Temat zosta$
omówiony w rozdziale 10.

Wysoko wydajny PostgreSQL 9.0

164

Optymalizacja ustawie( nowego serwera

Istnieje kilka sposób po$"czenia wszystkich przedstawionych dot"d informacji w jeden proces
optymalizacji ustawie8 nowego serwera. Wybór najlepszego sposobu zale(y od oczekiwa8
stawianych serwerowi, a tak(e od samego u(ytkownika — czy chce przeprowadzi) samodzieln"
optymalizacj#, czy b#dzie stosowa$ zalecane tutaj warto'ci parametrów.

Wskazówki dotycz'ce

serwerów dedykowanych

Pocz"tkow" optymalizacj# serwera mo(na sprowadzi) do ca$kiem mechanicznego procesu. Oto on.

1. Dostosowanie rejestracji zdarze8 w taki sposób, aby dostarcza$a wi#kszej ilo'ci

informacji.

2. Ustalenie wielko'ci parametru

shared_buffers

. Nale(y rozpocz") od warto'ci równej

25% pami#ci systemowej. Je(eli czytelnik u(ywa najnowszych wersji PostgreSQL
obs$uguj"cych rozpraszanie punktów kontrolnych i wie, (e dane obci"(enie serwera
odniesie korzy'ci po przydzieleniu buforowi wi#kszej ilo'ci pami#ci, mo(e spróbowa)
zwi#kszania warto'ci

shared_buffers

. W przypadku platformy, na której parametr

ten nie jest tak u(yteczny, jego warto') nale(y odpowiednio dopasowa) lub nawet
zmniejszy).

3. Rozs"dne oszacowanie maksymalnej liczby po$"cze8. Jest to ograniczenie bezwzgl#dne.

Po osi"gni#ciu ustalonej liczby po$"cze8 próby nawi"zania po$"czenia przez nowych
klientów b#d" odrzucane.

4. Uruchomienie serwera z tymi parametrami pocz"tkowymi. Nast#pnie trzeba sprawdzi)

ilo') pami#ci pozosta$ej dla bufora systemu plików.

5. Kolejny krok to okre'lenie wielko'ci parametru

effective_cache_size

na podstawie

wielko'ci parametru

shared_buffers

i bufora systemu operacyjnego.

6. Podzielenie wielko'ci bufora systemu operacyjnego przez warto')

max_connections

a pó1niej jeszcze przez dwa. W ten sposób czytelnik otrzymuje rozs"dn" warto')
dla parametru

work_mem

. Je(eli aplikacja w (aden sposób nie jest uzale(niona od

wydajno'ci operacji sortowania, odpowiednie b#dzie ustawienie znacznie ni(szej
warto'ci parametru

work_mem

7. Ustawienie dla parametru

maintenance_work_mem

warto'ci oko$o 50 MB na ka(dy

gigabajt pami#ci RAM.

8. Zwi#kszenie warto'ci parametru

checkpoint_segments

do przynajmniej 10. Je(eli

czytelnik posiada sprz#t klasy serwerowej z bateryjnie podtrzymywanym buforem
zapisu, warto') 32 dla parametru

checkpoint_segments

b#dzie znacznie lepsz"

warto'ci" domy'ln".

Rozdzia% 6. • Optymalizacja konfiguracji serwera

165

9. Zmiana warto'ci domy'lnej parametru

wal_sync_method

. Je(eli u(ywana jest platforma,

na której warto') domy'lna tego parametru jest niebezpieczna, nale(y zmieni) t# warto').

10. Warto') parametru

wal_buffers

trzeba zwi#kszy) do 16 MB.

11. Dla baz danych PostgreSQL w wersjach ni(szych ni( 8.4 warto rozwa(y) zwi#kszenie

warto'ci parametrów

default_statistics_target

(do 100, warto') domy'lna

w nowszych wersjach PostgreSQL) i

max_fsm_pages

na podstawie informacji

o przewidywanym obci"(eniu dla tej bazy danych.

Po skonfigurowaniu pewnej liczby serwerów przeznaczonych do obs$ugi danej aplikacji czy-
telnik b#dzie mia$ znacznie lepsze rozeznanie, które warto'ci pocz"tkowe maj" sens, aby rozpo-
czyna) z nimi prac#. Szczególnie warto'ci ko8cowe parametrów

checkpoint_segments

work_mem

mog" bardzo istotnie odbiega) od tutaj zalecanych.

Wskazówki dotycz'ce
serwerów wspó#dzielonych

Je(eli serwer bazy danych wspó$dzieli sprz#t z inn" aplikacj" — cz#sto spotykana jest sytuacja
umieszczania wielu aplikacji bazodanowych w pojedynczym systemie — podczas optymalizacji
nie mo(na stosowa) tak agresywnego podej'cia, jakie przedstawiono w poprzednim podroz-
dziale. W takim przypadku dok$adna procedura jest trudna do nakre'lenia. Nale(y podj") prób#
przeprowadzenia optymalizacji warto'ci parametrów zwi"zanych z pami#ci" i zastosowa) dolne
granice zalecanych warto'ci:

parametrowi

shared_buffers

nale(y przydzieli) tylko 10% pami#ci RAM, nawet

na platformach, na których normalnie zaleca si# przydzielenie wi#kszej warto'ci;

parametrowi

effective_cache_size

nale(y przydzieli) 50% lub mniej pami#ci RAM,

prawdopodobnie mniej, je'li wiadomo, (e aplikacja b#dzie u(ywa) du(ej ilo'ci pami#ci;

trzeba bardzo ostro(nie podchodzi) do zwi#kszania warto'ci parametru

work_mem

Inne sugestie przedstawione w poprzednim podrozdziale maj" zastosowanie równie( tutaj —
na przyk$ad u(ycie wi#kszych warto'ci dla parametru

checkpoint_segments

i odpowiedni wybór

warto'ci parametru

wal_sync_method

nie ró(ni" si# niczym w obu systemach.

Nast#pnie trzeba zasymulowa) dzia$anie aplikacji z pe$nym obci"(eniem i sprawdzi) ilo') dost#p-
nej pami#ci RAM, aby si# przekona), czy mo(liwe jest przydzielenie bazie danych wi#kszej
ilo'ci pami#ci. Proces mo(e wymaga) kilkakrotnego powtórzenia i na pewno powinien by)
powi"zany z przeprowadzaniem testów wydajno'ci na poziomie aplikacji, o ile jest taka mo(-
liwo'). W systemie wspó$dzielonym nie ma sensu przydzielanie bazie danych wi#kszej ilo'ci
pami#ci, je(eli aplikacja b"d1 inna warstwa buforuj"ca, na przyk$ad na poziomie puli po$"-
cze8, nie b#dzie efektywnie wykorzystywa$a tej pami#ci. Ta sama idea — u(ycie rozs"d-
nych warto'ci pocz"tkowych, a nast#pnie stopniowe przeprowadzanie optymalizacji na pod-
stawie monitorowania — sprawdza si# doskonale tak(e w serwerach dedykowanych.

Wysoko wydajny PostgreSQL 9.0

166

pgtune

Od PostgreSQL w wersji 8.4 narz#dzie pgtune dost#pne na stronie http://pgfoundry.org/projects/
pgtune/ mo(e by) u(yte do utworzenia pocz"tkowego pliku konfiguracyjnego postgresql.conf
dla nowego serwera. Narz#dzie pozwala u(ytkownikowi na zasugerowanie przewidywanego
rodzaju obci"(enia bazy danych z zakresu od stacji roboczej programisty a( do dedykowanego
serwera magazynu danych. Na podstawie tych danych wej'ciowych oraz parametrów, takich jak
ilo') pami#ci RAM zainstalowana w serwerze, narz#dzie generuje plik konfiguracyjny wst#pnie
zoptymalizowany dla najwa(niejszych parametrów systemowych, stosuje przy tym metody
podobne do omówionych w rozdziale. Uzyskany wynik nie b#dzie tak dobry jak zastosowanie
wskazówek przedstawionych dla serwera dedykowanego i samodzielne przeprowadzanie pomia-
rów, ale pozwoli na szybkie rozpocz#cie pracy z ogólnie dobr" konfiguracj". Ka(dy rozs"dnie
zmodyfikowany plik konfiguracyjny postgresql.conf b#dzie znacznie lepszy od domy'lnego,
który dostrojony jest jedynie pod k"tem alokacji jak najmniejszej ilo'ci pami#ci wspó$dzielonej.

Podsumowanie

W konfiguracji bazy danych PostgreSQL istnieje niemal 200 warto'ci, które mo(na zmodyfi-
kowa); poprawne ustawienie w aplikacji wszystkich mo(e by) ca$kiem du(ym wyzwaniem.
Wskazówki przedstawione w rozdziale powinny pomóc czytelnikowi w rozpocz#ciu procesu
optymalizacji konfiguracji i unikni#ciu najcz#'ciej spotykanych pu$apek. Gdy u(ytkownik napo-
tka problemy, powinny te( pokaza), które ustawienia s" cenniejsze.

Warto'ci domy'lne w pliku konfiguracyjnym serwera powoduj" zapisywanie
w dzienniku zdarze8 niewielu informacji i charakteryzuj" si# wyj"tkowo sk"pymi
ustawieniami pami#ci. W ka(dym serwerze nale(y przynamniej przeprowadzi)
podstawow" optymalizacj# w celu rozwi"zania najgorszych problemów.

Ustawienia parametrów zwi"zanych z pami#ci", czyli przede wszystkim

shared_buffers

work_mem

, powinny by) przeprowadzane bardzo ostro(nie, aby nie doprowadzi)

do sytuacji, w której systemowi zabraknie pami#ci.

W celu przygotowania w$a'ciwego planu wykonania zapytania planista zapytania musi
mie) prawid$owe informacje o pami#ci oraz dobre dane statystyczne dotycz"ce tabeli.

Demon

autovacuum

ma znaczenie krytyczne dla zapewnienia plani'cie zapytania

odpowiednich informacji. Ponadto demon

autovacuum

zapewnia tabelom uruchamianie

w$a'ciwych procesów konserwacyjnych.

W wielu przypadkach wprowadzenie zmiany konfiguracyjnej nie wymaga
ponownego uruchomienia serwera, a wiele parametrów mo(na nawet modyfikowa)
dla poszczególnych klientów, zapewniaj"c w ten sposób naprawd# dok$adn"
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 pami#ci 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 zdarze8, 203
analiza opó1nienia, 219
analiza planu zapytania, 264
analiza pliku dziennika zdarze8, 200
analiza zawarto'ci bufora bazy danych, 136
ANALYZE, 152, 154, 232, 259, 290, 291, 407,

421

cele danych statystycznych, 293
dostosowanie warto'ci celu

dla poszczególnych kolumn, 294

obszary trudne do oszacowania, 295
ró(ne warto'ci, 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

b$#dy spowodowane brakiem pami#ci, 187
d$ugo wykonywane transakcje, 188
monitorowanie procesu, 182
obci"(ony serwer, 187
opcje dla poszczególnych tabel, 184
problemy, 185
rejestrowanie zdarze8, 182

Wysoko wydajny PostgreSQL 9.0

444

autovacuum

uruchamianie procesu, 183
w$"czanie 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

obs$uga przez nap#dy, 94
obs$uga 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
bezpo'rednio pod$"czona 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 zawarto'ci, 136
dostosowanie wielko'ci bufora, 141
generowanie podsumowania, 138
jednostki pami#ci, 118
konfiguracja uk$adu dysków, 124
licznik u(ycia tabel, 138
naprawa bazy danych po awarii, 128
nat#(enie operacji dyskowych, 135
ograniczenia, 135
ogromne systemy, 136
pami#) wspó$dzielona w systemie Unix,

119

pg_buffercache, 123
pocz"tkowe wskazówki dotycz"ce

wielko'ci, 135

podsumowanie zawarto'ci bufora

z u(yciem danych procentowych, 139

podwójne buforowanie, 134
przeci"(enie punktu kontrolnego, 134
przegl"d wielko'ci bufora, 141
przegl"d zawarto'ci bufora, 137
relacje, 138
rozproszenie u(ycia 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ó1nionym zapisem, 49, 50
bufor zapisu, 49, 98

wy$"czanie, 52

Skorowidz

445

buforowanie bazy danych, 376

memcached, 376
pgmemcache, 377

buforowanie odczytu, 98
bulk-loading, 415

czyszczenie po operacji wczytania

danych, 420

dodawanie ogranicze8, 419
metody wczytywania danych, 416
optymalizacja operacji, 417
pomini#cie optymalizacji

mechanizmu WAL, 418

ponowne tworzenie indeksów, 419
przywracanie równoleg$e, 419

Cacti, 366

PostgreSQL, 366
Windows, 366

Cassandra, 26
cele danych statystycznych, 293

dostosowanie warto'ci celu

dla poszczególnych kolumn, 294

ró(ne warto'ci, 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 widoczno'ci rekordu, 168
czas dost#pu do plików, 97
czas wyszukiwania, 76
cz#stotliwo') kreowania punktów

kontrolnych, 129

czyszczenie bufora, 257
czyszczenie po operacji wczytania danych, 420

dane statystyczne, 152, 290, 315

cele danych statystycznych, 293
dane dotycz"ce ca$ej bazy danych, 324

Wysoko wydajny PostgreSQL 9.0

446

dane statystyczne

dane dotycz"ce indeksu, 322
dane dotycz"ce tabel, 230, 318
histogram, 291
pg_stats, 290
przegl"danie, 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
dost#p sekwencyjny, 63
dostrajanie systemów plików, 96
dowi"zania 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 wywo$ywanie funkcji, 398
dyski twarde, 37

bariery zapisu, 94
bonnie++, 70
dd, 69
dost#p sekwencyjny, 63
hdtune, 65
IOPS, 68
konfiguracja, 85
liczba operacji wej'cia-wyj'cia

na sekund#, 61

liczba wykonywanych operacji

zatwierdzania, 64

macierz RAID, 38
maksymalna wielko') systemu plików, 85
narz#dzia do testowania wydajno'ci, 65
NCQ, 95
nieprzewidywalna wydajno')

w Windows, 69

niezawodno'), 41
obs$uga b$#dów, 40
oczekiwana wydajno') dysku, 80
odczytywanie bloków danych, 69
oprogramowanie firmware, 42
optymalizacja pojemno'ci, 63
powody niskiej wydajno'ci, 81
Random Access, 68
schemat partycjonowania, 86
short stroking, 63
spindle, 62
SSD, 42
swobodny dost#p, 61
'redni czas dost#pu, 62
test_fsync, 64
testy typu short stroking, 67
testy wydajno'ci, 61, 77
wyniki testu wydajno'ci, 78
zapisywanie bloków danych, 69
ZCAV, 63

dziennik zapisu z wyprzedzeniem, 128
dziennik zatwierdze8, 133
dzienniki zdarze8 zapyta8, 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 wyj'ciowe, 437
dane wyj'ciowe w postaci czytelnej

dla komputera, 263

graficzne przedstawienie danych, 262
narz#dzia analizy danych, 262, 264
obci"(enie zwi"zane z pomiarem, 256
rozbudowane dane wyj'ciowe, 263
rozgrzany bufor, 257
struktura w#z$ó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 ksi#gowania, 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

fa$szywa 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 zdarze8, 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 agreguj"ce, 271
funkcje Window, 311, 437

Wysoko wydajny PostgreSQL 9.0

448

Generalized Inverted Index, 246
Generalized Search Tree, 247
generate_series(), 59, 310
generowanie warto'ci hash, 408
Genetic Query Optimizer, 289, 437
genetyczny optymalizator zapyta8, 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 wej'cia-wyj'cia, 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 bazuj"cy na wyra(eniu, 249
indeks cz#'ciowy, 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 wej'cia-wyj'cia, 323
sposoby korzystania z indeksów, 247
tworzenie, 235, 241
tworzenie wspó$bie(ne, 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
pe$ne 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 pe$nego tekstu, 250
wyszukiwanie za pomoc" nieefektywnego

indeksu, 235

informacje o blokadach, 327, 332
informowanie o wyst"pieniu 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 modu$u contrib

z kodu 1ród$owego, 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

przyk$ady dobrej wydajno'ci, 349
przyk$ady przeci"(onego 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 pami#ci, 118
jednostka pami#ci masowej, 109
j#zyk 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 zewn#trzne, 424
klustsize, 103
k$amstwa dysku twardego, 49
kolejno') z$"cze8, 287
kolekcjoner danych statystycznych, 426
konfiguracja dysków twardych, 48, 85
konfiguracja przekazywania danych

mechanizmu WAL, 383

konfiguracja rejestracji zdarze8, 194

log_line_prefix, 195
rejestrowanie CSV, 197
rejestrowanie trudnych zapyta8, 199
syslog, 197
zapytania obejmuj"ce wiele wierszy, 196
zbiór dzienników zdarze8, 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 u(ywan" 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 ustawie8 nowego

serwera, 164

optymalizacje niezalecane, 162
pami#) wspó$dzielona, 149
pgtune, 166
po$"czenia z baz" danych, 147
ponowne wczytywanie pliku

konfiguracyjnego, 146

punkty kontrolne, 155
random_page_cost, 161
rejestrowanie zdarze8, 150
shared_buffers, 149
synchronous_commit, 160
umieszczanie ustawie8

w komentarzach, 146

ustawienia domy'lne, 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 dotycz"ce

serwerów dedykowanych, 164

wskazówki dotycz"ce

serwerów wspó$dzielonych, 165

zapytania w$"czaj"ce parametry, 163
zerowanie ustawie8, 144

konfiguracja uk$adu dysków, 124
konflikty podczas blokowania rekordów, 171
konserwacja, 167
kontekst do przeprowadzania zmian, 144
kontrola wspó$bie(no'ci, 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
ksi#gowanie, 87, 89

Least Recently Used, 132
LEFT JOIN, 288, 289
libevent, 375
liczba obs$ugiwanych po$"cze8, 149
liczba operacji wej'cia-wyj'cia 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 po$"cze8, 372
liczniki u(ycia 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
fa$szywa macierz RAID, 46
JBOD, 53
konfiguracja dysków, 112
powody niskiej wydajno'ci, 81
programowa macierz RAID, 44
sprz#towa macierz RAID, 44
wskazówki dotycz"ce 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 z$"czenia 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ó$bie(no'ci, 167
mechanizm WAL, 382
MegaRAID, 45
memcached, 376
memtest86+, 56
Mened(er zada8, 360
mened(ery kolejki replikacji, 386
Merge Join, 280, 283, 304

materializacja z$"czenia, 284

metadane systemu plików, 86
metody replikacji, 391
metody wczytywania danych, 416
mi#kkie dowi"zania symboliczne, 109
migracja partycjonowanej u(ywanej tabeli, 401
MIN(), 271, 431
mirroring, 39
mk-query-digest, 206
model MVCC, 325
model wykonania zst#puj"cego, 270
modu$y contrib, 27

instalacja z kodu 1ród$owego, 28
pg_buffercache, 29
u(ywanie modu$u, 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 zdarze8 zapyta8, 194
kontroler dyskowy, 51
monitorowanie pod k"tem przerwania

us$ug, 363

poziom wykorzystania pami#ci, 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

nap#dy SSD, 42
naprawa bazy danych po awarii, 128

dziennik zapisu z wyprzedzeniem, 128
punkty kontrolne, 128

naprawa indeksu, 243
narz#dzia monitoruj"ce

system Unix, 343
system Windows, 360

narz#dzia s$u("ce do analizy planu, 264
narz#dzia SNMP, 369
NAS, 46
nat#(enie operacji wej'cia-wyj'cia, 130
Native Command Queuing, 95
NCQ, 95
Nested Loop, 278, 280
Network Attached Storage, 46
niewyja'nione 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
obs$uga barier zapisu

nap#d, 94
system plików, 95

obs$uga b$#dó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 przeci"(enie klucza

zewn#trznego, 424

ogromne przeci"(enie mechanizmu

zbieraj"cego dane statystyczne, 426

OID, 125, 265
oid2name, 125, 126
okno, 311
okre'lanie wielko'ci 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 wej'cia-wyj'cia indeksu, 323

Skorowidz

453

operacje wej'cia-wyj'cia tabel, 320
operacje zapisu, 422
OProfile, 32, 428
oprogramowanie, 30
oprogramowanie firmware, 42
oprogramowanie trendów, 362, 363
optymalizacja wydajno'ci, 32

Hot Standby, 384
konfiguracja serwera, 143
operacja bulk-loading, 417
optymalizacja z u(yciem danych

statystycznych dotycz"cych
zapisu w tle, 339

pojemno') dysku twardego, 63
ustawienia nowego serwera, 164

optymalizacja zapyta8, 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 zapyta8, 299
poszukiwanie odpowiednika zapytania, 300
przetwarzanie w#z$ów, 268
rozwi"zywanie b$#dów optymalizatora, 305
SELECT, 298
struktura w#z$ów planu zapytania, 259
unikanie planu restrukturyzacji, 306
UPDATE, 298
w pe$ni buforowane zbiory danych, 300
work_mem, 297
wy$"czanie funkcji optymalizatora, 301
zewn#trzne 1ród$a problemów, 309
z$"czenia, 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 wydajno'ci, 55
tryb dwukana$owy, 60
XMP, 60

parametry konfiguracyjne, 143
parametry planowania zapytania, 295
partition, 434
partycje, 405
partycjonowanie danych, 393

b$#dy, 407
tworzenie partycji, 405
zalety partycjonowania, 406

partycjonowanie o zasi#gu tabeli, 393

lista partycjonowania, 395
migracja partycjonowanej u(ywanej

tabeli, 401

plany zapyta8 dla pustej partycji, 399
pole klucza u(ywanego

do partycjonowania, 394

przekierowywanie polece8 INSERT

do partycji, 397

regu$y partycjonowania, 398
tworzenie partycji, 396, 405
uaktualnianie wyzwalacza, 400
wielko'ci partycji, 395
zapytania partycjonowane, 403
zmiana daty, 400

partycjonowanie poziome, 408

generowanie warto'ci hash, 408
GridSQL, 411
PL/Proxy, 408
Sharding, 410

parzysto'), 38
pdflush, 98
pe$ne skanowanie tabeli, 234
PERC, 45
perfmon, 360
p#tle zagnie(d(one, 281

materializacja z$"czenia Merge Join, 284
wewn#trzne 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ó1nienia, 219
definicja skryptu zapytania, 211
definicja tabeli, 210
inicjalizacja tabel, 211
konfiguracja serwera bazy danych, 213
ograniczenia programu, 224
powody otrzymywania b$#dnych wyników

i ró(nic, 222

programistyczne wersje PostgreSQL, 223
skrypt transakcji, 211
test przeprowadzaj"cy jedynie zapytania

SELECT, 217

test szybko'ci wstawiania danych, 225
test transakcji TPC-B-like, 218
testy domy'lne, 209
uruchamianie, 214
u(yteczno') wyników, 223
w"tki worker, 224
w$asne testy, 225
wykrywanie skali wielko'ci 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 wyj'ciowych, 204

pgFoundry, 30
pgiosim, 78
pgloader, 416, 417
pgmemcache, 377
pgpool, 389
pgpool-II, 373, 389

równowa(enie obci"(enia 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 zapyta8 dla pustej partycji, 399
w#z$y, 259

plik dziennika zdarze8, 200
pliki tymczasowe, 111
podtrzymywany bateryjnie bufor zapisu, 50
podwójnie buforowane dane, 133
Point-in-time recovery, 382
pole kontekstu, 145
polecenia sk$adowane, 423
po$"czenia z baz" danych, 147, 324
pomiar nadmuchania indeksu, 191
pomini#cie optymalizacji

mechanizmu WAL, 418

ponowne indeksowanie, 244
ponowne wczytywanie pliku

konfiguracyjnego, 146

poprawianie zapyta8, 299

postgres, 196
PostgreSQL, 21

uaktualnienie bezpo'rednie, 24
uaktualnienie do nowszej g$ównej

wersji, 23

wersje, 23, 429
wydajno') wyda8, 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 zwi"zane z wydajno'ci", 421

wersje PostgreSQL, 429

procesor, 36

testy wydajno'ci, 55, 59

profilowanie, 32

dyskowe operacje wej'cia-wyj'cia, 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
protoko$y

SMART, 40
SNMP, 363
Streaming Replication, 384
XMP, 60

prstat, 356

Wysoko wydajny PostgreSQL 9.0

456

przeci"(enie

klucz zewn#trzny, 424
mechanizm zbieraj"cy dane

statystyczne, 426

punkt kontrolny, 134

przegl"d wielko'ci bufora, 141
przegl"d zawarto'ci bufora, 137
przekierowywanie polece8 INSERT

do partycji, 397

przetwarzanie punktów kontrolnych, 128
przetwarzanie w#z$ó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ównoleg$e, 419
przywrócenie do pewnego punktu w czasie,

382

ps, 355, 426
pset, 231
psql, 59
pula po$"cze8, 371

liczba po$"cze8, 372
liczniki, 372
pgBouncer, 374
pgpool-II, 373
serwer aplikacji, 375

punkty kontrolne, 128

aktywno') tworzenia, 335
nat#(enie operacji wej'cia-wyj'cia, 130
przeci"(enie, 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
regu$y partycjonowania, 398
REINDEX, 125, 189, 192, 243, 320, 406, 440
ReiserFS, 93
rejestrowanie CSV, 197
rejestrowanie danych wydajno'ci, 363
rejestrowanie informacji o blokadach, 332
rejestrowanie trudnych zapyta8, 199
rejestrowanie zdarze8, 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
mened(ery 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 u(ycia bufora, 140
rozwi"zywanie b$#dów optymalizatora, 305
rozwi"zywanie problemów zwi"zanych

z wydajno'ci", 33

równowa(enie obci"(enia 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 dost#p, 61
SELECT, 59
semafory j"dra, 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 wielko'ci 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

narz#dzia, 369

SNMP MIB, 369
soft updates, 104
Solaris, 102
Solid State Drive, 42
Sort, 268
sortowanie, 248

sortowanie zewn#trzne przez scalanie, 269

SPD, 60
spindle, 61, 62
sposoby zapisu zmodyfikowanych bloków, 132
sprawdzanie wydajno'ci bazy danych, 209
sprz#t, 35

dyski twarde, 37
konfiguracja dysków, 48
kontrolery dysków, 43
pami#), 37
procesor, 36
testy wydajno'ci, 55
wydatki na zakup sprz#tu, 35

sprz#towa 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 sprz#towe, 57

Streaming Replication, 384, 385
stream-scaling, 57
stripe, 82
striped z parzysto'ci", 39
striping, 39
struktura w#z$ó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 dost#pu do plików, 97
dostrajanie, 96
ext2, 88

ext3, 89
ext4, 91
FAT32, 107
FreeBSD, 102, 104
JFS, 93
ksi#gowanie, 87, 88, 89
Linux, 88
maksymalna ilo') danych, 85
metadane, 86
naprawa, 87
NTFS, 107
odczyt z wyprzedzeniem, 96
odzyskiwanie danych po awarii, 86
okre'lanie wielko'ci bufora zapisu, 98
ReiserFS, 93
Solaris, 102
swapping, 98
UFS, 102
UFS2, 104
winda harmonogramu operacji

wej'cia-wyj'cia, 100

Windows, 107
XFS, 91, 96
ZFS, 105

szacowanie wielko'ci pami#ci

wspó$dzielonej, 121

szybkie sortowanie, 269

'redni czas dost#pu, 62

tabele, 318

dane statystyczne, 318
operacje wej'cia-wyj'cia, 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 pami#ci, 56
testowanie wydajno'ci dysku, 65

Skorowidz

459

testy OLTP, 22
testy szybko'ci wstawiania danych, 225
testy TPC-H, 26
testy transakcji TPC-B-like, 218
testy wydajno'ci, 32, 227

PL/pgSQL, 424
Transaction Processing Performance

Council, 226

testy wydajno'ci sprz#tu, 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 sk$adowane, 122, 318
transakcje wirtualne, 326
trendy, 362, 363

przechowywanie historycznych

danych trendów, 363

TRUNCATE, 125, 419
trwa$y identyfikator, 326
tryb JBOD, 53

tworzenie

blok w bazie danych, 126
indeks, 235, 241
przyk$adowe 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 bezpo'rednie, 24
uaktualnienie do PostgreSQL 8.3, 25
uaktualnienie mniej znacz"cych 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

urz"dzenia, 347

NAS, 46, 47
SAN, 46, 47

USB, 41
user, 145
ustawienia na poziomie klienta, 159
usuni#cia, 173
usuwanie z$"cze8, 288
uuid-ossp, 29
u(ycie pami#ci przez wyzwalacz, 425
u(ywanie modu$u contrib, 29

Czytaj dalej...

Wysoko wydajny PostgreSQL 9.0

460

vacuum, 176, 179, 180

autovacuum, 181
b$#dy spowodowane brakiem pami#ci, 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 pomini#te, 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
warto'ci hash, 408
warto'ci null, 242
w"skie gard$o, 32
wczytywanie pliku konfiguracyjnego, 146
wersje PostgreSQL, 21, 429
wewn#trzne skanowanie indeksu, 282
w#z$y planu zapytania, 259
WHERE, 171, 266, 281, 287, 407
widoczno') transakcji, 167

cykl (yciowy widoczno'ci rekordu, 168
konflikty podczas blokowania rekordów,

171

serializacja, 172
uaktualnienia, 169
usuni#cie, 173
vacuum, 176
wewn#trzne mechanizmy okre'laj"ce

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

wej'cia-wyj'cia, 100

Window, 311, 434, 437

kumulowanie wyniku, 311
numerowanie, 311

WindowAgg, 274
Windows, 107
WITH, 434
WITH RECURSIVE, 434
wolne wykonywanie funkcji i polece8

sk$adowanych, 423

work_mem, 111, 117, 160, 269, 296, 297, 418
Write-Ahead Log, 48, 156, 382
writeback, 107
written_per_sec, 339, 340
wspó$bie(ne tworzenie indeksu, 243
wybór wersji PostgreSQL, 23

Wyszukiwarka

Podobne podstrony:
informatyka wysoko wydajne mysql optymalizacja archiwizacja replikacja wydanie ii pelna lista autoro
Wysoko wydajny PostgreSQL 9 0
Wysoko wydajny PostgreSQL 9 0 2
Wysoko wydajny PostgreSQL 9 0 wyssql
Wysoko wydajny PostgreSQL 9 0
Wysoko wydajny PostgreSQL 9 0 wyssql
informatyka optymalizacja wydajnosci aplikacji na android herv guihot ebook
informatyka jeszcze wydajniejsze witryny internetowe przyspieszanie dzialania serwisow www steve sou
Wniosek o udzielenie informacji o wysokości należności wpłaconej z tytułu opłaty skarbowej
Informacja o wysokości opłat skarbowych, OCHRONA ŚRODOWISKA
informatyka html5 zaawansowane programowanie peter lubbers ebook
Windows Server 2003 Wysoko wydajne rozwiazania w23wys
informatyka jquery poradnik programisty wlodzimierz gajda ebook
informatyka php i jquery receptury vijay joshi ebook
informatyka android 3 tworzenie aplikacji satya komatineni ebook
Windows Server 2003 Wysoko wydajne rozwiazania w23wys

więcej podobnych podstron