Všechny reference
Platební služby

Optimalizace produkční databáze

Slovenský agregátor SMS mikroplateb

Předchozí optimalizace nezabíraly — skutečná příčina byla na rozhraní databáze a aplikačního kódu. Cíleným reverzibilním zásahem jsme snížili zátěž bez výpadku provozu.

CPU zátěž 50–60 % → ~20 %, dlouhodobě

Výzva

CPU produkční databáze se dlouhodobě drželo na 50–60 %, přes den ve špičkách výše. Klient už zkoušel několik optimalizací bez efektu a hrozila mu investice do výkonnějšího hardwaru.

Řešení

Diagnostikovali jsme jen s read-only přístupem do produkce. Kombinací statistik dotazů, vzorkování aktivních spojení, exekučních plánů a rozboru aplikačního kódu jsme našli kořenovou příčinu, kterou souhrnné statistiky skrývaly — a odstranili ji cíleným, plně reverzibilním zásahem bez výpadku.

Výsledky:

  • CPU zátěž z 50–60 % na přibližně 20 % — pokles o více než polovinu
  • Snížení se drží dlouhodobě; odpadla potřeba investice do silnějšího hardwaru
  • Zásah nasazen bez výpadku, s měřením dopadu po každém kroku (služba po službě)
  • Diagnostika jen s read-only přístupem — bez rizika pro chod systému

Příčina, kterou statistiky neukazovaly

Většinu CPU nespotřebovávalo zpracování dat, ale režie — databáze při každém spuštění znovu kompilovala krátké, velmi časté dotazy, které se pro způsob skládání v aplikacích nedaly cachovat. Režie se opakovala nonstop bez užitku. Odhalilo ji až přímé měření toho, co reálně běží na CPU, spojené se čtením aplikačního kódu.

Bezpečně, v produkci

Režii jsme vypnuli cíleně jen pro transakční aplikační spojení, službu po službě, a po každém kroku změřili dopad. Analytická spojení, kde má opodstatnění, jsme nechali nedotčená. Změna je plně reverzibilní — přesně takový přístup, jaký umožňuje dělat optimalizace rychle a s pomocí AI v procesu práce, ale vždy přes důkaz, ne odhad.

Máte podobný projekt?

Řekněte nám, co řešíte — ozveme se s návrhem, jak to udělat rychle a měřitelně.

Nezávazná konzultace