Temat: Optymalizacja bazy danych kroko po kroku
Ostatnio edytowany przez zbytnik (2009-03-17 16:37:07)
Odp: Optymalizacja bazy danych kroko po kroku
Co znaczy schody? Baza muli. Nie wyrabiają select'y, inserty, update'y ? Jak dużo połączeń z baza jest nawiązywanych?
Odp: Optymalizacja bazy danych kroko po kroku
NO dobra od początku:
Czasy zaczynają wzrastać wraz z ilością użytkowników. Najpierw było 0,9 s(grało się płynnie) potem stopniowo wzrastało do wartości 10 s (muł totalny).
Przez ten czas dopisałem trochę kodu (około 25%) i doszło trochę grafiki. Sprawdziłem, strona bez bazy robi na poziomi 0,6 - 0,7 sek z bazą już 9,0 - 10,0 czyli wniosek: baza danych gdzieś coś przycina.
Znalazłem jedno miejsce odpowiedzialne za około 0,7 - 0,8 s jest to zapytanie proste typu:
SELECT sum(waga) FROM muarab_broniereczne WHERE id_muarab_ekwipunek=1 AND a='A';
Takich zapytań jest około 10 sztuk i tutaj muli na poziomie około 4 sekund
Parametr a to znaczy że przedmiot ma być zliczony do wagi
A tutaj wynik explaina:
!!!!=# explain SELECT sum(waga) FROM muarab_broniereczne WHERE id_muarab_ekwipunek=1 AND a='A';
QUERY PLAN
-----------------------------------------------------------------------------------------------------
Aggregate (cost=18.29..18.30 rows=1 width=4)
-> Bitmap Heap Scan on muarab_broniereczne (cost=14.27..18.28 rows=1 width=4)
Recheck Cond: ((id_muarab_ekwipunek = 1) AND (a = 'A'::text))
-> BitmapAnd (cost=14.27..14.27 rows=1 width=0)
-> Bitmap Index Scan on index_id_muarab_ekwipunek (cost=0.00..2.15 rows=42 width=0)
Index Cond: (id_muarab_ekwipunek = 1)
-> Bitmap Index Scan on index_a (cost=0.00..11.88 rows=1679 width=0)
Index Cond: (a = 'A'::text)
(8 rows)
Odp: Optymalizacja bazy danych kroko po kroku
Config bazy masz jakis ? ;]
shared_buffers = ?
effective_cache_size = ?
Jaka maszyna ... dajesz wszystko co masz 
Pozdrawiam
Pawel Socha
Pawel Socha
Odp: Optymalizacja bazy danych kroko po kroku
Podaj jakie masz indeksy założone dla tej bazy?
Odp: Optymalizacja bazy danych kroko po kroku
Indexy (na przykład):
"muarab_przedmiot_a_id_ekwipunek" btree (id_muarab_ekwipunek, a) <- podobnych undexów jest z 10 sztuk narazie ale docelowo będzie około 18
Bo jest tego dużo, w tym stylu. Odkąd je pozakładałem nie było żadnych indexów. Ucze się dopiero je stawiać.
Odkąd je pododawałem to sporo mi przyspieszył system, na szczęści trafiłem na kogoś kto to potrafił mi wytłumaczyć przy piwku. 
Konfig sprzętu:
shared_buffers=50000 (ustawiał mi admin na 50k było chyba jakoś innaczej)
effective_cache_size = 1000 (do tej pory było zahaszowane ale od haszowałem)
maszyna : cantos 5.0
Procesor dwurdzeniowy, 1GB pamięci RAM i dyskami w Raid 0 + 1
Już pozindeksowaniu (przedzindexowaniem jest gdzieś powyżej):
!!!=# explain SELECT sum(waga) FROM muarab_broniereczne WHERE id_muarab_ekwipunek=1 AND a='A';
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
Aggregate (cost=7.03..7.04 rows=1 width=4)
-> Index Scan using muarab_broniereczne_a_id_ekwipunek on muarab_broniereczne (cost=0.00..7.03 rows=2 width=4)
Index Cond: ((id_muarab_ekwipunek = 1) AND (a = 'A'::text))
(3 rows)
Może ktoś ma pomysła jak więcej wycisnąc sekund z takiego zapytania 
Ostatnio edytowany przez zbytnik (2009-03-19 15:58:30)