Zpomalujici se Pg
Horak Daniel
horak na sit.plzen-city.cz
Pátek Listopad 1 10:54:07 CET 2002
> mam takovy problem - tusim ze neco podobneho zminoval
> Michal Krause,
> kdyz jsem se s nim bavil na Invexu. Jde o to, ze se postgres
> postupne zpomaluje
> az do uplneho zpomaleni. Modelovy priklad:
>
> Tabulka:
> create table sa_ping_kas (id int primary key, txt varchar(256));
>
> Naplneni:
> insert into sa_ping_kas ($_, 'rand(999)')
> kde $_ je od 1 do 1000, rand(999) je realne cislo prevedene
> na retezec.
>
> V cyklu spoustim tento kod:
>
> for my $run (1..1000) {
> my $start = time;
> for my $iter (1..100) {
> my $start = 1+ int(rand(980));
> my $text = rand(999);
> $dbh->do("update sa_ping_kas set txt = '$text' "
> . " where id >= $start and id <= ".
> ($start + 19));
> }
> print time-$start, "\n";
> system 'sync';
> sleep 2;
> }
>
> cili v podstate delam update nahodne vybranych 20 vedle sebe lezicich
> radku tak, ze menim hodnotu "txt" na neco jineho nez predtim.
> Kdyz tohle spustim, tak mi to vypisuje cisla okolo dvou sekund, ktera
> se postupne zvysuji (zatim po cca 60 iteracich jsem u 5 sekund).
Vychazi mi z toho, ze je provedeno 1200 updatu na tabulce s 1000 zaznamu
=> tabulka naroste na vice nez dvojnasobek. Duvod je uveden nize.
> Kdyz dam "vacuum sa_ping_kas", tak se to zase zrychli na 2 sekundy.
Po "vacuum" zustane zase jen 1000 zaznamu.
>
> Podobny problem mam i u jine situace - tam mam tabulku s
> primarnim klicem
> typu varchar(64) a snazim se delat
>
> select primarni_klic from tabulka order by primarni_klic
jaky je EXPLAIN?
>
> Tohle se taky cim dal vic zpomaluje s tim, jak do tabulky
> delam updaty.
> A po vacuum se to vyrazne zrychli.
Tady je nejspis problem s tim, ze krome vlastni tabulky narusta i index.
>
> Cili dotazy:
>
> - Proc vacuum kdyz v tabulce nepridavam ani nerusim zaznamy?
Protoze PostgreSQL neprepisuje zaznamy, na kterych provadim UPDATE, ale
zaklada nove.
> - Jak muze byt pomale vyhledani podle primarniho klice, kdyz rozlozeni
> hodnot v tabulce je naprosto rovnomerne?
> - Proc se teda Pg nerozhodne cas od casu ten index prepocitat sam,
> kdyz uz je jasne, ze je nekde neco spatne.
> - Jak tenhle problem odstranit, pokud nechci periodicky po nekolika
> malo hodinach delat vacuum?
Napsat storage manager, ktery bude umet "neplatne" radky znovu pouzit -
urcite je to v TODO.
Dan
Další informace o konferenci Test