GoldenLine
Zaloguj się

konto usunięte

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

Witam,

Czy ktoś spotkał się z problemem dziwnego wzrostu objętości tabeli poprzez operacje UPDATE? Dla przykładu tabela zawiera 6.5 mln rekordów (około 1.2 GB danych) i po 2 miesiącach jej wielkość wzrosła do 30GB, może ktoś wie dlaczego?

Pozdrawiam,

john
Link do wypowiedziLink
Michal Oczak

Michal Oczak sysadmin/webdev

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

wzrosla pewnie z powodu mvcc http://www.onlamp.com/pub/a/onlamp/2001/05/25/postgres...

vacuumdb, reindeksacja, dump/restore - od najwolniejszej(najwiecej miejsca odzyskuje) do najszybszej metody(najmniej) zmniejszenia rozmiaru bazy
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

Witam,

Trochę nie rozumiem jak mam odczytać twoje wskazówki...

Vacuum -> autovacuum=on w postgresql.conf, coś jeszcze "VACUUM FULL table" u mnie trochę za długo trwa (mam do dyspozycji tylko 12 minut czasu)
REINDEX table_idx jest wykonywany po większej zmianie danych, po kluczu nie muszę tego robić bo tam się nic nie zmienia
DUMP & RESTORE, nie bardzo widzę możliwość wykonania tego na bazie która działa nonstop

MVCC, nie bardzo wiem jak mam odebrać dane spod tego url-a, jak one się mają do mojego problemu...

Pozdrawiam,

john
Link do wypowiedziLink
Michal Oczak

Michal Oczak sysadmin/webdev

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

problem przyrostu jest zwiazany z fragmentacja bazy, ta framgentacje powoduje mvcc, implementacja synchronizacji odczytu i zapisu w bazie bez blokowania

autovacuum to nie to, niestety poza tymi metodami ktore wymienilem nie znam innych zeby sobie z tym poradzic, rozumiem ze przerwa na maintaince to 12 minut? to jest problem, nie masz replikacji/backupu na drugiej maszynie ewentualnie nie mozesz zrobic?
Link do wypowiedziLink
Sylwester M.

Sylwester M. --

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

John R.:
Witam,

Czy ktoś spotkał się z problemem dziwnego wzrostu objętości tabeli poprzez operacje UPDATE? Dla przykładu tabela zawiera 6.5 mln rekordów (około 1.2 GB danych) i po 2 miesiącach jej wielkość wzrosła do 30GB, może ktoś wie dlaczego?


hmm, jakos nie zwrocilem uwagi. ale moze i racja z tym rosnieciem i powodem

http://www.linuxinsight.com/optimize_postgresql_databa...

trzeba by pogrzebac. zobaczyc ktora to tabela moze na poczatek, zobaczyc czy to index, czy sama tabela. az w miedzy czasie zobacze sobie sam cos takiego. ile moze byc zapytan w ciagu takich 2 miesiecy ? i czy duzo userow zmieniajacych te same dane, czy raczej w danym momencie kazdy zmienia raczej swoje dane - np w ciagu 1s. jedna tabela z tymi 6mln rek czy kilka tabel ? itd :)

ajc, jeszcze czy 64 czy 32 bit, i zakladam, ze linux ?Sylwester M. edytował(a) ten post dnia 05.07.07 o godzinie 08:42
Link do wypowiedziLink

konto usunięte

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

Witam,

1. Na tabeli pracuje jeden proces który ją aktualizuje, ilość danych nie zmienia się zbyt często (nie częściej niż raz na tydzień)
2. OS to RHEL4 + PostgreSQL 8.2.4 (instalacji z binariów)
3. Platforma to 2xXeon 3.2 + 4GB RAM-u
4. Mam jeszcze maszynę z 8.1.3 (kompilowany) na Slackware 10.2 i tutaj nie zauważyłem tego problemu

Pozdrawiam,

