Prowadzę szereg projektów, których celem w życiu jest ułatwienie testowania fragmentów PostgreSQL. Wszystkie te otrzymały przyzwoitą aktualizację w ciągu ostatniego tygodnia.
skalowanie strumienia testuje wzrost szybkości pamięci na serwerach w miarę wprowadzania do gry większej liczby rdzeni. To fascynujące dane, wystarczająco dużo, by zacząć dostrzegać prawdziwe trendy. Teraz działa poprawnie na systemach z dużą ilością pamięci podręcznej procesora, ponieważ mają one wiele rdzeni. Wcześniej możliwe było, że był tak agresywny w ustalaniu rozmiaru zestawu testowego, aby uniknąć wpływu na pamięć podręczną, że zużywał więcej pamięci, niż można było przydzielić przy obecnym projekcie kodu strumienia. To zostało zmniejszone. Jeśli masz serwer 48-rdzeniowy lub większy, mógłbym przeprowadzić więcej testów tego nowego kodu, aby sprawdzić, czy nowy sposób, w jaki sobie z tym poradzę, ma sens.
peg to skrypt, który napisałem, aby ułatwić budowanie PostgreSQL ze źródeł, zwykle do pracy programistycznej lub do tymczasowego wypróbowania nowszej wersji w systemie produkcyjnym. Bardzo łatwo było się pomylić z przełączaniem się między projektami i powiązanymi z nimi gałęziami git; dokumentacja w tym obszarze jest znacznie ulepszona.
pgbench-tools to moja pracownia testowania wydajności, która pozwala ustawić w kolejce dni wartości benchmarku, a następnie mieć wystarczającą ilość dostępnych narzędzi analitycznych, aby to zrozumieć. Program śledzi teraz ostatnio wprowadzony parametr pg_stat_bgwriter.buffers_backend_fsync, jeśli masz wersję, która go obsługuje (obecnie tylko ostatnia kompilacja soure – co sprowadza nas z powrotem do tego, dlaczego peg jest przydatny). Możesz również powiedzieć mu, aby uruchamiał każdy test przez określony czas, co znacznie ułatwia testowanie przy bardzo różnych wartościach klienta/rozmiaru.
Jeśli chodzi o to, co możesz zrobić z pgbench-tools… od dzisiaj dzielę się testami porównawczymi, które wykonuję na PostgreSQL 9.1 na najpotężniejszym serwerze, z którego mam nieograniczone korzystanie. 8 rdzeni, 16 GB RAM, 3 dyskowe dyski bazy danych RAID-0, 1 dyskowy wolumin WAL, pamięć podręczna Areca podtrzymywana bateryjnie. Możesz zobaczyć wyniki. Przebiegi są zorganizowane w zestawy testowe, z których każdy reprezentuje pewien rodzaj zmiany w konfiguracji. Na przykład, nr 1 w tych danych uruchamia tylko SELECT, nr 2 działa w stylu TPC-B, ale z 8 GB pamięci RAM i wcześniejszym kodem, podczas gdy gorące rzeczy to nr 3, uruchamiając TPC-B z 16 GB pamięci RAM i kodem, który śledzi buffers_backend_fsyncs.
W kolejce PostgreSQL 9.1 znajduje się kilka poprawek związanych z wydajnością w obszarach wyróżnionych przez te wyniki - że Linux może mieć wyjątkowo wysokie opóźnienia w najgorszym przypadku przy obciążeniach bazy danych o dużym natężeniu zapisu. Dobrym przeciętnym przykładem jest test 215:skala 1000, 32 klientów, 365 TPS. Ale najgorsze opóźnienie to 43 sekundy, a na wykresie TPS widać martwe punkty. To po prostu okropne i istnieje kilka koncepcji, jak to zrobić.
Jeśli ktoś, kto to czyta, ma potężny serwer dostępny przez kilka tygodni do przeprowadzania takich testów, z przyjemnością pomogę ci zreplikować to środowisko i zobaczyć, jakie wyniki widzisz. Jedyną magią, jaką mam, jest trochę praktyki w ustawianiu skalowania i obciążenia klientów, aby nie tracić dużo czasu na bezproduktywne testy. Reszta mojego procesu jest bezpłatna i udokumentowana.
