Поддържам редица проекти, чиято цел в живота е да улесня тестването на части от PostgreSQL. Всички те получиха приличен надстрой през тази миналата седмица.
мащабирането на потока тества как скоростта на паметта се увеличава на сървърите, тъй като повече ядра се включват в игра. Това са завладяващи данни, достатъчно от тях, за да започнете да виждате някои реални тенденции. Сега работи правилно на системи с големи количества кеш на процесора, защото имат много ядра. Преди беше възможно да бъде толкова агресивен с оразмеряването на тестовия набор, за да се избегне влиянието на кеша, че да използва повече памет, отколкото може да бъде разпределено с текущия дизайн на кода на потока. Това е намалено. Ако имате 48-ядрен сървър или по-голям, мога да използвам още малко тестване на този нов код, за да видя дали новият начин, по който се справям с това, има смисъл.
peg е скрипт, който написах, за да улесня изграждането на PostgreSQL от източник, обикновено за работа с разработчици или за временно изпробване на по-нова версия в производствена система. Беше много лесно да се объркате с превключването между проекти и свързаните с тях клонове на git преди; документацията в тази област е значително подобрена.
pgbench-tools е моята работна къща за тестване на производителността, която ви позволява да наредите на опашката стойности на бенчмарк и след това да разполагате с достатъчно инструменти за анализ, за да разберете това. Програмата вече проследява наскоро въведения параметър pg_stat_bgwriter.buffers_backend_fsync, ако имате версия, която го поддържа (понастоящем само скорошна soure build – което ни връща към защо peg е полезен). Можете също да му кажете да изпълнява всеки тест за фиксиран период от време, което прави тестването при изключително различни стойности на клиент/размер много по-лесно.
Що се отнася до това, което можете да правите с pgbench-tools...от днес споделям тестовете за сравнителен анализ, които правя на PostgreSQL 9.1 на най-мощния сървър, който използвам неограничено. 8 ядра, 16GB RAM, 3 дискови RAID-0 устройства с база данни, 1 диск WAL том, кеш памет Areca с батерии. Можете да видите резултатите. Изпълненията са организирани в тестови набори, всеки от които представлява някаква промяна в конфигурацията. Например, #1 в тези данни изпълнява само SELECT, #2 работи като TPC-B, но с 8GB RAM и по-ранен код, докато горещите неща са #3, изпълнявайки TPC-B с 16GB RAM и код, който проследява buffers_backend_fsyncs.
Има няколко корекции в опашката на PostgreSQL 9.1, свързани с производителността в областите, подчертани от тези резултати – че Linux може да има изключително голяма латентност в най-лошия случай при натоварване на база данни с тежък запис. Добър среден пример е тест 215: скала от 1000, 32 клиента, 365 TPS., Но в най-лошия случай латентността е 43 секунди и можете да видите мъртвите точки в графиката на TPS. Това е просто ужасно и има няколко концепции как да се направи точно това.
Ако някой, който чете това, разполага с мощен сървър за няколко седмици за провеждане на тестове като този, ще се радвам да ви помогна да репликирате тази среда и да видите какви резултати виждате. Единствената магия, която имам, е известна практика как да настроите мащабирането и клиентското натоварване, така че да не губите много време за непродуктивни тестове. Останалата част от моя процес е безплатна и документирана.
