Bardzo duże obciążenie bazy danych

[Thunder1000]

Witam,

Posiadam swoją joomlę na serwerach kei.pl

Otrzymałem ostatnio małe ostrzeżenie:

Nasze mechanizmy monitorujące wykorzystanie parametrów serwera wykazują, że Państwa serwisy/bazy danych na usłudze Dedykowany serwer MySQL: mysql.secpress.kei.pl generują 185,45% obciążenia dysku (IO) serwera referencyjnego.

Zgodnie z posiadaną przez Państwa opcją serwera obciążenie dysku (IO) powinno wynosić maksymalnie 5,00%

185% to bardzo dużo...

Poprosiłem o zbadanie sprawy i w odpowiedzi dostałem taki o to plik w załączniku.

Powiem szczerze że mało z tego rozmumiem choć z joomlą ju jestem ponad 3 lata (wiem mało, ale zwasze coś) :)

Czy jesteście wstanie podpowiedzieć w jakim kierunku mam iść w optymalizacji bazy mysql

Szukałem w necie pod hasłem "optymalizacja bazy danych joomla" ale to daje mi bardzo dużo ogołników.

- - - Updated - - -

Byłbym zapomniał... chodzi o serwis www.portal-ochrony.pl

[Gall Anonim]

Trudno powiedzieć na wyczucie co jest przyczyną na czują - na początek w robots.txt zablokowałbym wszystkie roboty po za googlebot
Spróbuj również zainstlować sobie jakieś rozszerzenie które blokuje ataki DoS
- a a potem za dzień, dwa zerknij na statystyki serwera.
Zresztą zastanów się co ostatnio instalowałeś lub uruchomiłeś.
czasami chociażby chat daje taki efekt.
Pzdr

[Jola]

Witam,
załącznik wskazuje na trzy zapytania do bazy delikatnie mówiąc kosmicznie rozbudowane.
Można testowo odpalić je w phpMyAdmin i zobaczyć statystyki.
Nie wiem które z rozszerzeń je generuje.
Rozwiązanie - odnaleźć winowajcę i
- wyłączyć (odinstalować)
- zastąpić innym rozszerzeniem
- poprawić kosmiczne zapytania

[Thunder1000]

Dostałem malą wskazówkę od administratora serwera mainowicie:



Jednym z głównych problemów jest to że zastosowana konstrukcja zapytań uniemożliwia korzystanie z indeksów i wymaga tworzenie tabel tymczasowych które są zapisywane na dysku.

[Thunder1000]

Mam jeszcze jedno pytanie z inne beczki ale w tym samym temacie...

Czy w tym przypadku zmiana opcji w Kei.pl z LunaII 10%/60gb na serwer dedykowany np na SERWER L2 1and1
Procesor AMD Dual-Core Prędkość 2 rdzenie x 2,2 GHz Pamięć RAM 2 GB DDR2 Dyski twarde 250 GB
(2 x 250 SATA)

coś mi pomorze?

Ogólnie portal nie jest taki poteżny bo to tylko na dzień dzisiejszy 15 000 UU i około 80 000 wyświetleń

[zeki]

na kei masz VPS czy to hosting współdzielony? Bo jakoś ta e-platforma mi nic nie mówi...

Co d 1and1 to zapodałeś dedyka więc tam ich obciążenie maszyny nie interesuje. Po prostu masz swój serwer i co na nim robisz to Twoja sprawa. Tak samo będziesz miał w kei i każdej formie jeśli weźmiesz dedyka. To twoja maszyna i tylko Ty z niej korzystać będziesz więc limit 5% proca czy czegoś takiej usługi nie dotyczy.

[Jola]

Panowie - czy dla trzech źle napisanych zapytań trzeba zmieniać usługę na serwerze? To dosyć zabawne.

[Thunder1000]

Panowie - czy dla trzech źle napisanych zapytań trzeba zmieniać usługę na serwerze? To dosyć zabawne.

Zapewne nie... tylko zupełnie nie wiem gdzie mam się zaczepić żeby te zapytania zmienić lub jaką grogą iść :)

[Korek1]

A może najprostszą czyli pomalutku, powolusku wyłączać dodatki. Kiedys byl identyczny problem na witrynie posiadającej 100 UU dziennie. Prawdopodobnie byl to jeden z dodatkow, rozszerzeń nie wiem dokladnie a chodzilo o akeebe.

Wysyłane z mojego GT-I9300 za pomocą Tapatalk 2

