ďťż
 
[PostgreSQL] Replikacja na 8 =?ISO-8859-2?Q?serwer=F3w?= ďťż
 
[PostgreSQL] Replikacja na 8 =?ISO-8859-2?Q?serwer=F3w?=
Zobacz wiadomości
 
Cytat
A gdyby tak się wedrzeć na umysłów górę, / Gdyby stanąć na ludzkich myśli piramidzie, / I przebić czołem przesądów chmurę, / I być najwyższą myślą wcieloną. . . Juliusz Słowacki, Kordian
Indeks BCB i MySQL subiekt gt fototapeta
 
  Witamy

[PostgreSQL] Replikacja na 8 =?ISO-8859-2?Q?serwer=F3w?=



Krzych K2 - 16-01-2007 00:01
[PostgreSQL] Replikacja na 8 =?ISO-8859-2?Q?serwer=F3w?=
  Witam

Mam pytanie - czy zna ktoś z szanownego grona dobry projekt replikacji dla
postgre ew, jak ztuningować slony1.

Mam centralną bazę o wielkości ok 100MB i replikuję ją na 8 maszyn, aby
ograniczyć ilość zapytań i obciążenie centralnej bazy. Używam do tego
Slony1, który jest szybki i bardzo szybko rozsyła modyfikacje z bazy matki
na dzieci. Ale pojawił się problem w postaci tego iż po dłuższej pracy,
procesy połączeniowe dzieci do postgre na centralnym serwerze osiągają 100%
czasu procesora i serwer strasznie muli.

Wszystkie tabele przeindeksowałem dla świętego spokoju, porobiłem porządki
ale nadal problem występuje. Wygląda to tak, jakby im dłużej był podłączony
klient do centralnej bazy, tym bardziej zajmuje procka, mimo iż informacje
nie przepływają, a zapytań jest niewiele, gdyż replikacja idzie tylko z
matki na dzieci (triggery) a w drugą stronę już nie.
--
Pozdro
KrzychK2





hubert depesz lubaczewski - 17-01-2007 00:05

  On 2007-01-15, Krzych K2 <krzysztof.kardas@wp.pl> wrote:
> Mam centralną bazę o wielkości ok 100MB i replikuję ją na 8 maszyn, aby
> ograniczyć ilość zapytań i obciążenie centralnej bazy. Używam do tego
> Slony1, który jest szybki i bardzo szybko rozsyła modyfikacje z bazy matki
> na dzieci. Ale pojawił się problem w postaci tego iż po dłuższej pracy,
> procesy połączeniowe dzieci do postgre na centralnym serwerze osiągają 100%
> czasu procesora i serwer strasznie muli.

1. który slony?
2. który postgres?
3. czy dodawałeś jakieś node'y do replikacji które potem usuwałeś?
4. czy może w replikacji jest wpisane więcej node'ów niż faktycznie?
5. co pokazuje:
select * from _slony.sl_status;
gdzie zamiast _slony wstaw nazwę schemy replikacyjnej u ciebie.

depesz

--
http://www.depesz.com/ - blog dla ciebie




Krzych K2 - 17-01-2007 00:05

  hubert depesz lubaczewski napisał(a):

> On 2007-01-15, Krzych K2 <krzysztof.kardas@wp.pl> wrote:
>> Mam centralną bazę o wielkości ok 100MB i replikuję ją na 8 maszyn, aby
>> ograniczyć ilość zapytań i obciążenie centralnej bazy. Używam do tego
>> Slony1, który jest szybki i bardzo szybko rozsyła modyfikacje z bazy
>> matki na dzieci. Ale pojawił się problem w postaci tego iż po dłuższej
>> pracy, procesy połączeniowe dzieci do postgre na centralnym serwerze
>> osiągają 100% czasu procesora i serwer strasznie muli.
>
> 1. który slony?

slon 1.1.5

> 2. który postgres?

PostgreSQL 8.0.8

> 3. czy dodawałeś jakieś node'y do replikacji które potem usuwałeś?

Tak, ale zazwyczaj wywalałem wtedy cały schemat i VACCUM FULL szedł.

> 4. czy może w replikacji jest wpisane więcej node'ów niż faktycznie?

Nie.

