Temat: PostreSQL - problem z indexami
Przy takich przyrostach - trzeba poczekać... Za jakiś czas sytuacja powinna się ustabilizować.
Co do checkpointów... W ten sposób baza oznacza, że dane zostały przeniesione z ramu na dysk, i są bezpieczne. To jest istotne na wypadek padu systemu. Im dalej checkpoint tym więcej trzeba odtwarzać z logów. Da wcześniejszych wersji PG, była to operacja mocno obciążająca system, teraz jest lżej. Baza i tak smaruje do logów, zawsze, pytanie tylko na ile dane w buforach systemowych zostały zrzucone na dysk. Czyli dalej nie ma co robić tego za często. Domyślną wartość 5 minut, można spokojnie podnieść do 10 minut. Tak samo bezpieczna wartość... O ile oczywiście np. jest miejsce na dysku. Podbicie ilości segmentów do 16 oznacza, że będzie max. 16 plików po 16MB każdy. Ten warning w logach domyślnie pojawia się, jeżeli baza robi checka częściej jak co 30 sekund. Uwzględniając przyrost bazy, pewnie teraz robi co 35 sekund... Ja bym podbił timeout i ilość segmentów tak, żeby razem wypadało, coś koło 10 minut - w szczycie.
Ja tam nie wiem, ale latanie na forum z każdym, kolejnym problemem, to słaby pomysł. Lepiej to komuś zlecić. Za dwa miesiące dych będzie tyle, że każdy ruch zajmie pół dnia. Lepiej jak ktoś poświęci dzień pracy dziś, a potem kolejny - co miesiąc. Niż zabawa zacznie się za te 2 miesiące do 2 tygodni pracy... W zasadzie za pół roku efekt będzie ten sam, no z dokładnością do budżetu. :)
Pytania pomocnicze:
Jaka to konkretnie wersja bazy danych?
Czy ruch jest taki sam przez całą dobę?
Jaki jest stosunek poszczególnych operacji - w czasie?
Jaka replikacja jest stosowana i jak zachowuje się przy takim obciążeniu?
пропозиції роботи
