Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.


10.06.2019

Inteligentne zarządzanie...

W dniach 11, 12 i 13 czerwca – odpowiednio – w Gdańsku, w Warszawie i w Katowicach,...
27.05.2019

Rozwiązania na platformie GCP

Citrix SD-WAN i Citrix ADC
27.05.2019

Chmura hybrydowa

Dell Technologies Cloud
27.05.2019

Uproszczona komunikacja

Cisco Webex
24.05.2019

Konferencja IT Manager of...

W dniach 12–14 czerwca w Sopocie odbędzie się konferencja IT Manager of Tomorrow 2019. To...
24.05.2019

Ochrona sieci

Fortinet FortiOS 6.2
24.05.2019

Mniejsza złożoność

Rittal VX25 Ri4Power
24.05.2019

All-in-one NAS

QNAP TDS-16489U R2
24.05.2019

Układy SoC

AMD Ryzen Embedded R1000

Optymalizacja parametrów konfiguracji PostgreSQL

Data publikacji: 23-05-2019 Autor: Mariusz Ferdyn
Rys. 1. Wielkości bazy danych...

Analizując ustawienia stosowane przez największych dostawców chmury publicznej Microsoft Azure Database for MySQL oraz Amazon Relational Database Service (RDS), w poprzednim artykule opisaliśmy optymalną konfigurację MySQL. Tym razem na warsztat bierzemy bazę danych PostgreSQL.

 

W jednym z poprzednich wydań „IT Professional” (numer 3/2019, s. 24) porównaliśmy konfigurację wzorcową (wraz ze zmieniającymi się podczas skalowania parametrami), jaką najczęściej można spotkać w środowiskach on-premise, z konfiguracją dostarczaną w ramach usług chmury publicznej przez Microsoft i Amazon. Kolejną bazą danych, której optymalizacją się zajmiemy, będzie PostgreSQL.

> INSTANCJE USŁUGI AZURE DATABASE FOR POSTGRESQL

Na początek przyjrzymy się, jakie parametry są zmieniane podczas skalowania u najpopularniejszych dostawców chmury publicznej, a następnie porównamy je z instancją domyślną. Na tej podstawie będzie można wydedukować, które ustawienia i opcje należy modyfikować podczas skalowania bazy danych PostgreSQL.

W pierwszym kroku zakładamy trzy instancje usługi Azure Database for PostgreSQL w wersji 10 o następujących parametrach:
 

  • 2vCores, 50 GB – bez specyfikacji IOPS, Basic – 54,86 euro /mc,
  • 8vCores, 667 GB – 2001 IOPS, General Purpose – 599,56 euro/mc,
  • 32vCores, 2014 GB – 6000 IOPS, Memory Optimized – 3101,28 euro/mc.