> 5. co pokazuje:
> select * from _slony.sl_status;
Pokazuje nody na które idzie replikacja. jest ich tyle ile trzeba, czas
połączenia, id i inne przydatne rzeczy.

> gdzie zamiast _slony wstaw nazwę schemy replikacyjnej u ciebie.
>
> depesz
>

--
Pozdro
KrzychK2




hubert depesz lubaczewski - 17-01-2007 00:05

  On 2007-01-16, Krzych K2 <krzysztof.kardas@wp.pl> wrote:
>> 1. który slony?
> slon 1.1.5

zaktualizuj. niekoniecznie do 1.2, ale przynajmniej 1.1.6

>> 3. czy dodawałeś jakieś node'y do replikacji które potem usuwałeś?
> Tak, ale zazwyczaj wywalałem wtedy cały schemat i VACCUM FULL szedł.

co znaczy "wywalałem cały schemat"? kasowałeś replikację? i odtwarzałeś?
a ten vacuum full to po co?

>> 5. co pokazuje:
>> select * from _slony.sl_status;
> Pokazuje nody na które idzie replikacja. jest ich tyle ile trzeba, czas
> połączenia, id i inne przydatne rzeczy.

dzięki. wiem jakie tam są kolumny. prosiłem byś pokazał wynik. chyba, że
jest tajny.

pokaż też:
select count(*) from _slony.sl_log_1;
select count(*) from _slony.sl_log_2;

depesz

--
http://www.depesz.com/ - blog dla ciebie





baklarz - 18-01-2007 00:01

  Dnia 15.01.2007 Krzych K2 <krzysztof.kardas@wp.pl> napisał/a:
> Witam
>
> Mam pytanie - czy zna ktoś z szanownego grona dobry projekt replikacji dla
> postgre ew, jak ztuningować slony1.
>
> Mam centralną bazę o wielkości ok 100MB i replikuję ją na 8 maszyn, aby

Po pierwsze baze centralną postawiłbym w ramie.
http://www.linuxfocus.org/English/No...rticle125.html
Po drugie ograniczyłbym liczbę maszyn.
Jak wygląda stosunek dml do select ?

--
Tomasz Drobiszewski




Krzych K2 - 18-01-2007 00:01

  baklarz napisał(a):

> Dnia 15.01.2007 Krzych K2 <krzysztof.kardas@wp.pl> napisał/a:
>> Witam
>>
>> Mam pytanie - czy zna ktoś z szanownego grona dobry projekt replikacji
>> dla postgre ew, jak ztuningować slony1.
>>
>> Mam centralną bazę o wielkości ok 100MB i replikuję ją na 8 maszyn, aby
>
> Po pierwsze baze centralną postawiłbym w ramie.

Fakt, ale tam jest dosyć szybki dysk i jak robiłem pg_bench to dyszczydło
sie powodowało wąskiego gardła.

> http://www.linuxfocus.org/English/No...rticle125.html
> Po drugie ograniczyłbym liczbę maszyn.

Nie ma takiej możliwości. Wtedy zwiększam ilość zapytań do bazy centralnej i
wracamy do punktu wyjścia. Poza tym zaczyna spadać niezawodność bo jak
centralna baza klęknie to klienci nadal korzystają z replikacji i działamy
dalej.

> Jak wygląda stosunek dml do select ?
>

Hm. nie wiem, musiałbym to zmierzyć.

--
Pozdro
KrzychK2




Krzych K2 - 18-01-2007 00:01

  hubert depesz lubaczewski napisał(a):

> On 2007-01-16, Krzych K2 <krzysztof.kardas@wp.pl> wrote:
>>> 1. który slony?
>> slon 1.1.5
>
> zaktualizuj. niekoniecznie do 1.2, ale przynajmniej 1.1.6
Okij. Postaram się to zrobić w najbliższym czasie.

>
>>> 3. czy dodawałeś jakieś node'y do replikacji które potem usuwałeś?
>> Tak, ale zazwyczaj wywalałem wtedy cały schemat i VACCUM FULL szedł.
>
> co znaczy "wywalałem cały schemat"? kasowałeś replikację? i odtwarzałeś?
> a ten vacuum full to po co?

