Ogólne - HOME.pl i jego walka z wydajnosci? serwerów...
mopek - 16-11-2006, 18:00
Przemo napisał/a: | Tak więc prawdopodobnie uda nam sie pozytywnie to rozwiązać. |
no też byłem bliski zawału - teraz ujrzałem światełko w tunelu
w załączeniu TXT - mam nadzieje, ze sie przyda
montee - 16-11-2006, 18:39
Ok, wklejam co jest u mnie:
Tabela: phpbb_users
Kod: |
PRIMARY PRIMARY 4360 Edytuj Usuń user_id
user_session_time INDEX 4360 Edytuj Usuń user_session_time
user_level INDEX 3 Edytuj Usuń user_level
user_lastvisit INDEX 4360 Edytuj Usuń user_lastvisit
user_active INDEX 2 Edytuj Usuń user_active
|
Tabela: phpbb_read_history
Kod: |
user_id INDEX 240 Edytuj Usuń user_id
post_id INDEX 6893 Edytuj Usuń post_id
topic_id INDEX 2757 Edytuj Usuń topic_id
forum_id INDEX 250 Edytuj Usuń forum_id
|
marekpow - 16-11-2006, 20:02
merowing napisał/a: | Przemo napisał/a: | Każdy kto w mailu dostał: |
Ja miałem taką informację,
Kod: | SELECT u.user_id FROM (forumusers u, forumread_history r) WHERE u.user_id = r.user_id AND u.user_lastvisit ... |
jednak we wszystkim wskazanych przez Ciebie Przemo przypadkach, posiadam klucze (indexy). |
Czy można prosić o całego SELECT'a? Wygląda mi na to, że jest napisany mało efektywnie.
Przeszukałem cały kod forum i nie znalazłem takiego SELECT'a.
Przemo - 17-11-2006, 09:14
Kod: | SELECT u.user_id FROM (phpbb_users u, phpbb_read_history r) WHERE u.user_id = r.user_id AND u.user_lastvisit < 1161856810 AND u.user_id <> -1 AND u.user_level = 0 AND u.user_id <> 1292 GROUP by r.user_id | To zapytanie pobiera uzytkownikow dawno niezalogowanych z wyjatkiem admina, moda i usera ktory aktualnie jest na forum aby usunac im wpisy o nieczytanych postach. Ma to na celu zapobiegniecie przepelnieniu tabeli read_history
student - 17-11-2006, 10:49
Przemo napisał/a: | student (i inni), sprawdż, czy w tabeli phpbb_users i w widoku struktury tabeli sprawdź czy napewno na dole masz klucze (indexy) na polach: user_id, user_level, user_lastvisit
oraz dla tabeli read_history na polu: user_id |
Przemo, w tabela users wygląda u mnie tak:
Kod: | Indeksy:
Nazwa klucza Typ Moc Działanie Pole
PRIMARY PRIMARY 1817 Edytuj Usuń user_id
user_session_time INDEX 1817 Edytuj Usuń user_session_time
user_level INDEX 3 Edytuj Usuń user_level
user_lastvisit INDEX 1817 Edytuj Usuń user_lastvisit
user_active INDEX 2 Edytuj Usuń user_active |
A tabela read_history:
Kod: | Nazwa klucza Typ Moc Działanie Pole
user_id INDEX 168 Edytuj Usuń user_id
post_id INDEX 6534 Edytuj Usuń post_id
topic_id INDEX 347 Edytuj Usuń topic_id
forum_id INDEX 14 Edytuj Usuń forum_id |
W takim razie dobrze czy nieprawidłowo?
marekpow - 17-11-2006, 11:05
Nie rozumiem po co jest tam GROUP BY skoro nie ma żadnego sumowania ani zliczania.
Ja bym to napisał tak:
Kod: | SELECT u.user_id
FROM forumusers u
LEFT JOIN forumread_history r ON u.user_id = r.user_id
WHERE u.user_id <> -1 AND
u.user_id <> 5065 AND
u.user_lastvisit < 1159712323 AND
u.user_level = 0
|
I ustawił indeks na u.user.id, u.user_last_visit, u.user.level
Eurycide - 17-11-2006, 20:21
Witam,
Rowniez jestem poszkodowany, list od home.pl dostalem pare dni temu. Od tego czasu usunalem mody:
- cash moda
- topics ratings
- top users z nad shouta
- ranks moda
- topics_anywhere (prawdziwa masakra z tym modem...)
Wyłączyłem:
- ostatatnie zdjecia z albumu w portalu
- mozliwosc komentowania i oceniania zdjec w albumie
- linki do profili użytkowników w shoucie
- listę ostatnich użytkowników na forum
- moduł urodzin
Zmodyfikowałem:
- Z 2000 na 1000 limit nieczytanych postów
- Zmniejszyłem długość sesji
- Ograniczyłem ilość tematów w obrębie forum na jednej podstronie (z 35 do 28)
- Ograniczyłem ilość wpisów w obrębie tematu na jednej podstronie (z 15 do 10)
Po 2 dniach otrzymalem kolejny zbior logow (konkretniej dzisiaj), po czym usunalem wlasnie cash moda i topics_ratings. W chwili obecnej mam czyste phpbb by przemo 1.12 z wlasnymi modyfikacjami, ktore jednak nie maja wplywu na baze danych.
Ostatni otrzymany log zamieszczam w zalaczniku (nie obejmuje moich dzisiejszych zmian z cash modem i topics ratings).
Dodam jeszcze, że home.pl to mój najnowszy dostawca, wcześniej hostowałem serwis u mniejszych i tańszych dostawców (nie wyrabiali) i w końcu postanowiłem zdecydować się na najlepszy hosting. Nie narzekam, strona ma uptime niemalże 100%, nie ma żadnych błędnych komunikatów, wszystko działa szybko i sprawnie. Nie chcę zrywać umowy bo moje forum nigdzie indziej nie pociągnie. Dodam, że mam ponad 3K użytkowników, ponad 80K postów i całkiem sporo unikalnych wejść dziennie.
BTW: Przemo -> przesyłam małe wsparcie finansowe i liczę na rozwiązanie problemu... Nie chcę nic mówić, ale z tego co słyszałem home.pl nastawia się na mniejsze strony (typowo domowe) tak jak całkiem niedawno nazwa.pl
w jedności siła
PS: proponowalbym przykleic ten temat az do rozwiazania sprawy
Smoczek - 18-11-2006, 18:33
Mam identyczną sytuację, indeksy mam (przynajmniej wedle phpmyadmin istnieją).
W załączniku treść maila, który otrzymałem, co prawda za kilkanaście dni przenoszę się na zagraniczny serwer, ale wolałbym mimo wszystko aby umowa nie została rozwiązana, dlatego z niecierpliwością czekam na wyniki "rozmów" Przema z administracja home.pl.
Przemo - 19-11-2006, 23:35
marekpow, grupowanie jest po to, bo byly sytuacje, ze jakims cudem dublowali sie uzytkownicy.
Probowalem joinowania tabeli ale skutek byl troche gorszy. jesli jestes przekonany, ze musi pomoc to wygeneruj sobie duza tabele userow i read_history i sprawdź.
chelloPL - 20-11-2006, 22:27
Jednej rzeczy nie rozumiem. Włączyłem logowanie u siebie na serwerze wszystkich zapytań trwających dłużej niż 4s.
I jedyne co widzę, to nocny backup bazy (dokładniej jednej z tabel niezwiązanej z forum, która ma ponad 460000 rekordów) - 13s oraz tabela phpbb_search_wordmatch - 824000 rekordów - backup nocny wykonuje zapytanie przez 7s. Więc dlaczego niektóre fora tak obciążają serwery, podczas gdy inne tego obciążenia (albo przeciążenia) nie generują? Dodam, że logowanie działa od 5 dni, a dziennie forum odwiedza ponad 200 unikalnych osób i generują dzienny ruch około 1GB.
I jeszcze jedno, co uważam za chore. U mnie nie ma na serwerze uprawnień do blokowania tabel, czyli nie ma problemu iż coś tabelę zablokuje, a inne wątki nie mogą uzyskać do niej dostępu.
Widmo - 21-11-2006, 01:36
chelloPL, tez odnosze wrazenie ze home przekoloryzowal sprawe...
ja w logach mam zapytanie Kod: | SELECT * FROM phpbb_users WHERE userr_id = 'x' |
uznane za bardzo obciazajace...
student - 21-11-2006, 12:41
Przemo, czy są jakieś ustalenia z home.pl? Czy sprawa zostanie pozytywnie (dla nas) rozwiązana?
mopek - 21-11-2006, 14:51
dostałem nawet pismo pocztą tradycyjną... też jestem żywo zainteresowany informacjami w sprawie bo dali mi termin do 28.11 a wyjeżdżam jutro za granicę i wracam... 27.11 i wolałbym nie obudzić się z ręką w nocniku...
franek - 21-11-2006, 15:07
Powiem jak ja to widzę, jeszcze dwa miesiące temu przy znacznie większych obciążeniach na jednym z moich for nie działo się dosłownie nic, problem pojawił się może 2 miesiące temu, i nie ma reguły, na jednym serwerze mam co pochwila 503, a na drugim serwerze gdzie mam DOKŁADNIE takie samo forum (konfiguracja itp) ale z bazą 5 razy większą, większą oglądalnością ani razu 503 nie zauważyłem. To może być wina ich marketingu i ciągłych promocji, zapewne dokoptowali do każdego serwera po 10-20 dodatkowych kont i dlatego są problemy.
mopek - 21-11-2006, 18:29
jeszcze taki mail:
home.pl napisał/a: | Szanowni Państwo!
W nawiązaniu do pisma sprzed kilku dni, przesyłamy Państwu zaktualizowane
analizy logów MySQL Państwa serwisu z okresu ostatnich 36 godzin.
Mogą Państwo na ich podstawie określić efekty optymalizacji, jeżeli takowe
były przez Państwa wykonywane w ciągu kilku ostatnich dni.
Przypominamy że analiza dotyczy jedynie zapytań, które:
- nie używają indeksów (serwer każdorazowo analizuje wszystkie dane w tabeli,
wczytując nadmiarowo wiele rekordów, co znacząco obciąża serwery) lub
- wykonują się ponad 3 sekundy (znacznie spowalniając i blokując
Państwa serwis).
Informacje te prosimy wykorzystać do dalszego zoptymalizowania zapytań w
używanych aplikacjach oraz założenia brakujących indeksów w tabelach MySQL.
Korzystając z panelu phpMyAdmin (http://domena.pl/sql/, login/hasło jak do
bazy MySQL) i polecenia EXPLAIN mogą Państwo zbadać poziom optymalizacji
(sposób wykonania, użyte indeksy) każdego zapytania z osobna. Dokładną
dokumentację dotyczącą w/w zagadnień mogą Państwo uzyskać pod adresem:
http://dev.mysql.com/doc/...uery-speed.html
Jeżeli korzystają Państwo z gotowych aplikacji, proponujemy kontakt z
autorem/producentem, z prośbą o bardziej zoptymalizowaną wersję oraz
informacje na temat dodatkowych indeksów w bazie MySQL, które zwiększą
wydajność danej aplikacji. Optymalizacje takie zawarte są często już w
najnowszych wersjach aplikacji - wystarczy je zaktualizować
(aktualizując także strukturę baz SQL).
Przypominamy że wymienione w załączniku zapytania są powodem powolnego
działania serwisu oraz komunikatów "503 Virtual Server overloaded -
high load (or servicing) in progress". |
i do tego logi
|
|
|