johnJohn R. edytował(a) ten post dnia 05.07.07 o godzinie 17:04
Link do wypowiedziLink
Sylwester M.

Sylwester M. --

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

John R.:
2. OS to RHEL4 + PostgreSQL 8.2.4 (instalacji z binariów)
3. Platforma to 2xXeon 3.2 + 4GB RAM-u

tak tylko mala uwaga. kiedys pg nie lubil xeonow. nie wiem jak teraz. kiedys jak bedziesz mial okazje przetestuj opterony. tak zupelnie z ciekawosci. inna wydajnosc :) testowaem na 3mld (miliardow !) rekordow. dzialalo :D pg 7.4 np nie chcial za bardzo nawet zalozyc intexow

postawilem na szybko testowa instancje i zaladowalem jakis backup - 12mln rekorodow. zaraz zapuszcze jakis test i niech sie kreci przez cala noc. zobaczymy co wyjdzie

tylko, ze srodowisko to bedzie debian, i na opteronach. samodzienie kompilowany pg
Link do wypowiedziLink
Michal Oczak

Michal Oczak sysadmin/webdev

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

przydaloby sie jeszcze troche informacji bo moze to byc jeszcze problem z indeksami specyficzny wlasnie dla 8.2 (przypadek 1.5gb danych - index 35gb)

mozesz wlaczyc stats collectora?
Link do wypowiedziLink
Sylwester M.

Sylwester M. --

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

ogolne wyniki zabawy nocnej

1) system: pg 8.2, debian 64bit, 2x operony
2) baza zaladowana - 1 tabela, 4 integery, 1 real, 1 char (11), ilosc rekordow: 13012701, rozmiar: 950MB, 2 indexy na integery, indeksy maja po 279MB :D

3) test. select ilosci rekordow, podzielilem przez 3 (no tak sobie wybralem),sprawdzilem min i max wartosc klucza glownego, i kazalem skryptowi wykonoac update jednego pola N razy. gdzie N jest 1/3 ilosci rekorodow. czyli mowiac lopotoligocznie

skryp zrobil iles tam updatow == 1/3 ilosci rekordow w tabeli. przy kazdym updacie losowal ktory rekord updatowac - losowo. robil po kazej operacji commita. skrypt wykonal 4337566 updatow. ale zeby jeszcze skomplikowac odpalilem 2 procesy z tymi skryptami - zeby byly jakies locki i inne

efekt ciekawy:
wartosc zmienilo 2527802 rekordow. to dziwne, bo 2 procesy, kazdy po 4337566 updatow - czyli 8675132 updatow w sumie (skutecznosc upodatowania - 29.14% :)). nie miej wartosc zmienilo 19.43% danych w calej tabeli

rozmiar tabeli po operacji: 1156MB
rozmiar indexow: ten po ktorym bylo wyszukiwanie: 557MB, drugi index: 475MB

czyli: baza wzrosla o 21.68%
indexy: w sumie o 94.95%

nie jest tak zle wg mnie. puszcze te skrypty jeszcze raz. niech sobie pracuja.

posumowywujac chyba faktycznie cos jest nie tak z indexami. puchna. pochodzi jeszcze 5 takich skryptow przez dzsiejszy dzien i zobaczmy jaka bedzie zmiana

pzd

p.s.
jeszcze jedna uwaga, moze ktos wie. jakims trafem oba te procesy chodzily na 1 procku. to jeszcze powiedzmy, ze moze tak jakos trafilem. ale teraz chodzi 5 procesow z tym skryptem i wszystkie na jednym procku znowu. he ? o so chodzi ?Sylwester M. edytował(a) ten post dnia 06.07.07 o godzinie 12:56
Link do wypowiedziLink
Michal Oczak

Michal Oczak sysadmin/webdev

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

to nie tyle cos nie tak z indeksami co nowy algorytm ktory jest standardowo wybierany sie nie sprawdza, nie dziala za dobrze przy niektorych rodzajach dystrybucji kluczy