Gdzieś czytałem że vacuma warto robić po głębszej ingerencji. Wtedy byłem
trochę za ciemny w temacie i były to takie testy na systemie testowym,
łącznie z tym jak szybko można odtworzyć replikację. Teraz jak wrzuciłem
na produkcję, wyszedł taki problem z wydajnością. grr.

>
>>> 5. co pokazuje:
>>> select * from _slony.sl_status;
>> Pokazuje nody na które idzie replikacja. jest ich tyle ile trzeba, czas
>> połączenia, id i inne przydatne rzeczy.
>
> dzięki. wiem jakie tam są kolumny. prosiłem byś pokazał wynik. chyba, że
> jest tajny.
>
> pokaż też:
> select count(*) from _slony.sl_log_1;
> select count(*) from _slony.sl_log_2;
>
> depesz
>

No to już się chwalę. Wierszy specjalnie nie zawijam, aby się łatwiej czytało.

# select * from _slony.sl_status;

st_origin | st_received | st_last_event | st_last_event_ts | st_last_received | st_last_received_ts | st_last_received_event_ts | st_lag_num_events | st_lag_time
-----------+-------------+---------------+---------------------------+------------------+----------------------------+---------------------------+-------------------+-----------------
1 | 2 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:49:22.622635 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
1 | 3 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:49:18.601663 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
1 | 6 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:47:36.820723 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
1 | 7 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:46:47.643096 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
1 | 4 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:45:03.300361 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
1 | 5 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:52:03.944611 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
1 | 8 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:49:02.898028 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
(7 rows)
# select count(*) from _slony.sl_log_1;
count
-------
68253
(1 row)
# select count(*) from _slony.sl_log_2;
count
-------
0
(1 row)

--
Pozdro
KrzychK2




hubert depesz lubaczewski - 18-01-2007 00:01

  On 2007-01-17, Krzych K2 <krzysztof.kardas@wp.pl> wrote:
> No to już się chwalę. Wierszy specjalnie nie zawijam, aby się łatwiej czytało.
> # select * from _slony.sl_status;
> st_origin | st_received | st_last_event | st_last_event_ts | st_last_received | st_last_received_ts | st_last_received_event_ts | st_lag_num_events | st_lag_time
> -----------+-------------+---------------+---------------------------+------------------+----------------------------+---------------------------+-------------------+-----------------
> 1 | 2 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:49:22.622635 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
> 1 | 3 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:49:18.601663 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
> 1 | 6 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:47:36.820723 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
> 1 | 7 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:46:47.643096 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
> 1 | 4 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:45:03.300361 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
> 1 | 5 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:52:03.944611 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
> 1 | 8 | 10037 | 2007-01-17 19:48:15.11889 | 10037 | 2007-01-17 19:49:02.898028 | 2007-01-17 19:48:15.11889 | 0 | 00:00:08.921996
> (7 rows)
> # select count(*) from _slony.sl_log_1;
> count
> -------
> 68253
> (1 row)

tu trochę dużo.
zobacz czy na którymś z node'ów nie masz zbędnych wpisów w
_slony.sl_node;

depesz

--
http://www.depesz.com/ - blog dla ciebie




Krzych K2 - 24-01-2007 00:02

  hubert depesz lubaczewski napisał(a):

<ciach>
Już sobie poradziłem. Trochę przebudowałem schemat replikacji i teraz hula
aż miło.

--
Pozdro
KrzychK2
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • effulla.pev.pl
  • comp
    Wydajność baz danych w zależności od poziomu izolacji ANSI/ISO Czy zna (obsługuje) ktoś program Iso Draw ? MYSQL - kodowanie w ISO-PL strona plus baza w iso do utf-8 Kodowanie: z iso na utf postgresql - int/int postgresql Select count(*) czy raczej Select count(ID) Dopasowanie do "najlepszego" dopasowania :) [ PostgreSQL] Wstawianie nowego wiersza w przypadku jego braku podczas SELECT w PostgreSQL Konwesja znaków w dump'ie bazy danych - ISO -> utf-8 -> ISO -> utf-8
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • morebeer.opx.pl
  • Cytat

    Decede mihi sole - nie zasłaniaj mi słonca.
    Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
    Hoc fac - tak czyń.
    A tergo - od tyłu; z tyłu.
    I czarne włosy posiwieją. Safona

    Valid HTML 4.01 Transitional

    Free website template provided by freeweblooks.com