Sziasztok!
Egy tarhely.eu-s drupal7 oldal ügyében írok, aminek lassulása kapcsán a többi hasonló topikban sajnos nem találtam választ.
A jelenség egyszerű a rendszer viszonylag normális üzemelést követően pár hét után egyszercsak lelassult. Aztán mégjobban lelassult az admin.
Napi 2000 olvasó van kb. Pár tucat comment, honeypot védelemmel, mert anonim is lehet hozzászolni és az image chaptca-t is lelőttem, hátha...
Néha magától (mert nem csinálok benne semmit) a sebességlassulás "megfodrul", azaz az admin lesz gyorsabb, és az anonim felület lesz baromira lassú.
Próbából lelőttem gyakorlatilag az oldalon minden modult így view-okat is (erre gyanakodtam az itteni írások alapján), de amikor gyakorlatilag a nagy semmi jelenik meg, még az is lassan tölt be.
Cpanelen CPU usage zömében 75-100%, de minden más dolog rendben van.
A honlap betöltése is érdekes, mert bejön a background, aztán "homokóra" egy darabig, majd villámként megjelenik minden. (megnéztem más sima d7-es sminket is, de azokkal is ugyanez van).
Ránéztem az sql-táblákra, de néha azok is baromira lassan nyilnak meg. Hiába végzi el a műveletet 0,00000000002 sec alatt a rendszer, amire ezt kiírja 10-15 sec és ajándék homokóra.
Van másik tárhely.eu-s oldalam is, de azzal nics ilyen gond. A support korábban optimalizálást kért, megtettem, de eleve ha már minden ki van kapcsolva (csak prá core modul fut), annál jobban nem tudok "optimalizálni", szóval máshol van szerintem a gond.
No de hol?
Előre is köszi a segítséget!
cron
Az időzített feladatok futnak az oldalon?
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés
Szia, az időzítő fut rendesen
Szia, az időzítő fut rendesen...
Adatbázis optimalizálás
Adatbázis optimalizálásra a DB Maintenance modult lehet használni. Időzive lefuttatja az optimalizálást.
Feltettem, lefuttattam az
Feltettem, lefuttattam az összes táblára, de semmi. :(
Tesztkörnyezet + profilozás, avagy hol van a palack nyaka.
Mivel azt írod 100% pörög a CPU ezért feltételezhetően szerver oldalon lesz a gubanc. Első körben én készítenék egy tesztkörnyezetet a saját gépemen és ott nézném meg, hogy mi történik. XDebug Profiler vagy a Devel megfelelő eszközeivel.
Ha itt nem találok jelentős hibát, akkor rákérdeznék a szolgáltatónál, hogy ő mit lát, mert simán lehet, hogy csak túl van terhelve a szervere.
pp
(palack nyaka (bottle neck) vagyis szűk keresztmetszet, de ez utóbbi nem fért ki)
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Igazad van. Új csomagba
Igazad van. Új csomagba került az oldal, SSD-s szerver, működő memchace, nagyobb erő és minden a legnagyobb rendben. Egyetlen belassulásos dolog maradt csak, ami utalhat valami bug-ra is.
Amikor új nézetet készítek megint belassul minden 6, 10 mseces oldalgenerálás, 5-10 secre is felkúszik szerkesztés után.
Ezt eddig nem láttam mert minden lassú volt. A nézet szerkesztése és a chace funkciók közöt lehet valami ütközés? Magukkal a nézetekkel nincs gond, nincs körbehivatkozás, és csak fieldeket hívnak meg sorban.
Ha ez megoldódna, minden rendben is volna.
Eloszor amig maga a pontos
Eloszor amig maga a pontos diagnozis, hogy mi is lassu nem nagyon bocsatkoznek tippelgetesbe. Peldaul az, hogy cache, vagy az adatbazis, ami a CPU loadot okozza azt meg nem tudjuk.
Elsokorben azt tanacsolnam, amit PP is mondott, probald kideriteni, hogy mi is tortenik. Ezt lehet nezni localhoston felrakott honlappal, xhprof-fal, devellel. Ha sikerul reprodukalni a problemat, akkor nyert ugyed van, onnantol fogva csak azt kell kitalalni, hogy mi a gondja, PHP processz, mysql stb. Ha PHP akkor meg lehet tovabb turni a profiler kimenetet.
Ha views, akkor slow query
Ha views, akkor slow query log a mysql-ben, vagy devel sql log (de vigyázni kell, mert a views elég jól kesel). Ha egy field-re van szűrés, beleértve a környezeti szűrőt, vagy valamilyen kapcsolt tartalmat, akkor ott lesz a probléma gyökere. A Field modul ugyanis soha nem rak indexet a filed értékekre, miért is tenné, Te meg azt használod egy sql query-ben.
Persze látni kéne a views-t, mert ha 100 felett node-ot akarsz megjeleníteni tartalom nézettel, akkor bizony az a 100 node_load ami öli a processzort Ez utóbbira nem is gondolnék, mert ez annyira alap, hogy már szinte soha nem használjuk ezt a lehetőséget a views-ban.
pp
Palócz István
https://palocz.hu | https://tanarurkerem.hu
Panelban hívok meg nézeteket,
Panelban hívok meg nézeteket, alig egy tucat noderól van szó. Egy nézet a címet, képet, body-bevezetőt hozza, aminek footerébe van ágyazva egy nézet, ami további 5 db. node-címmet listáz. Ilyenből van kb 4-5 blokk.
Van egy másik nézet a főoldalon, ami a node-okat taxonomy id alapján szűri. Van még egy slideshow 6-7 db node-val (kép, cím, bevezető) és kb. ennyi. Ez nem sok, a betöltés is marhagyors, de amint egy új nézetet definiálok (ami amúgy cserél egy meglévőt, csak fontos, hogy az előző nézet is megmaradjon) mintha lepedőt húznának a rendszerre, minden, de minden lelassul, örökre.
Field indexes dolgot nem nagyon értettem. Devel logok holnap következnek.
Köszönöm!
Entity cache
Hasznos lehet: http://drupal.org/project/entitycache
Választ szeretnél? - Új kérdés, új téma - Tesztoldal - Trollkezelés - Frissítés