Po porównaniu parametrów zwróconych po wykonaniu polecenia show all odkrywamy, że niektóre parametry są modyfikowane wraz ze skalowaniem instancji w Microsoft Azure. Modyfikowane parametry skalowanej instancji wraz z opisami przedstawiono poniżej, a zestawienie różnic w tabeli 1:
 

  • archive_mode – jeżeli ten parametr jest włączony, wówczas archiwalne pliki dziennika (patrz wyjaśnienie Write-Ahead Logging) są zapisywane przez archive_command. W logach rejestrowane są wszystkie transakcje w bazie danych (czyli operacja zmiany jej zawartości). Następnie transakcje te są przepisywane do plików bazy danych. Jeżeli log osiągnie zakładaną wielkość, jest archiwizowany lub nadpisywany (zależy od ustawienia parametru archive_mode). Mechanizm działa tak samo jak Redolog i Archive Log w bazach danych Oracle. Archiwalne logi mogą być użyte do odzyskania zawartości bazy danych w określonym czasie lub określonej transakcji.
  • autovacuum_analyze_scale_factor, autovacuum_vacuum_scale_factor – współczynnik wielkości tabeli w rekordach dodanych do autovacuum_vacuum_threshold i autovacuum_analyze_threshold. Po osiąg­nięciu wielkości ustawionej w drugim z wymienionych parametrów (we wszystkich analizowanych przypadkach ustawionych na wartość domyślną 50) baza danych rozpocznie proces czyszczenia pliku bazy danych (proces VACUUM) i odświeżania statystyk (proces ANALYZE). Tak samo po osiągnięciu wielkości nowych, zmienionych lub skasowanych rekordów w tabeli określonej w autovacuum_analyze_threshold (tu również domyślna wartość to 50), nastąpi ponowne zbieranie statystyk. Statystyki te są niezbędne do prawidłowego budowania planu zapytań do bazy danych.
  • autovacuum_naptime – określa minimalne opóźnienie między przebiegami VACUUM i ANALYZE. Co wyspecyfikowany czas baza danych jest sprawdzana i w zależności od potrzeb procesy VACUUM i ANALYZE są uruchamiane. Opóźnienie mierzone jest w sekundach.
  • bgwriter_flush_after – liczba bajtów, po których dane z pamięci cache systemu operacyjnego zapisywane są na dysk (fsync).
  • checkpoint_completion_target – interwał ustawiony w parametrze checkpoint_timeout określający, co jaki czas tworzony jest punkt kontrolny, który przepisuje dane z pliku dziennika do plików bazy danych. Domyślnie wartość to 5 minut. Im większy odstęp czasu, tym dłużej uruchamia się baza, ale wydajność jest większa.
  • checkpoint_flush_after – liczba bajtów zapisanych do bazy danych po wykonaniu punktu kontrolnego, po przekroczeniu której dane z cache systemu operacyjnego zapisywane są na dysk (fsync).
  • effective_cache_size – parametr określający, jaką przestrzeń na pamięć podręczną ma do dyspozycji baza danych podczas wykonywania zapytania. Niska wartość spowoduje, że nie będą wykorzystywane indeksy na tzw. full table scan (czytanie wszystkich danych z dysku).
  • full_page_writes – jeżeli parametr jest włączony, to po wykonaniu punktu kontrolnego zapisywana jest cała strona danych na dysk. Wyłączenie parametru zwiększa wydajność, ale może spowodować utratę danych w razie awarii systemu.
  • maintenance_work_mem – maksymalna ilość pamięci, jaka może być użyta dla takich operacji jak: VACUUM, CREATE INDEX, ALTER TABLE ADD FOREIGN KEY.
  • max_connections – maksymalna liczba połączeń do serwera.
  • max_wal_senders – określa maksymalną liczbę serwerów, do których będą wysyłane pliki dziennika. Domyślna wartość 0 oznacza wyłączoną replikację.
  • max_wal_size – po przekroczeniu wartości zdefiniowanej w tym parametrze wykonywany jest punkt kontrolny i co za tym idzie, zawartość transakcji z logu transakcyjnego przepisywana jest do plików bazy danych.
  • min_wal_size – minimalna wielkość logu transakcyjnego. Jeżeli log transakcyjny nie osiągnie tej wartości, nowy plik WAL nie będzie tworzony.
  • random_page_cost – parametr wykorzystywany przez optymalizator zapytań, wskazujący na koszt dostępu do danych losowo zapisanych w plikach bazy danych. Im wyższy koszt, tym mniejsza preferencja użycia indeksów przez optymalizator.
  • seq_page_cost – parametr, który określa koszt operacji sekwencyjnego dostępu do dysku, im jest on większy, tym optymalizator bardziej preferuje użycie indeksów. Domyślnym ustawieniem dla dysków talerzowych seq_page_cost vs random_page_cost jest 1:4. Dla szybkich SSD można ustawić niemalże 1:1.
  • shared_buffers – podstawowy parametr optymalizacji, który informuje, jak dużo pamięci przeznaczonej jest na cache bazy danych. W systemach bazodanowych najbardziej obciążonym zasobem jest zazwyczaj podsystem dyskowy, tak więc wskazane jest posiadanie jak największej części bazy danych w pamięci RAM. Zalecane ustawienia dla tego parametru to 25–40% wielkości pamięci RAM.
  • wal_buffers – wielkość pamięci podręcznej cache używanej przy zapisie dziennika zdarzeń. Jeżeli parametr ma wartość -1, wówczas do tego celu użyte zostanie około 3% wartości zdefiniowanej w parametrze shared_buffers. Ustawienie dużych wartości rzadko kiedy powoduje poprawę wydajności (i tak zazwyczaj wcześniej wykonywany jest punkt kontrolny).
  • wal_level – wartość domyślna to minimal, która zapisuje tylko informacje potrzebne do odzyskania bazy systemu po awarii lub natychmiastowym wyłączeniu (przepisanie niezapisanych informacji z logu do plików bazy danych). Wartość archive dodaje rejestrację wymaganą do archiwizacji WAL. Z kolei hot_standby dodaje informacje wymagane do uruchomienia zapytań (tylko do odczytu) na serwerze rezerwowym.

 

[...]

 

W świecie IT od ponad 20 lat. Początkowo współpracownik periodyków „Bajtek” i „Commodore & Amiga”. Od 2000 roku specjalizuje się w technologiach Microsoftu. Pełnił funkcję Technical Learning Guide podczas największych konferencji Microsoft TechEd i Ignite w USA. Obecnie ekspert w dziedzinie rozwiązań chmur prywatnych i publicznych w szczególności Microsoft Azure. 

Artykuł pochodzi z miesięcznika: IT Professional

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"