Logování pomalých dotazů v PostgreSQL

Na produkčním prostředí jsem se snažil zjistit, které dotazy databázi nejvíce vytěžují.

Mile mě překvapilo, jak mocný je v tomto ohledu PostgreSQL.

Jednoduché logování dotazů, jejichž čas zpracování trvá více jak monitorovaný čas mě umožnil identifikovat dotazy, o kterých jsem ani netušil, že by mohli dělat problém.

Stačí v postgresql.conf zapnout magický přepínač log_min_duration_statement, který je defaultně vypnutý.

Pokud ho nastavím takto

log_min_duration_statement=100

tak mi do logu databáze zapíše dotazy, které trvají více jak 100ms.
Pak už přichází ke slovu klasický explain a refaktoring.

Nejkrásnější filmová melodie

Nedělní odpoledne se sedmi statečnými

Moje první video

Continuous delivery v jPower8

Náš produkt nasazujeme produkci každé dva týdny. Máme tak nastavený sprint cyklus.

 Celý proces je (skoro) plně automatický.


Zdrojáky verzujeme v svn (migraci na git plánujeme).

Stabilitu buildu udržuje TeamCity, které

• provádí unit testy,
• spouští seleniové (integrační) testy,
• nasazuje na testovací prostředí a
• provádí statickou analýzu kódu.

Doba od commitu do nasazení na test je cca 15 minut.

Pro upečení stabilního verze používáme maven-release-plugin, který se postará o to, že zvedne verzi ve všech pomech, otaguje verzi v svn a uloží upečený build do artifactory. To vše se děje jedním stiskem tlačítka na TeamCity.

Posledním krokem je samotné nasazení waru na produkční prostředí. To dělám kvůli svému pocitu důležitosti ještě stále ručně (a protože nechci, aby TeamCity mělo na produkci přístup).

Samostatnou kapitolou je aplikace migračního databázového skriptu. Ještě donedávna jsme ji prováděli ručně, což sebou neslo riziko lidské chyby a hlavně velkého opruzu.

Pokud je například potřeba přejmenovat sloupec do tabulky, přidat index, změnit constraint, vývojář commitnul migrační sql sript do svn. Dále musel změnu aplikovat u sebe lokálně minimálně na dvou databázích - jedna pro unit testy a druhá pro lokální vývoj. Dále musel změnu provést na testovacím prostředí na dalších třech databázích. Ostatní vývojáři si také museli tuto změnu aplikovat u sebe lokálně. No prostě opruz až na půdu.

Tuto příjemnou činnost jsme hodili na framework flyway. Má přesně takovou složitost, jakou jsme byli ochotni akceptovat. Do databáze přidal jednu tabulku, ze které je naprosto zřejmé, které migrační skripty už v databázi jsou aplikované. Vše je plně automatické a v režii spring beany. Jednoduché jako facka.

A jak jste se zaváděním continuous delivery vy?

Zákaz tisku tlustých knih

Přes víkend jsem zhltnul první díl výborné Přemyslovské epopeje od Vladislava Vondrušky.

Další díl jsem si chtěl koupit v iBook storu, ale pešek! Je vydaná jen papírově! Není to žádná anorektická slečinka, ale pořádná 600ti stránková šťabajzna. Když se podívám na svůj noční stolek, jak se pod náporem jí podobných prohýbá, uvítal bych možnost koupě v elektronické podobě. Přece jen můj iPad má v tomto ohledu větší nosnost než sektorový nábytek.

Nakladatelé, přestaňte knížky tisknout a začněte je vydávat! 

Kradu jako umělec

Na iTunes jsem narazil na další pecku nakladatelství Melvil.

Jde o brutálně zjednodušenný výtah rad k odblokování tvůrčího ducha.

Jednu radu jsem hned aplikoval, vytáhl blok, pastelky a design rezervačního formuláře pro náš produkt jdemenato jsem vysmrkl ručně.

Vykradl (nechal se inspirovat) jsem kalendář Googlu, iCalu a Outlooku. Konkurenční systémy jsem ani vykrást nemohl, neb opakující se rezervace vůbec nepodporují.

Pastelky, ořezávátko a papíry jsou už nedílnou součástí mého analogového stolu.

A co vy? Pamatujete si ještě ze školky co jsou to pastelky?