Sytuacja Mam bazę danych postgresql 9.2, która jest dość mocno aktualizowana przez cały czas. System jest więc związany z I / O, a obecnie rozważam wprowadzenie kolejnej aktualizacji, potrzebuję tylko kilku wskazówek, od czego zacząć ulepszanie.
Oto zdjęcie, jak wyglądała sytuacja w ciągu ostatnich 3 miesięcy:
Jak widać, aktualizacja operacji odpowiada za większość wykorzystania dysku. Oto kolejne zdjęcie tego, jak wygląda sytuacja w bardziej szczegółowym 3-godzinnym oknie:
Jak widać, szczytowa prędkość zapisu wynosi około 20 MB / s
Oprogramowanie
Na serwerze działa Ubuntu 12.04 i postgresql 9.2. Typ aktualizacji jest niewielki, zwykle aktualizowany w poszczególnych wierszach identyfikowanych przez identyfikator. Np UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id. Usunąłem i zoptymalizowałem indeksy tak bardzo, jak myślę, że jest to możliwe, a konfiguracja serwerów (zarówno jądra Linuksa, jak i postgres conf) jest dość zoptymalizowana.
Sprzęt Sprzęt to dedykowany serwer z 32 GB pamięci RAM ECC, 4x 600 GB 15 000 obr./min. Dyski SAS w macierzy RAID 10, kontrolowane przez kontroler RAID LSI z BBU i procesorem Intel Xeon E3-1245 Quadcore.
pytania
- Czy wydajność widoczna na wykresach jest rozsądna dla systemu tego kalibru (odczyt / zapis)?
- Czy powinienem w związku z tym skupić się na aktualizacji sprzętu lub dokładniej zbadać oprogramowanie (poprawianie jądra, konfesjonały, zapytania itp.)?
- Czy w przypadku aktualizacji sprzętu liczba dysków ma kluczowe znaczenie dla wydajności?
------------------------------AKTUALIZACJA------------------- ----------------
Zaktualizowałem teraz mój serwer bazy danych o cztery dyski SSD Intel 520 zamiast starych 15k dysków SAS. Używam tego samego kontrolera RAID. Rzeczy uległy znacznej poprawie, jak widać po tym, jak szczytowa wydajność we / wy poprawiła się około 6-10 razy - i to świetnie!
Spodziewałem się jednak czegoś więcej niż 20–50-krotnej poprawy, zgodnie z odpowiedziami i możliwościami we / wy nowych dysków SSD. Oto kolejne pytanie.
Nowe pytanie Czy w mojej obecnej konfiguracji jest coś, co ogranicza wydajność I / O mojego systemu (gdzie jest wąskie gardło)?
Moje konfiguracje:
/etc/postgresql/9.2/main/postgresql.conf
data_directory = '/var/lib/postgresql/9.2/main'
hba_file = '/etc/postgresql/9.2/main/pg_hba.conf'
ident_file = '/etc/postgresql/9.2/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/9.2-main.pid'
listen_addresses = '192.168.0.4, localhost'
port = 5432
unix_socket_directory = '/var/run/postgresql'
wal_level = hot_standby
synchronous_commit = on
checkpoint_timeout = 10min
archive_mode = on
archive_command = 'rsync -a %p [email protected]:/var/lib/postgresql/9.2/wals/%f </dev/null'
max_wal_senders = 1
wal_keep_segments = 32
hot_standby = on
log_line_prefix = '%t '
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
default_statistics_target = 100
maintenance_work_mem = 1920MB
checkpoint_completion_target = 0.7
effective_cache_size = 22GB
work_mem = 160MB
wal_buffers = 16MB
checkpoint_segments = 32
shared_buffers = 7680MB
max_connections = 400
/etc/sysctl.conf
# sysctl config
#net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
# ipv6 settings (no autoconfiguration)
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.default.accept_dad=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.accept_ra_defrtr=0
net.ipv6.conf.default.accept_ra_rtr_pref=0
net.ipv6.conf.default.accept_ra_pinfo=0
net.ipv6.conf.default.accept_source_route=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_dad=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.accept_ra_defrtr=0
net.ipv6.conf.all.accept_ra_rtr_pref=0
net.ipv6.conf.all.accept_ra_pinfo=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.forwarding=0
# Updated according to postgresql tuning
vm.dirty_ratio = 10
vm.dirty_background_ratio = 1
vm.swappiness = 0
vm.overcommit_memory = 2
kernel.sched_autogroup_enabled = 0
kernel.sched_migration_cost = 50000000
/etc/sysctl.d/30-postgresql-shm.conf
# Shared memory settings for PostgreSQL
# Note that if another program uses shared memory as well, you will have to
# coordinate the size settings between the two.
# Maximum size of shared memory segment in bytes
#kernel.shmmax = 33554432
# Maximum total size of shared memory in pages (normally 4096 bytes)
#kernel.shmall = 2097152
kernel.shmmax = 8589934592
kernel.shmall = 17179869184
# Updated according to postgresql tuningWyjście z MegaCli64 -LDInfo -LAll -aAll
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :
RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0
Size : 446.125 GB
Sector Size : 512
Is VD emulated : No
Mirror Data : 446.125 GB
State : Optimal
Strip Size : 64 KB
Number Of Drives per span:2
Span Depth : 2
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disk's Default
Encryption Type : None
Is VD Cached: Noźródło
synchronous_commit = offpo przeczytaniu dokumentacji na postgresql.org/docs/9.2/static/wal-async-commit.html . (3). Jak wygląda twoja konfiguracja? Na przykład. wyniki tego zapytania:SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');synchronous_commit: „Odpowiedzi:
Tak, ponieważ dysk twardy - nawet SAS - ma głowicę, która wymaga czasu.
Chcesz HUGH upgrade?
Zabij dyski SAS, przejdź do SATA. Podłącz dysk SSD SATA - na poziomie korporacyjnym, jak Samsung 843T.
Wynik? Możesz wykonać około 60 000 (czyli 60 tysięcy) operacji IOPS na dysk.
To jest powód, dla którego dyski SSD są zabójcami w przestrzeni DB i są o wiele tańsze niż jakikolwiek dysk SAS. Phyiscal spinning disc po prostu nie nadąża za możliwościami IOPS dysków.
Twoje dyski SAS były kiepskim wyborem na początek (zbyt duże, aby uzyskać dużo IOPS). Dla bazy danych o wyższym zastosowaniu (więcej mniejszych dysków oznaczałoby znacznie więcej IOPS), ale na końcu SSD jest tutaj zmiennikiem.
Odnośnie oprogramowania / jądra. Każda porządna baza danych zrobi dużo IOPS i opróżni bufory. Plik dziennika musi być NAPISANY, aby zagwarantować podstawowe warunki ACID. Jedyne melodie jądra, które możesz zrobić, unieważniłyby twoją integralność transakcyjną - częściowo MOŻESZ to zrobić. Kontroler RAID w trybie zapisu wstecznego zrobi to - potwierdzi zapis jako wyczyszczony, nawet jeśli nie jest - ale może to zrobić, ponieważ zakłada się, że BBU zabezpiecza dzień, w którym nastąpi awaria zasilania. Wszystko, co robisz wyżej w jądrze - lepiej wiedzieć, że możesz żyć z negatywnymi skutkami ubocznymi.
Na koniec bazy danych wymagają IOPS i możesz być zaskoczony, jak niewielka jest twoja konfiguracja w porównaniu z innymi tutaj. Widziałem dane z ponad 100 dyskami, aby uzyskać potrzebne IOPS. Ale tak naprawdę dzisiaj kupujesz dyski SSD i decydujesz się na ich rozmiar - są tak doskonałe w zakresie możliwości IOPS, że nie ma sensu walczyć w tej grze z dyskami SAS.
I tak, twoje numery IOPS nie wyglądają źle dla sprzętu. W granicach tego, czego bym się spodziewał.
źródło
Jeśli możesz sobie na to pozwolić, umieść pg_xlog na osobnej parze dysków RAID 1 na swoim własnym kontrolerze z zasilaną bateryjnie pamięcią RAM skonfigurowaną do zapisu wstecznego. Jest to prawdą, nawet jeśli musisz użyć wirującej rdzy dla pg_xlog, podczas gdy wszystko inne znajduje się na dysku SSD.
Jeśli używasz dysku SSD, upewnij się, że ma on superkondensator lub inne środki, aby zachować wszystkie buforowane dane w przypadku awarii zasilania.
Ogólnie rzecz biorąc, więcej wrzecion oznacza większą przepustowość we / wy.
źródło
Zakładając, że korzystasz z systemu Linux, pamiętaj o ustawieniu harmonogramu dyskowego we / wy.
Z dotychczasowych doświadczeń przejście na noop da ci dość znaczne przyspieszenie (szczególnie w przypadku dysków SSD).
Zmiana harmonogramu we / wy może być wykonana w locie bez przestojów.
to znaczy. echo noop> / sys / block // queue / scheduler
Zobacz: http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/, aby uzyskać więcej informacji.
źródło