Днес е крайният срок за специалната цена на стаята в хотела, който е домакин на тази месец PostgreSQL Conference East 2010. Ако отлагате резервирането на място на конференцията, от утре това ще започне да ви струва.
Моят разговор е за хардуерния сравнителен анализ на базата данни и е насрочен за късния следобед на първия ден, четвъртък, 25 март. Тези, които може би са виждали този разговор преди, или на живо на PGCon 2009, или чрез наличната там видео връзка, може да се чудят дали ще изтегля същите слайдове и ще говоря отново. Не е така; докато общата философия на разговора („не се доверявайте на никого, изпълнявайте свои собствени показатели“) остава същата, предложените примери и тестов микс бяха актуализирани, за да отразяват още една година хардуерни постижения, работа на PostgreSQL и моите собствени изследвания по време на това време. По-специално ситуацията на Intel срещу AMD се промени доста, изисквайки нов набор от сравнителни показатели на паметта, за да следват наистина какво се случва в момента.
А PostgreSQL 9.0 отстрани сериозен проблем, който му пречеше да предоставя нормално точни резултати в Linux, поради регресия на ядрото, която влоши и без това твърде често срещана ситуация: лесно е един клиент на pgbench да се превърне в пречка, когато го изпълнява, по-скоро отколкото самата база данни. Прегледът, който направих за многонишковия pgbench (който също може да бъде многопроцесен pgbench на системи, които не поддържат нишки), предложи солидно>30% ускорение дори на системи, които нямат лоша несъвместимост на ядрото. Последващите тестове показват, че може лесно да са необходими 8 pgbench процеса, за да се получи пълна пропускателна способност дори от евтини съвременни процесори под последните ядра на Linux. Ще разгледам как точно това се случва в такива системи и как тази нова функция дава възможност отново да се използва pgbench като основен начин за измерване на производителността на процесора, работещ с базата данни.
Наскоро направих и актуализирана версия на git repo за pgbench-tools, която добавя работеща поддръжка за PostgreSQL 8.4 и основна 9.0 съвместимост, а следващата актуализация ще включва поддръжка за многонишковата опция сега, когато начертах как това трябва да работи. Всичко това води нанякъде. След като имаме точни измервания за производителността на PostgreSQL, които са ограничени от CPU от страна на сървъра, нещо, което не се е случвало често повече от две години, те отново се превръщат в полезен начин за наблюдение за регресия на производителността в кодовата база на PostgreSQL. Включените тестове ще трябва да се разширят, за да обхванат повече в крайна сметка, но засега сме достигнали точка, в която pgbench може да се използва за намиране на регресии, които влияят върху това колко бързо се изпълняват прости оператори SELECT. Знам, че работи според очакванията, защото всеки път, когато случайно създам PostgreSQL с твърдения, това се улавя, защото виждам, че средната скорост на обработка пада драстично.
След като имам няколко настройки на системи тук, за да тествам за такива регресии, въпросът става как да автоматизирам това, което правя, и след това да направя същото нещо срещу по-широк спектър от проверки на компилации. В идеалния случай бихте могли да виждате графика на средната производителност на SELECT всеки ден, разбита по версия, така че когато бъде въведен комит, който го намалява, веднага да бъде очевидно, когато производителността спадне. Това е мечтаната цел за изграждане на ферма за производителност, подобна на PostgreSQL buildfarm. Частите вече са почти всички заедно: частите ми за pgbench се приготвят, разширенията към buildfarm, за да го накарат да говори директно с git, се движат (не е изискване, но никой, който работи по този проект, не иска да използва CVS, ако можем да го избегнем) , а основното нещо, което липсва в този момент, е някой, който да отдели време, за да интегрирам това, което съм правил, в клиент, подобен на buildfarm.
И изглежда, че сега имаме корпоративен спонсор, който желае да помогне с тази част от работата, на когото ще дам заслуга, когато всички приключим, и това е планирано да се случи това лято. Напълно очаквам, че разработката на PostgreSQL 9.1 и 9.0 backpatching ще се осъществят с ранна ферма за производителност, за да се предпази от регресия на производителността. Ако можем да пренесем новия многонишков pgbench към по-стари версии на PostgreSQL, може да ги включим и в микса. Вече имам бекпорт на 8.3 pgbench, който има много подобрения, поддържам само за тестване на 8.2 системи. С pgbench като доста самостоятелен модул за принос е възможно да се изгради по-късен, различен от останалата част от системата, стига да не се очаква да съществуват и по-нови функции на базата данни.
Ако това е нещо, което ви интересува, моята реч на конференцията ще очертае основите, върху които очаквам да бъде изградена. Независимо от това, надявам се, че можете да стигнете до конференцията и да се насладите на дългия списък с лекции, представени там.
