Dzisiaj upływa termin otrzymania specjalnej ceny pokoju w hotelu, w którym odbędzie się tegoroczna konferencja PostgreSQL Conference East 2010. Jeśli zwlekasz z rezerwacją miejsca na konferencji, od jutra będzie to kosztować Cię.
Mój wykład dotyczy testu porównawczego sprzętu bazodanowego i jest zaplanowany na późne popołudnie pierwszego dnia, w czwartek 25 marca. Ci, którzy mogli już widzieć tę prelekcję, czy to na żywo na PGCon 2009, czy za pośrednictwem dostępnego tam łącza wideo, mogą się zastanawiać, czy wyciągnę te same slajdy i znów będę mówić. Nie tak; podczas gdy ogólna filozofia rozmowy („nie ufaj nikomu, uruchamiaj własne testy”) pozostaje taka sama, sugerowane przykłady i miks testów zostały zaktualizowane, aby odzwierciedlić postępy w sprzęcie z innego roku, prace nad PostgreSQL i moje własne badania w tym czasie czas. Zwłaszcza sytuacja Intela i AMD uległa znacznej zmianie, co wymaga nowego zestawu testów pamięci, aby naprawdę śledzić to, co się teraz dzieje.
PostgreSQL 9.0 naprawił główny problem, który uniemożliwiał normalne dostarczanie dokładnych wyników w systemie Linux, ze względu na regresję jądra, która znacznie pogorszyła i tak już zbyt powszechną sytuację: pojedynczy klient pgbench może stać się wąskim gardłem podczas jego uruchamiania, a nie niż sama baza danych. Recenzja, którą zrobiłem dla wielowątkowego pgbencha (który może być również wieloprocesowym pgbenchem w systemach, które nie obsługują wątków) sugerowała solidne przyspieszenie>30%, nawet na systemach, które nie miały na nich złej niekompatybilności jądra. Kolejne testy sugerują, że może z łatwością zająć 8 procesów pgbench, aby uzyskać pełną przepustowość nawet niedrogich nowoczesnych procesorów z najnowszymi jądrami Linuksa. Omówię dokładnie, jak to się kończy na takich systemach i jak ta nowa funkcja umożliwia ponowne użycie pgbench jako podstawowego sposobu pomiaru wydajności procesora obsługującego bazę danych.
Ostatnio zrobiłem również aktualizację repozytorium git dla pgbench-tools, która dodaje działającą obsługę PostgreSQL 8.4 i podstawową kompatybilność 9.0, a następna aktualizacja będzie zawierała obsługę opcji wielowątkowej, teraz, gdy zmapowałem, w jaki sposób to musi pracować. To wszystko do czegoś prowadzi. Gdy mamy już dokładne pomiary wydajności PostgreSQL, które są ograniczone przez procesor po stronie serwera, co nie zdarzało się często od ponad dwóch lat, ponownie stają się one użytecznym sposobem monitorowania regresji wydajności w bazie kodu PostgreSQL. Dołączone testy będą musiały zostać rozszerzone, aby w końcu objąć je bardziej, ale na razie osiągnęliśmy punkt, w którym pgbench może być używany do znajdowania regresji, które wpływają na szybkość wykonywania prostych instrukcji SELECT. Wiem, że działa to zgodnie z oczekiwaniami, ponieważ za każdym razem, gdy przypadkowo buduję PostgreSQL z asercjami, które są przechwycone, ponieważ widzę dramatyczny spadek średniej szybkości przetwarzania.
Kiedy już mam kilka systemów skonfigurowanych tutaj do testowania takich regresji, pojawia się pytanie, jak zautomatyzować to, co robię, a następnie zrobić to samo z szerszym zakresem sprawdzania kompilacji. Idealnie byłoby, gdybyś był w stanie zobaczyć wykres średniej wydajności SELECT każdego dnia, z podziałem na wersję, tak aby po wprowadzeniu zmiany, która ją zmniejszyła, od razu widać było, kiedy wydajność spadła. Jest to wymarzony cel zbudowania wydajnej farmy podobnej do buildfarmy PostgreSQL. Elementy są teraz prawie wszystkie razem:moje części pgbench są już pakowane, rozwijają się rozszerzenia buildfarmy, aby przemawiał bezpośrednio do git (nie jest to wymagane, ale nikt pracujący nad tym projektem nie chce używać CVS, jeśli możemy tego uniknąć) , a główną rzeczą, której brakuje w tym momencie, jest ktoś, kto poświęci czas na zintegrowanie tego, co robię, z klientem podobnym do buildfarm.
I wygląda na to, że mamy teraz sponsora korporacyjnego, który chce pomóc w tej części pracy, któremu pozwolę sobie wziąć kredyt, kiedy wszyscy skończymy, a to ma się wydarzyć tego lata. W pełni oczekuję, że rozwój PostgreSQL 9.1 i backpatch 9.0 będzie miał miejsce wraz z wczesną farmą wydajności, aby chronić przed regresją wydajności. Jeśli możemy przeportować nowy wielowątkowy pgbench do starszych wersji PostgreSQL, możemy je również włączyć do miksu. Mam już backport pgbencha 8.3, który ma wiele ulepszeń, które utrzymuję tylko do testowania systemów 8.2. Z pgbench jako dość samodzielnym modułem contrib, możliwe jest zbudowanie późniejszego, innego niż reszta systemu, o ile nie oczekuje się istnienia nowszych funkcji bazy danych.
Jeśli to jest coś, co cię interesuje, moje wystąpienie na konferencji nakreśli podstawy, na których oczekuję, że zostanie zbudowana. Niezależnie od tego, miej nadzieję, że uda Ci się dotrzeć na konferencję i cieszyć się długą listą prezentowanych tam prelekcji.