[Gall Anonim]

@Korek1 - kiepska teoria - bo biorąc pod uwagę ilość stron stojących na moim hostingu i to że każda ma Akeeba'ę to nie ma prawa on hulać.
Pzdr

[Jola]

Witam,
niestety mam chyba złą wiadomość - taki kod generuje sam Joomla w komponencie com_content (mowa tu o wersji 2.5).
Toteż zmiana (optymalizacja zapytania jest możliwa ale zniknie przy pierwszej lepszej aktualizacji)
Trzeba przeanalizować zachowanie, obciążenie baz danych na innych instalacjach Joomla 2.5
Co z tego wyniknie - zobaczymy.
Co zrobić mimo wszystko - włącz cachowanie strony lub zainstaluj i uruchom jakies rozszerzenie do cachowania

[sylwekb]

Podłączam się do wątku. W dniu dzisiejszym dostawca hostingu zresztą także kei.pl zwrócił mi uwagę na wysycenie mysqla na poziomie 85%, do tej pory miałem około 15%. Ich zdaniem poniższe polecenia wygenerowały ten straszny skok. Czy ktoś ma jakiś pomysł? Dotychczas nie miałem takich problemów.


SELECT a.id, a.title, a.alias, a.title_alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, CASE WHEN a.modified = 0 THEN a.created EL SE a.modified END as modified, a.modified_by, uam.name as modified_by_name,CASE WHEN a.publish_up = 0 THEN a.created ELSE a.publish_up END as publish_up,a.publish_down, a.images, a.urls, a.a ttribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, LENGTH(a.fulltext) AS readmore,CASE WHEN badcats.id is not null THEN 0 ELSE a.state END AS state,c.title AS category_title, c.path AS category_route, c.access AS category_access, c.alias AS category_alias,CASE WHEN a.created_by_alias > ' ' THEN a.created_by_alias ELSE ua.name END AS author,ua email AS author_email,contact.id as contactid,parent.title as parent_title, parent.id as parent_id, parent.path as parent_route, parent.alias as parent_alias,ROUND(v.rating_sum / v.rating_c ount, 0) AS rating, v.rating_count as rating_count,c.published, CASE WHEN badcats.id is null THEN c.published ELSE 0 END AS parents_published FROM j25_content AS a LEFT JOIN j25_content_frontpage AS fp ON fp.content_id = a.id LEFT JOIN j25_categories AS c ON c.id = a.catid LEFT JOIN j25_users AS ua ON ua.id = a.created_by LEFT JOIN j25_users AS uam ON uam.id = a.modified_by LEFT JOIN ( SELECT contact.user_id, MAX(contact.id) AS id, contact.language FROM j25_contact_details AS contact WHERE contact.published = 1 GROUP BY contact.user_id, contact.language) AS contact ON contact.user_id = a.created_by LEFT JOIN j25_categories as parent ON parent.id = c.parent_id LEFT JOIN j25_content_rating AS v ON a.id = v.content_id LEFT OUTER JOIN (SELECT cat.id as id FROM j25_categories AS cat JOIN j25_categories AS parent ON cat.lft BETWEEN parent.lft AND parent.rgt WHERE parent.extension = 'com_content' AND parent.p ublished != 1 GROUP BY cat.id ) AS badcats ON badcats.id = c.id WHERE a.access IN (1,1) AND c.access IN (1,1) AND CASE WHEN badcats.id is null THEN a.state ELSE 0 END = 1 AND (a.publish_up = '0000-00-00 00:00:00' OR a.publish_up <= '2013-04-21 23:05:12') AND (a.publish_down = '0000-00-00 00:00:00' OR a.publish_down >= '2013-04-21
23:05:12')
GROUP BY a.id, a.title, a.alias, a.title_alias, a.introtext, a.checked_out, a.checked_out_time, a.catid, a.created, a.created_by, a.created_by_alias, a.created, a.modified, a.modified_by, ua m.name, a.publish_up, a.attribs, a.metadata, a.metakey, a.metadesc, a.access, a.hits, a.xreference, a.featured, a.fulltext, a.state, a.publish_down, badcats.id, c.title, c.path, c.access, c.
alias, uam.id, ua.name, ua.email, contact.id, parent.title, parent.id, parent.path, parent.alias, v.rating_sum, v.rating_count, c.published, c.lft, a.ordering, parent.lft, fp.ordering, c.id, a.images, a.urls
ORDER BY fp.ordering, a.created LIMIT 0, 25G