co do mp to przydaloby sie wiecej danych, co za procesy, konfiguracja, statystyki itp
Link do wypowiedziLink
Sylwester M.

Sylwester M. --

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

Michal O.:
to nie tyle cos nie tak z indeksami co nowy algorytm ktory jest standardowo wybierany sie nie sprawdza, nie dziala za dobrze przy niektorych rodzajach dystrybucji kluczy

hmm, masz moze pod reka gdzies link do jakiegos opisu ?
co do mp to przydaloby sie wiecej danych, co za procesy, konfiguracja, statystyki itp

cos to bardziej zlozone jest. zdecydowanie nie rozklada sie to po rowno po procesorach. jest juz lepiej, to znaczy czasami pg przeskakuje na drugi procesor, ale 90% czasu liczy na p1. wroce do tematu
Link do wypowiedziLink
Sylwester M.

Sylwester M. --

Temat: PostgreSQL 8.2 i dziwny wielkość tabeli

Sylwester M.:
ogolne wyniki zabawy nocnej

1) system: pg 8.2, debian 64bit, 2x operony
2) baza zaladowana - 1 tabela, 4 integery, 1 real, 1 char (11), ilosc rekordow: 13012701, rozmiar: 950MB, 2 indexy na integery, indeksy maja po 279MB :D

3) test. select ilosci rekordow, podzielilem przez 3 (no tak sobie wybralem),sprawdzilem min i max wartosc klucza glownego, i kazalem skryptowi wykonoac update jednego pola N razy. gdzie N jest 1/3 ilosci rekorodow. czyli mowiac lopotoligocznie

skryp zrobil iles tam updatow == 1/3 ilosci rekordow w tabeli. przy kazdym updacie losowal ktory rekord updatowac - losowo. robil po kazej operacji commita. skrypt wykonal 4337566 updatow. ale zeby jeszcze skomplikowac odpalilem 2 procesy z tymi skryptami - zeby byly jakies locki i inne

efekt ciekawy:
wartosc zmienilo 2527802 rekordow. to dziwne, bo 2 procesy, kazdy po 4337566 updatow - czyli 8675132 updatow w sumie (skutecznosc upodatowania - 29.14% :)). nie miej wartosc zmienilo 19.43% danych w calej tabeli

rozmiar tabeli po operacji: 1156MB
rozmiar indexow: ten po ktorym bylo wyszukiwanie: 557MB, drugi index: 475MB

czyli: baza wzrosla o 21.68%
indexy: w sumie o 94.95%

nie jest tak zle wg mnie. puszcze te skrypty jeszcze raz. niech sobie pracuja.

posumowywujac chyba faktycznie cos jest nie tak z indexami. puchna. pochodzi jeszcze 5 takich skryptow przez dzsiejszy dzien i zobaczmy jaka bedzie zmiana


reszta testu. różnica taka, ze pracujemy dalej na tej samej bazie, ten sam skrypt, ale teraz chodzi 5 procesów + 1 zdalny (zrobił dużo mniej updatów)

efekt:
wykonano: 5x4337566 updatów -> 21687830 :) + ze zdalnego komputera: 644120
rekordów, które zmieniły wartość: 7054537 (54,21% tabeli)
baza (tabela) ma teraz: 1167MB
index: 1034MB

było poprzednio:
baza (tabela): 1156MB
index: 1032MB

początkowo:
baza (tabela): 950MB
indexy: 558MB

czyli niewiele sie zmieniło od poprzedniego testu. sytuacja stabilna

'chłopaki się bawią' :)

p.s.
po wykonaniu
21687830 + 8675132 -> 30362962 updatów, jest zmienione 7054537 rekordów z 13012701 sztuk. to jest 54,21% tabeli. to ile trzeba zrobić updatów, żeby zrobić powiedzmy 90% updatów w tabeli ? krzywa Gaussa/Studenta ?
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj