[ Pobierz całość w formacie PDF ]

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 zapyta . 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 prawdopodobie stwa, 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 zapyta .
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.
161
Wysoko wydajny PostgreSQL 9.0
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 a 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 ró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 a 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 zako czeniu 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.
162
Rozdzia 6. " Optymalizacja konfiguracji serwera
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 i 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ó nienia 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 [ Pobierz całość w formacie PDF ]