Szolgáltatótól ezt az e-mailt kaptuk! És nem tudjuk a hibát megoldani!
Tudnátok segíteni?
Kedves Bálint!
Oldalad kritikusan sok MySql lekérdezést futtat, annak ellenére, hogy oldalad látogatószáma relatív alacsony.
Látogatók száma naponta: 8
A tegnapi napon futtatott lekérdezések száma: 2.555.573
Az összes lekérdezéshez képest a szerveren: 13.52%
A statisztikából látszik, hogy oldalad annyi adatbázis műveletet végez, mint több száz másik oldal, így igen nagy terhelést generál.
Kérlek javítsd az oldalad hatékonyságát!
Megoldás lehet az oldal optimalizálása, vagy cache használata. Ha valamilyen publikus rendszert használsz (például Joomla, WordPress, Drupal, Prestashop) akkor a cache egyszerűen telepíthető plugin-ként is. Ha kérdésed van, segítünk a megválaszolásában!
Üdvözlettel,
*
*
*
______________________________________________________________________ 005 ___
Count : 333.01k (1.76%)
Connection ID : 1041152
Database : ragnarok_****
Users :
******@localhost : 100.00% (333007) of query, 13.52% (2555573) of all users
Query abstract:
SELECT cid, data, created, expire, serialized FROM drupal_7_cache_bootstrap WHERE cid IN (S1)
Query sample:
SELECT cid, data, created, expire, serialized FROM DRUPAL_7_cache_bootstrap WHERE cid IN ('variables')
______________________________________________________________________ 008 ___
Count : 231.87k (1.23%)
Connection ID : 1044659
Database : ragnarok_****
Users :
******@localhost : 100.00% (231868) of query, 13.52% (2555573) of all users
Query abstract:
SELECT cid, data, created, expire, serialized FROM drupal_7_cache_field WHERE cid IN (S1)
Query sample:
SELECT cid, data, created, expire, serialized FROM DRUPAL_7_cache_field WHERE cid IN ('field_info_fields')
______________________________________________________________________ 010 ___
Count : 202.79k (1.07%)
Connection ID : 1041152
Database : ragnarok_****
Users :
******@localhost : 100.00% (202794) of query, 13.52% (2555573) of all users
Query abstract:
SELECT cid, data, created, expire, serialized FROM drupal_7_cache WHERE cid IN (S1)
Query sample:
SELECT cid, data, created, expire, serialized FROM DRUPAL_7_cache WHERE cid IN ('locale:hu')
Na erre én is kíváncsi vagyok
Na erre én is kíváncsi vagyok, mit fognak mondani a többiek, mert nem is olyan rég beszélgettünk egy másik topicban a Drupal fordításainak cache-eléséről, és arról írtam épp, hogy szerintem nagyon durván pazarló...
Mondjuk hogy nálad vajon miért fut le ennyire durván sokszor, azt tényleg nem értem. Valamelyik modul mintha valamit rosszul csinálna, ha ennyire nem indokolja a dolgot az alacsony látogatottság...
Én elkezdenék nyomozni a helyedben localhoston. Letölteném az egészet, felraknám helyi webszerverre, aztán mehet minden fel, ami kell hozzá.
((((((( OFF
Én Drupal Answers-ön korábban feltettem memóriazabával kapcsolatos kérdést, hogy mivel lehet tesztelni:
http://drupal.stackexchange.com/questions/48698/method-to-test-which-mod...
Azóta utánanéztem, és a Field group kegyetlen undorítóan van megírva (elég nagy csalódást okozott számomra, amikor láttam az adatbázis-szerkezetet, amit feltölt), lehet, hogy a fejlesztőjük nem hallott még az adatbázis-normalizációról, vagy nem vágom, miért művelt oly érdekes dolgokat, hogy például pipe-olva, stringként felnyomta az összes mezőt, aztán az extra mezőben meg serializálva, aztán jó lesz az... nem csoda, hogy csak úgy zabálja a memóriát.
XHProf kiterjesztést érdemes lehet feltenni:
http://pecl.php.net/package/xhprof
Aztán még amit itt ajánlanak:
http://drupal.stackexchange.com/questions/2802/getting-per-module-memory...
/OFF )))))))
Szerk.:
Bocs, a fentiek memóriazabálásra vonatkoznak, véletlenül hirtelen eltereltem a témát.
MySQL-profilozásra lenne szükség, szintén localhoston.
Ajánlott:
A szolgáltató arra hivatkozik, hogy cache-elést kellene használnod, de az a gáz, hogy a query-k épp a cache-táblákból kérdeznek le. :(
Mindenképp valami profilozó eszközzel tesztelgess (adatbázis, PHP...). De sanszos, hogy ugyanez fog kijönni neked, mint a szolgáltatónak, arra kéne rájönni, hogy melyik modul(ok) okozza (okozzák).
Kedves Bálint!
Kedves Bálint!
Melyik ez a túlterhelős weboldalad a sok közül?
Üdv. Peti
RH
www.ragnarokhungary.com
1 hónapos
Pár hetes weboldal csak, karban tartási módban szerkesztjük, kb 300 fős online közösségnek. Nem tudom, hogy még mit kéne írnom az oldalról. Szolgáltatónak írtam még levelet, lehet hogy majd tudni fognak segíteni. Mi is gondolkoztunk csapattal se semmi ötlet nem ugrott be
profilozás, teljesítménymérések
Az előbb írtam, hogy komolyabb tesztelésnek kellene alávetnetek localhoston a Drupalt és elkezdeni nyomozni; azért írtam a localhostot, mert ott azt telepítesz, amit akarsz, osztott tárhelyen nem.
Ha nincs köztetek a csapatban olyan, aki hozzá tud ehhez szólni, akkor abból sztem sajnos munkaajánlat lesz. Mindenesetre energiabefektetés nélkül nem lehet megmondani a tutit így látatlanban, hacsak valakinek nincs valami kapásból győztes tippje, mert sajnos a telepített moduljaid listájával sem vagyunk tisztában.
Szerk.:
egyébként itt a választ adó egy MySQL-hez kötődő query cache bugról beszél:
http://drupal.stackexchange.com/questions/56730/drupal-sites-extremely-s...
nem tudtam még róla, de érdekes. Mondjuk ennek állítgatásához nincs jogosultságod, ha osztott tárhelyen vagy.
De még az is lehet, hogy meg kéne próbálkozni a Drupal cache-tábláinak teljes ürítésével (backup után), aztán megnézni, van-e bármi változás. Van, amikor már mindenféle lehetőséget végig kell próbálgatni, hátha.
minden zöld?
status report szuperzöld?
ilyen furcsaságok simán lehetnek pl nem rendesen futó cron esetén. meg persze lehet, hogy pont egy olyan mysql query cache bug van pont a te szolgáltatódnál, amit már linkelt Sk8erPeter, meg lehet nyilván ezer más dolog is, de ez már ő leírta, csak azt akartam mondani, hogy én a cront ellenőrizném először.
-
clear: both;
status report
Sajnos nem teljesen szuper zöld, de szerintem nincs benne kritikus hiba.
http://www.ragnarokhungary.com/playerpictures/report.jpg
igazából itt most csak a cron érdekes
hogy az fut e rendesen, de a kép szerint 7 perce futott. csak tippeltem, nem jött be bocs.
-
clear: both;
értem
Tegnap egész nap csak optimizálgattuk a weboldalt. Várom a szolgáltató levelét, hogy javultak-e a dolgok. De ha nem akkor már tényleg nem lesz ötletünk a hiba okára. Szívesen megadnék minden hozzá férést egy Drupal gurunak aki megnézné hogy honnan ered a hiba, de hát ingyen nem szeretnék senkit se dolgoztatni :)
Mondjuk írtunk hozzá saját modult ami regisztrációval kapcsolatos, és az user modulba is kicsit "belepiszkáltunk" , hogy megtudjuk valósítani amire pontosan szükségünk volt. De ezek mind egy másik adatbázissal vannak kapcsolatba ami nem szolgáltató szerverén van. Szerintünk ez nem okozhat ekkora hibát.
Drupal Chatre gyanakszunk még....
Every time you hack core God kills a kitten
http://www.flickr.com/photos/hagengraf/2802915470/
„Szerintünk ez nem okozhat ekkora hibát” Honnan tudod?
--
Palócz Paal Pál, a drupal.hu admin csoportjának tagja
Ajánlott olvasmány: Eric Steven Raymond - Hogyan kérdezzünk okosan
+1, főleg, hogy nevergone már
+1, főleg, hogy nevergone már szintén leírta épp a userek kezeléséhez kapcsolódó kérdésében:
http://drupal.hu/forum/regisztr%C3%A1ci%C3%B3-2-adatb%C3%A1zisba/17497
még egy ezzel kapcsolatos volt:
http://drupal.hu/forum/regisztr%C3%A1ci%C3%B3-testre-szab%C3%A1sa/17536
Szóval tényleg ne öldököljük a kismacskákat :D
Imádom a kismacskákat
Cicák a gyengéim, de máshogy nem tudtuk megoldani az igényünket csak így. Ha tudtok egy jó megoldást írni hozzá akkor azt nagyon nagy örömmel vennénk! Lentre kilinkeltem azt a kis módosítást és a saját modult is amit készítettünk.
Cache
Szia,
ezek tipikusan nagy méretű cache bejegyzések, melyek kezelése általában túlmutat a szokásos MySQL beállításokon shared hoszting esetén.
Mind az üzemeltető és ti is akkor jártok a legjobban, ha kaptok egy kis méretű cache backendet. Ez tipikusan vagy Memcache vagy APC lehet és várhatóan kb. 40-80MB közti memióriára lesz szükségetek. Ezzel leveszitek a más típusú lekérdezésekből adódó terhet a MySQL-ről: hatékonyabban, kevesebb erőforrásból és gyorsabban tudjátok kiszolgálni a látogatókat.
A #drupal.hu freenode.net IRC csatornán szerintem fogsz találni olyat, aki akár aktívan is segít a beállításban akár nektek, akár a hosztingot el tudja látni jótanácsokkal, miértekkel és hogyanokkal. :)
Lippai Ádám
young element
+1
A memória cache nálam mindig az első lépések egyike. Annyi kiegészítéssel, hogy nálam 4-6MB mindig elég volt memcache-ből egy sitehoz, nem biztos, hogy nektek kell olyan sok, mint alippai javasolta.
Amúgy meg csodálom, hogy senki nem írta, de Devel modulnak van olyan funkciója hogy kiírja az összes lefuttatott SQL-t a lap aljára. Azzal nézd meg. Sajnos 200-400 query normális egy Drupal site esetén, ahol nincs memória cache. De ha jól olvasom a számokat, nálatok ennél sokkal-sokkal több query fur le.
Egy tipp vaktában: nincs véletlenül nálatok sok fájl feltöltögetés? A fájlfeltöltés állapotát AJAX-szal kérdezi le a file field, és nem másodpercenként, hanem brutál gyakran. Ha valami más modul pl. hook_init()-ben sok query-t futtat, akkor az tényleg tud ilyet produkálni.
A core hackelést pedig tényleg felejtsétek el. Nem azért, mert az kiváltságosok privilégiuma lenne, hanem mert hosszú távon marha sok fejfájást fog okozni. A user api nagyon sokoldalú volt már D6-ban is, erősen csodálkoznék ha nem lehetne megoldani saját custom modullal az igényeiteket. Csak néttetek utána alaposan, akár a régi 6-os verziós Pro Drupal Development könyvben a lehetőségeknek.
Kalandjaim a Drupal és PHP világában.
Méretek
A méretek bizony nagyon sokmindentől függnek, pl. APC esetén az opcode cachet is bele kell számolni, gyorsan össze lehet kattingatni olyan űrlapot vagy viewot, ami magában 1MB felett van példányonként.
Edgarpenak teljsen igaza van, de mivel úgyis ilyen kedves a hosztingosotok, egykét nap alatt valószínűleg töredezés és vergődés mentesre be tudjátok állítani. :)
Lippai Ádám
young element
8 látogatót APC nélkül osztott tárhelyen ki kéne tudni szolgálni
Na de szerintem a napi 8 látogatót osztott tárhelyen, APC nélkül is ki kellene tudni szolgálni. A szolgáltató által jelzett brutális erőforrás-igény, a query-k száma pedig nem indokolt szerintem még akkor sem, ha 100 modul van telepítve az oldalra, és ha ennek a látogatószámnak az ötszöröse lenne (még az is csak 40):
Szóval én inkább valami rendkívül bugos működésre gyanakodnék elsősorban, vagy valamelyik modul, vagy épp a korábban említett esetleges MySQL query cache bug, vagy valami más hibaforrás következtében. Mondjuk az is igaz, hogy ahogy Drupalban a cache-elés például a fordításoknál működik, az szerintem nagyon durván erőforrás-pazarló...
Nekem elég gyanús, amit a kérdező kolléga írt, hogy belehekkeltek a core-ba, hogy a userek adatait, bejelentkezését, regisztrációját, aktuális állapotát egy külső adatbázissal tudják szinkronizálni. Jó lenne tudni, mit műveltek a core kódjával...
semmi extra
csak egy új változót vettünk fel amiben eltároljuk a jelszót. Mert 2 adatbázisba kell regisztrációt csinálni, de másikba nem jó a drupal hexás jelszó.
http://pastebin.com/SK6MKpXS user modul
428 sor nál van a saját kodunk...
http://pastebin.com/Yj7yqB92
Ez pedig a saját modulunk kódja.
Szerintem nincs összefüggésbe azzal a rendkívül sok lekérdezéssel...
Remélem tévedek!