Windows 10 Pro (64 bit; CPU 4×1,6 GHz; RAM 4Gb)-en wampserver64 van telepítve Drupal 8-al. Már a Drupal telepítése közel 1 óráig tartott. A wampserver előtt xampp volt, de azért cseréltem mert az is nagyon lassú lett. Azóta kipróbáltam még másik localhostos szervereket is, de minddel ez a lassúság volt a probléma. Rendszeresek a várakozó üzenetek: "Várakozás a szerverre: localhost...". Érdekes, hogy egy tartalmi oldalt viszonylag gyorsan úgy 3-4 mp alatt betölt, de az admin felület nagyon lassú. Pl a Konfiguráció és a Bővítés menüpontok betöltődésének megkezdésére 12-18 mp-et kell várni, de bármire kattintok az admin felületen az legkevesebb 6-8 mp mulva kezdi a betöltődést. Egy gyorsítótár törlés úgy 45-50 mp. A böngészőben a várakozás alatt a "Várakozás a szerverre: localhost..." felirat látható, de szerintem a várakozás azért lehet ilyen hosszú, mert az adatbázis későn válaszol.
A Drupal telepítése után telepítettem egy phpBB3.2 fórummort is ami másodpercek alatt települt és bármilyen kattintásra azonnal reagál.
Gondolom az nem lehet gond, hogy a nem a wampserver www mappájába telepítettem a drupalt, hanem egy almappába www/newdrupal/
Ugyanez a Drupal van élesben egy szolgáltató szerverén, de ott semmi gond a sebességgel a saját gépen pedig olyan a sebesség mintha a naprendszeren kívül lenne a localhost. Mi lehet az oka?
Háttértároló: SSD
Annyit tennék még hozzá, hogy a háttértároló sem lassú. Egy SSD van a gépben és hely is van rajt bőven.
Ha belépek a phpMyAdmin felületére és kijelölöm a Drupal adatbázisát akkor azt is nehezen adja be. Ha utána rákattintok pl a "Méret" szerinti rendezésre akkor az is 10 mp-ig tart mire megkezdi az átrendezést. Ha a fejléc másik rendezési szempontjára kattintok azok is mind 10 mp időt vesznek igénybe mire teljesülnek. A mysql my.ini fájlban az alábbi gyorsítással próbálkoztam a mysqld szakaszban, de semmiféle változást nem eredményezett:
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
Néztem a processzor sebességeket is a Drupal Admin menüpontok váltásakor és a legnagyobb sebességet az Apache HTTP Server foglalja (30-35%). A teljes processzor használat ilyenkor 65%.
A legtöbb memóriát a Crome foglalja 450 Mb körül.
A mysql.exe is csak 4-6% processzorsebességet használ és 96 Mb memóriát foglal el.
Ami meglepő, hogy a Drupal menüváltása után legnagyobb hálózati forgalmi terhelést a Google Chrome teszi, de az is csak 0 - 0,1 Mb/s!!! Amíg egy Facebook oldal kezdőlap újraolvastatása 11 Mb/s hálózati sebességet generál és 1-2 mp alatt betöltődik, addig egy helyi szerveren levő Drupal Admin menüváltás csak 0,1 Mb/s-ot, de 8-16 mp-et vesz igénybe. Miért kicsi és lassú a helyi szerveren levő Drupal forgalmazás, míg a távoli Facebook százszoros átvitellel repeszt? Ennyire azért nem lehet lassú az az Apache, hiszen még terhelhetné nyugodtan a processzort és memória is lenne még neki a 4 Gb RAM-ból. A háttértároló sem lassú, mert egy SSD van benn és helye is lenne neki rajt bőven.
Probald meg az alabbit:
Probald meg az alabbit:
Intits el egy command prompt-ot Administratorken(!)
futtasd le sorban az alabbiakat
netsh winsock reset
netsh winsock reset catalog
netsh int ip reset reset.log
netsh int ipv4 reset reset.log
netsh int ipv6 reset reset.log
ipconfig /flushdns
Inditsd ujra a windowst majd nezd meg hogy javult-e.
Lefuttattam és újraindítottam
Lefuttattam és újraindítottam a gépet, de semmi változás.
Ezeket kaptam vissza. Ott van egy hiba az IPV reseteknél:
C:\>netsh winsock reset
Sucessfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.
C:\>netsh winsock reset catalog
Sucessfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.
C:\>netsh int ip reset reset.log
Resetting Compartment Forwarding, OK!
Resetting Compartment, OK!
Resetting Control Protocol, OK!
Resetting Echo Sequence Request, OK!
Resetting Global, OK!
Resetting Interface, OK!
Resetting Anycast Address, OK!
Resetting Multicast Address, OK!
Resetting Unicast Address, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting Potential, OK!
Resetting Prefix Policy, OK!
Resetting Proxy Neighbor, OK!
Resetting Route, OK!
Resetting Site Prefix, OK!
Resetting Subinterface, OK!
Resetting Wakeup Pattern, OK!
Resetting Resolve Neighbor, OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , failed.
A hozzáférés megtagadva.
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Restart the computer to complete this action.
C:\>netsh int ipv4 reset reset.log
Resetting Compartment Forwarding, OK!
Resetting Compartment, OK!
Resetting Control Protocol, OK!
Resetting Echo Sequence Request, OK!
Resetting Global, OK!
Resetting Interface, OK!
Resetting Anycast Address, OK!
Resetting Multicast Address, OK!
Resetting Unicast Address, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting Potential, OK!
Resetting Prefix Policy, OK!
Resetting Proxy Neighbor, OK!
Resetting Route, OK!
Resetting Site Prefix, OK!
Resetting Subinterface, OK!
Resetting Wakeup Pattern, OK!
Resetting Resolve Neighbor, OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , failed.
A hozzáférés megtagadva.
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Restart the computer to complete this action.
C:\>netsh int ipv6 reset reset.log
Resetting Compartment Forwarding, OK!
Resetting Compartment, OK!
Resetting Control Protocol, OK!
Resetting Echo Sequence Request, OK!
Resetting Global, OK!
Resetting Interface, OK!
Resetting Anycast Address, OK!
Resetting Multicast Address, OK!
Resetting Unicast Address, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Resetting Potential, OK!
Resetting Prefix Policy, OK!
Resetting Proxy Neighbor, OK!
Resetting Route, OK!
Resetting Site Prefix, OK!
Resetting Subinterface, OK!
Resetting Wakeup Pattern, OK!
Resetting Resolve Neighbor, OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , failed.
A hozzáférés megtagadva.
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Resetting , OK!
Restart the computer to complete this action.
C:\>ipconfig /flushdns
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
Biztos hogy adminkent
Biztos hogy adminkent inditottad el a command promptot?
Regebb en is sokat veszodtem ezzel a problemaval es ezt mindig bevalt, aztan meguntam, tettem linuxot es azota nincs hasonlo problemam.
Teljesen biztos, hogy adminként
Teljesen biztos, hogy adminként, pontosabban rendszergazdaként. Miből gyanítod, hogy nem? A hozzáférés megtagadása miatt? Ha a CMD-ot rendszergazdaként indítom szerintem az még nem jelenti azt, hogy a CMD által futtatott minden alprogramra is rendszergazdai jogosultságom lesz automatikusan.
én is tennék Linuxot vagy valamelyik BSD-t, de Telekomos sticket használok internethez és attól tartok, hogy ahhoz biztosan nem lenne driver. Internet nélkül fejlesztgetni pedig bajos. Mindig kell valami infót keresni, de a távoli szerverhez is hozzá kéne férni. Az meg nem igazán kellemes, ha minden interneteléréshez újraindítom a gépet a második rendszerrel ami Windows és utána megint vissza a Linuxra. A Telekomnál már kérdeztem és azt mondták, Linuxos driverük nincs mert igény sem volt rá eddig. Érdekes. Tudom lehet virtuális gépre is, de attól tartok, hogy azzal megint jönnének a gondok mint a windowssal. Két notebookot meg nem akarok hordani. Talán ha okos telóról tudnék netet osztani a Linuxos gépnek akkor érdekes lehetne.
Itt írnak a témáról
Itt írnak a témáról
Klikk ide...
Nálam az Acquia Dev Desktop alatt nem volt semmi gond.
Láttam.
Igen láttam. Itt a stackoverflow-n is írnak rengeteg módszert. Annyit, hogy még végig sem tudtam mindet próbálgatni, de eddig egyik sem segített.
Az Acquia Dev Desktop valami újabb "tuti" localhostos szerver ami automatikusan telepít egy öreg 4 hónapos Drupalt? :-) Ezt már a legtöbb l. szerver tudja, csak azok a legújabb verziót telepítik drupal.org-ról. Próbálkoztam már többel is, de eddig mindnél ugyanez a lassúság jött elő. Lehet, hogy valami windows beállítás ment el és akkor hiába bármilyen automata telepítő amíg a hiba ki nincs javítva.
Akkor húzd újra a Win-t. Egy
Akkor húzd újra a Win-t. Egy ssd-re kb 15 perc az egész. Ha úgy sem lesz jobb, egy másik Win 10-es gépen is ki lehetne próbálni.
Nem látom annak semmiféle akadályát, hogy az Acquia Dev Desktopra mindig a legfrissebb Drupal verzió kerüljön fel. Egy jó eszköz, amelyen komoly fejlesztéseket nyomtam le, amelyek utána éles szerver környezetben is bizonyítottak.
Telepítettem az Acquia Dev Desktop-ot.
Ezen van még mit fejleszteni! Olyan mint valami gyenge béta verzió. Telepítéskor lehet választani, hogy akarom-e, hogy ő telepítsen egy elavult Drupal verziót vagy egy a gépemen már meglévő Drupal kódbázist használjon. Ezt választottam. Kérte az adatbázis fájlt. Megkapta. Erre azt mondja, hogy ő azt a verziót nem ismeri, de ha akarom azért feltölti. Nem ismeri, mert amit ő ismer és be lehet állítani azok régi verziók és az új nincs a kiválasztható listáján. Rányomtam, hogy töltse fel! Feltöltötte. Siker. Próba. Hiba: "The provided host name is not valid for this server." Persze, mert localhost helyett megadta annak a mappának a nevét amelyikben a Drupal van. Kijavítom a beállításaiban. Erre elindul, de nincsenek képek és a CSS-t egyáltalán nem ismeri és ettől összedőlt a kinézet. Gondoltam telepíttetek vele indulástól egy új verziós szűz új Drupalt, csak előtte eltűntetem a jelenlegi beállításokat. Erre legyalulta az egész Drupal mappámat. Még az elmentett doc almappámat is kiirtotta. :-( Sebaj! Csak háromnegyed óra alatt újra lehet rakni a lassú wampserverrel.
Nekiállok a szűz Drupal telepítésének. Bekéri a Drupal kódbázisát. Megadom neki azt ahová a Drupal telepítőjét másoltam. Kéri a host nevet. Megadom, hogy localhost. Települ. Indítom. Megint az előbbi hibaüzenet Hát persze, hogy a hostnév már megint a fájlokat tartalmazó mappa neve, pedig magam írtam be kézzel a localhostot. Kijavítom. Erre elindul. Van hibaüzenet. Nézem: Hiba-1: "BEÁLLÍTÁSOK KÖNYVTÁRAI
Nincs jelen sites/mydrupal.dd/settings.php fájlban szerepelnie kell a $config_directories változónak, ami azoknak a könyvtáraknak a nevét tároló tömb, ahová a beállításfájlokat írni lehet. sync kulcsot szintén tartalmaznia kell."
Nézem a megadott helyen a settings fájt. Nincs ilyen bejegyzés. Nézem a Drupal szabvány helyén levő settings fájlt. Abban sincs. Nézem a régi elmentett, tömörített működőképes Drupál settingsét és abban sincs ilyen. Ezek szerint nem is kell csak ennek az új csodaprogramnak. Ez az Acquia Dev Desktop elmásolta a Drupal beállításokat egy maga kreálta helyre és azt is eltolta.
Hiba-2: "A trusted_host_patterns beállítás nincs még megadva a settings.php fájlban, ami biztonsági kockázattal jár. Erősen ajánlott ennek mielőbbi beállítása. Ehhez további tudnivaló a Védekezés a „HTTP HOST Header”-es támadások ellen leírásban található (angol nyelven)." Ez nem hiba. Ezt már rutinból korrigálom, azaz korrigálnám a már megszokott módon, de ahogy bármit is beleírok a settings fájlba, azonnal összetojja magát a csodaszerver és megint csak a "The provided host name is not valid for this server." hibaüzenetet nyomja. Mindkét settings-et egyforma tartalmúra írom, hátha összehasonlítja őket és eltérést talál és közben a szervert is újraindítom, hátha... Változatlan minden. Kiderül, ha csak egy jelentéktelen dolgot is megváltoztatok a settingsben azonnal ledöglik.
Ha viszont nem foglalkozok ezekkel a hibaüzenetekkel akkor a szűz Drupal elég gyors és a Drupal telepítése sem háromnegyed óra volt vel hanem legfeljebb 10 perc vagy kevesebb.
Amit észrevettem, hogy a csodaszerver nem a 80-as portot használja mint a wampserver, hanem a 8083-ast. Lehet, hogy ez lesz a megoldás?
Sajnos a 8083-as port beállítása sem segített.
Úgy látszik meg kell válni a Windowstól és helyette Linuxot vagy FreeBSD-t telepíteni. :-(
Csak az a baj, hogy a Borland Delphihez meg kellene a Windows. Virtuális gépet nem akarok. Valószínű a DVD helyére rakok még egy SDD-t és arra rakok FreeBSD-t. Valaki használta mostanában a FreeBSD-t? Régebben, úgy 8 éve használtam és nagyon elégedett voltam vele.
Valakinek javaslata vagy jobb ötlete lenne esetleg?
Szerintem csak a laptopod
Szerintem csak a laptopod gagyi. Vélhetően nem teljesen kompatibilis a Win10-el. Van ilyen, az egyik laptopom nem sokkal a Win10 telepítése után csontra fagy. Ugyan ez a gép Win 7 és linux alatt hibátlan. Egy nem teljesen kompatibilis driver is okozhat furcsa lassulásokat, vagy fagyásokat. Ettől függetlenül egyetlen más gépem esetében sem tapasztaltam Win10 alatt lassú D8 működést.
Windows alatt valóban a Drupal Admin a leglassabb
A portnak semmi köze a sebességhez. Windows rendszeren valóban a Drupal admin felülete a leglassabb. Sok megoldás van a gyorsításra, de a szerver első indítása után egy-egy oldal első betöltése simán lehet 10-20 másodperc, néha több is. Használat közben ez az idő 2-5 másodpercre csökken maximum.
A gyorsítótár webes felületen át végzett ürítése nagyon lassú. Azt nem tudom, hogy miért. Viszont csak a webes felület ilyen lassú a gyorsítótár ürítése. A gyorsítótár ürítése után az admin oldalak első betöltési ideje ismét megnő kb 5-6 másodperc környékére. i7 3GHz, 12GB RAM, SSD.
Érdekes, hogy linux alatt valóban szaporább kicsit, de ott is a lassabb adminisztrációs felületek közé tartozik a D8 Admin felülete. Kíváncsi leszek, hogy D9 alatt ez javul-e.
Amit írtál az túl lassúnak tűnik, még a D8-hoz képest is. Pár tipp windows alá:
-Használj domain neveket az almappázás helyett (Windows host fájl és szerver virtula host).
-Használj php 7.3-at.
-Módosítsd a my.ini beállításait:
port = 3306
socket = /tmp/mysql.sock
skip-external-locking
key_buffer = 384M
max_allowed_packet = 256M
table_open_cache=4096
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 64M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
innodb_buffer_pool_size = 384M
innodb_additional_mem_pool_size = 20M
innodb_log_file_size = 10M
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 180
Ha semmi nem segít, akkor lehet túl lassú a géped sajnos :(. Esetleg, még a szerverfolyamatok prioritását is lehet növelni normálról mondjuk magasra.
„Windows 10 Pro (64 bit; CPU 4×1,6 GHz; RAM 4Gb)-en wampserver64 van telepítve Drupal 8-al”
Túl lassú a proci és kevés a RAM. Ma már nem árt minimum 2.6GHz, vagy gyorsabb i5 (legalább 4 valós maggal), minimum 8GB memória.
Korábban gyors volt.
Ha a gép lenne lassú akkor a Acquia Dev Desktop alatt is lassú lenne a D8. A Acquia Dev Desktop-ot a bolondériái miatt nem használom.
Nem azért van 4×1,6 GHz -es gépem mert nincs pénzem gyorsabbra, csak ennek kicsi az áramfelvétele. Amúgy a szekrényben van egy 4× vagy 8× sok GHz-es, fémházas (ipari) Dell, csak rengeteget fogyaszt és zabálja az akkut. RAM-ot vehetek ebbe a kisebb gépbe ha segítene, sőt meg is vesze a maximumot amit még kezelni tud, de szerintem a hiba ugyanúgy megmarad. Teszteltem a gép erőforrásait, ahogy felül is írtam és leírtam az eredményeit is, maradt még RAM neki, de nem használja ki és processzorsebesség is lenne, de azt sem használja ki. A prioritást beállítottam valós idejűre és nem segített. A kérés kiküldése után néztem a RAM-ot procisebességet, hálózati adatátviteli sebességet és szinte semmiféle emelkedést nem produkál. Amikor a kérés (kattintás a menüre) kimegy akkor a hálózati átvitel a kimutathatósági alapérték minimumán van. Majd ezt követi a hosszú, látszólagosan semmit tevő, tevékenység nélküli várakozás, semmiféle erőforrás érték (RAM, procisebesség) nem emelkedik, majd egyszer csak lesz egy nagyon pici hálózati forgalom és bedobja az új lapot. Amúgy régebben xamppal is gyors volt a D8 csak hónapokig nem használtam a xamppot és amikor elindítottam akkor már lassú volt. Ezért kezdtem másik szervereket is kipróbálni. Fut rajt egy phpBB3 fórummotor is és az nagyon gyors.
Most php 7.3.5 fut. Gondolod ha downdate-elném 7.3-ra az segítene? Csak azt meg külön kéne telepítenem, mert nincs alapból telepítve. Van rajt 7.3.5; 7.2.18; és régebbiek. Próbáltam már régebbi verziókkal is, de nem volt különbség. Érdekes, hogy D8-on levő oldalakat viszont viszonylag gyorsan betölti.
Próbáld meg, akkor manuálisan.
Még 4 giga memóriától azért biztosan gyorsabb lenne a gép. Általánosan használt gyengébb laptopok közül sokat mentettem meg a vinyó SSD-re cserélésével és a régen divatos 4GB RAM 8GB-ra cserélésével.
Most ettől eltekintve egy lehetőséged, még van, ha az Acquia Dev Desktop tényleg jobban működik. A 7.3.5 ös PHP nyugodtan maradhat, de jelenleg a 7.3.10 az aktuális.
Először érdemes megszokni, hogy nem telepítünk localhost-ra simán rendszert és almappákat sem szerencsés használni. Nem rosszindulatból mondom, de tényleg jobb, ha minden munkádnak csinálsz egy egyedi teszt domain a gépre. Simán a host fájl módosításával és az apache virtualhost szolgáltatásával megoldható. Inentől pedig oda teszed a gépen a drupalt, ahova akarod. Amikor az apache szerver megkapja a kérést, akkor a domain-hez társított könyvtárból fogja betölteni a rendszert, mintha az a szerver gyökér web könyvtára lenne. Ez nginx szervernél is megoldható.
Egyébként nem a "csodaszerver" tojja össze magát, hanem aktivizálódik a trusted_host_patterns funkciója a drupal-nak és ezért kapod a "The provided host name is not valid for this server." hibaüzenetet. Viszont otthoni fejlesztésnél lénygtelen a trusted_host_patterns funkció. Csak a netről elérhető rendszer esetén számít. Vagyis elég akkor felkonfigurálni, mikor feltöltöd azt egy valós kiszolgálóra egy valós domain alá.
Tehát megfelelően felkonfigurált host beállításokkal a Acquia Dev Desktop drupal rendszere is jól futna.
Viszont manuálisan is telepítheted az apache szervert a php-t és az adatbázisszervert. A beállításokat átveheted az Acquia Dev Desktop által telepített rendszertől http.conf, my.ini, php.ini Ekkor manuálisan is felteheted a programokat és azt állítasz be amit szeretnél. Igazából a WAMP, XAMPP, stb. sem csinál mást, mint feltelepít egy apache szervert, hozzá egy php-t és mellé egy mysql adatbázisszervert, esetleg pár kiegészítő szolgáltatást és ad ezek működtetéséhez egy felületet, ahol bekattintgathatók a beállítások, amiket aztán ez a felület ír be a megfelelő konfigurációs fájlokba.
Egyébként a te gépeden meglehet, hogy a 32 bites verziók gyorsabban futnának, mint a 64 bitesek. Ezt igazából ki kell próbálni.
Nekem is haláli lassú a Wamp,
Nekem is haláli lassú a Wamp, naponta többször munka közben elkezd úm. homokórázni a Drupal, néha nincs türelmem megvárni és többször rányomok a frissítésre, vagy ha nagyon dühös vagyok már miatta akkor simán bezárom a böngészőt. Tudom ez brutál, de szánalmas, hogy Windows-on mennyire lassú.
Amint lesz időm telepíteni, Linux-on fogok fejleszteni, az már tuti.
Mit csinálhat olyankor a szerver amikor várni kell rá?
Most Ubuntura telepítettem Xampp-ot egy 2,6 GHz-es gépre 8Gb rammal. A Drupal friss telepítése több mint másfél óráig tartott. A válaszidők még lassabbak mint korábban. A processzor alig dolgozik, a ram alig foglalt. Letiltottam a swap-ot is, hátha azért lassú mert oda dolgozik a rendszer a ram helyett, de ez sem segített. Most már biztos, hogy az adatbázis válaszára várakozik sokat a rendszer. Nem tudom mi tart ilyen sokáig egy helyi szerveren? A távoli szerverre telepített Drupallal semmi gond. Az szélsebesen fut ugyanezekkel a gépekkel mint kliens. A helyi szerveren viszont pl. a Drupal cache törlése több mint 2 percig tart egy frissen telepített üres Drupalnál. Némelyik admin menüpontra kattintás 10-20 másodperc múlva történik meg. Sokáig semmi nem történik majd egyszer csak hirtelen bevágja a kért oldalt.
Érdekes megfigyelés:
Ha a Drupal admin menüpontjaira történő kattintásokkal váltogatok az admin menüpontok között akkor először nagyon lassú az új menüpontnak megfelelő oldal betöltődése, de ha olyan menüpontra kattintok amelyikre nemrég is kattintottam már akkor már gyorsan betöltődik. Ha viszont várok vele úgy 20 percet akkor megint nagyon lassan töltődik be az előbbi oldal és alul a láblécen ez van kiírva: "Várakozás a szerverre: localhost..."
Ebből arra következtetnék, hogy valami rengeteg dolgot írhat ki valami Drupal vagy adatbázis cache-be és amikor rövid időn belül adom ki ugyanazt a kérést akkor a cache-ből tölti be, de amikor többet várok akkor először újraépíti és kiírja a cache tartalmát és csak utána teljesíti a kérést? Akkor talán ezt a Drupal vagy adatbázis (szerver) cache-elést kellene letiltani a szerveren, hogy ne cache-eljen, hanem azonnal teljesítse a kérést! De hol? Talán az is segítene ha rá lehetne venni, hogy ne a háttértárolóra írja ki a cache-t, hanem a ram-ba, hiszen van ott hely bőven. Fejlesztéskor amúgy sem előnyös a cache-elés, mert a változásokat akarjuk látni és nem azt, hogy mi volt korábban a cache-ben? Hogy lehetne azt megtudni, hogy mit csinálhat olyankor a szerver amikor látszólag nem csinál semmit és 20 másodpercig tétlennek tűnik miközben a számítógép erőforrásait (processzorsebesség / ram) láthatóan nem használja ki?
• Kiszolgáló: Localhost via UNIX socket
• Kiszolgáló típusa: MariaDB
• Szerver kapcsolat: SSL is not being used
• Kiszolgáló verziója: 10.4.8-MariaDB - Source distribution
• Protokoll verzió: 10
• A kiszolgáló karakterkódolása: UTF-8 Unicode (utf8mb4)
• Apache/2.4.41 (Unix) OpenSSL/1.1.1d PHP/7.3.11 mod_perl/2.0.8-dev Perl/v5.16.3
• Adatbázis-kliens verziója: libmysql - mysqlnd 5.0.12-dev - 20150407 - $Id: 7cc7cc96e675f6d72e5cf0f267f48e167c2abb23 $
• PHP-kiterjesztés: mysqli curl mbstring
• PHP verzió: 7.3.11
Alakul a nyomozás. Írja a fogalmam sincs mit az SSD-re. De miért
Utóirat:
Alakul a nyomozás. Felraktam egy olyan gépre a Xampot és a szűz, üres Drupalt, amelyik kijelzi a háttértároló pillanatnyi használatát. Kiderült, hogy amikor kattintok egy Drupal admin menüre akkor valamit azonnal, rettenetes tempóval elkezd kiírni a HDD-re, miközben a processzor alig dolgozik és a 8 Gb ram-ban is alig van valami. Olyan sokat ír a háttér-tárolóra, hogy azzal még az SSD sem tud megbirkózni. Már az Ubuntu swapot is letiltottam, de semmi változás.
Mi lehet az a hatalmas adatmennyiség amit csak 10 másodperc alatt tud kiírni még egy SSD-re is, ha rákattintok a "Beállítás" (admin/config) menüpontra?
Ha se processzor használat,
Ha se processzor használat, se memória foglalás nincs, akkor kizárásos alapon valamelyik hálózati erőforrás nem elérhető. Vélhetően a háttértáron is azt próbálja megkeresni, ezért az intenzív háttértár használat. Erre utal, hogy több gépen és oprendszeren is megmaradt a hiba. Nálam a friss D8 Win10/XAMPP alá cirka 10 perc alatt ment fel hibátlanul egy 3.gen I5-ös laptopra és semmivel sem lassabb az admin felület, mint a 3. gen i7-es gépemen (valódi 4 magos CPU+8GB RAM), Acquia Dev Desktoppal, azaz kellően gyors.
A nem elérhető hálózati
A nem elérhető hálózati erőforrást, hogy lehet megtalálni?
A gyorsítótárazás ki van kapcsolva itt: localhost/admin/config/development/performance
Most az tűnt fel, hogy a frissen telepített, tartalom nélküli Drupalnál törlöm a gyorsítótárat, amit úgy 2 perc alatt végez el, pedig le van tiltva a gyorsítótárazás. Ez alatt az idő alatt semmire sem kattintok, majd amikor befejezte a gyorsítótár törlését akkor megint rányomok a gyorsítótár törlésére és megint másfél percig használja a HDD-t. A frissen törölt gyórsítótáron mit tud szöszmötölni másfél percig? Egyáltalán mi ez a rengeteg HDD használat? A távoli szerverről ennyi idő alatt az egész adatbázist lementem a HDD-re, de még talán a Drupalt is át tudom másolni valahová. Honnan vehet ennyi adatot amivel dolgozik, amikor az egész drupál nincs ekkora?
Csak webes felületen lassú
Nekem csak, akkor lassú a gyorsítótár törlése, ha a webes felületen kérem. A konzol gyorsabb. Lehet a settings.php-ben is beállítani a különféle gyorsítótárak törlését is. Ez a módszer is gyors. Egész pontosan ilyenkor nem használ gyorsítótárat.
A webes felületen viszont mindig lassú a gyorsítótár ürítése.
A nyelvi telepítő öt-tíz -esetleg tizenöt -perccel is lelassíthatja a telepítést, de órákig nem tarthat.
Ha jól van beállítva a webszerver az adatbázis szerver és a php is, akkor sem sebesség bajnok a drupal, ha az admin felületét nézzük, de 5-10 másodperc alatt általában be kell jönnie a lapoknak. A lapok első betöltése időnként lassú, ami 10-20 másodpercig is eltarthat, de az ismételt betöltés átlag max öt másodpercen belül lefut.
Okozhat, még problémát, ha frissítéseket keres, stb és nem éri el a netet a szerveren keresztül.
Sajnos valóban nem sebességbajnok a drupal admin része és a hagyományos telepítő is tud lassú lenni, de, amit írsz az tényleg durva.
Egy erősebb gépen nem szokott gond lenni 3GHz körüli modernebb i7, 8-12Gb ram és legalább Sata 3-on üzemelő 500Mb/s olvasási sebességgel rendelkező SSD esetén alapvetően nem lehet gond.
Azért gyengébb gépeken is használható általában, de ott akad néha gond. Ha rákeresel a neten adnak néhány tippet a szerverek és a php beállításaival kapcsolatban.
Telepítettem a Drush-t, több
Telepítettem a Drush-t, több problémával és nem fut le a "drush cache-rebuild"
parancs, mert hibával zárul: "In BootstrapHook.php line 32: Bootstrap failed.
Run your command with -vvv for more information."
Azért telepítettem a Xampp-ot, mert az nagyjából a megfelelő beállításokkal települ.
A frissítések keresését, cron futtatását letiltottam, mert én is gyanakodtam rá, de semmi sem változott. Most szándékosan raktam be HDD-t, hogy jobban észrevehető legyen ha "kidugul". Amúgy 2 db 480Gb-os, sata3-as, 545/465 MB/s sebességű SSD volt berakva. Raktam i5, 8Gb ram gépbe és i3, 4×1,6GHz 8Gb ram gépbe is, de a processzor szinte alapjáraton ketyeg mindkét gépben és a ram is csak 20% alatt volt. A háttértároló (HDD vagy SSD) viszont igen nagy használatban van a hosszú várakozás ideje alatt. Cache több perces törléskor normál esetben ilyen hosszú idejű munkával az egészDrupalt át tudná másolni szőrőstül-bőröstül az adatbázissal együtt. Ezért nem tudom megérteni mit írhat ilyenkor úgy, hogy még csak látszata sincs a "nagy" munkájának?
Eseménynapló...? A teljes lassuláshoz az is elég...
Eseménynapló...? A teljes lassuláshoz az is elég, ha a webről egy külső szkriptet, vagy fontot nem, vagy csak nagyon lassan tud betölteni. Egy másik internet elérésről is megpróbálnám...
Az említett 10-12 perces D8 telepítésben már a magyar fordítások letöltése is benne volt. Ja és mobilnet...
A HDD-t viszont felejtsd el. Anno pont a D8 miatt vettem az első SSD-met, mert nem szerettem volna két kattintás között mindig elszívni egy cigarettát...
Úgy érted, hogy tiltsam le az eseménynaplózást?
Úgy érted, hogy tiltsam le az eseménynaplózást?
Nem tudom milyen szkriptet tölthet a netről egy frissen localhostra telepített, üres Drupal?Másik internet elérésről? Ezt úgy érted, hogy egy távoli gépról próbáljam meg elérni a helyi gépemen levő Drupalt? Ezt nem tudom, hogyan kellene beállítani, mivel szerintem nincs kívülről elérhető IP címe. A HDD-t csak próbából tettem be.
Arra utaltam, hogy van-e a
Arra utaltam, hogy van-e a hibanaplóban valamilyen gyanús bejegyzés. Illetve arra is, hogy egy másik internet elérésről is kipróbálnám a rendszer működését, egy frissen letöltött telepítőkészlettel. A friss rendszer is kereshet a netről frissítéseket, nyelvi fordításokat, szkripteket, fontkészletet és ha lassú, vagy nem hibátlan az internet elérésed, akkor ezekre a külső erőforrásokra való várakozási idő miatt a rendszer válaszideje szélsőségesen kitolódhat.
Nyelvi telepítés igen lassú tud lenni.
Maga a telepítés angol nyelven nem szokott lassú lenni. Viszont, ha egyéb nyelvet választunk az akár percekkel is megnövelheti a telepítési időt.
Régen így volt, ahogy írod.
Régen így volt, ahogy írod, de most másfél óra. Igaz HDD-re, de SSD-re is megvan közel egy óra.
Ott muszáj állítani a futási
Ott muszáj állítani a futási időkorlátot, legalábbis nálam kellett, különben nem volt elég ideje, hogy befejezze, mert a nyelvi cucc az tényleg hihetetlenül lassú. Mintha 1990-es évekbeli számítógépen futtatnék mostani Windows rendszert...
Adatbázis kezeléssel lehet a hiba.
Elindítom a phpmyadmint (http://localhost/phpmyadmin) és ha kattintok a Drupal adatbázis nevére akkor azt is 8-10 másodperc alatt tölti be. Majd kattintgatok a "gyárilag" ott levő adatbázisok között akkor először azokat is sok várakozás után tölti be, de másodjára kattintva valamelyikre már 2 mp alatt betölti. Ez rendben van így?
Minden hatástalan. Cache letiltása lehetetlen
Már minden fellelhető cache letiltást kipróbáltam a mysql szerver beállításaiban ami fellelhető volt a neten, de mind hatástalan. Továbbra is zavartalanul folyik a hatalmas méretű keselés a beállításoktól és letiltásoktól függetlenül. Talán valamit gyorsult a folyamat, de nem sokat. Így a localhoston nem érdemes fejleszteni, mert a távoli szerveren sokkal gyorsabban látszik a módosítás.
Egyetlen megoldás maradt: Az éles oldal mellett létrehozok egy almappát ahová letükrözöm az éles oldalt és a távoli szerveren kezdek fejlesztésbe, mert a localhoston nem lehet kivárni amire az adatbázis válaszol.
Megfordult a fejemben az is, hogy 8 év Drupalozás után áttérek a Worpressre.
És ettől mit vársz,
csak nem azt hogy megjavul a mysql szervered?
Valamit nagyon rosszul csináltál az ubuntu telepítéskor, ha a phpmyadmin is lassú - ugye ennek semmi köze a drupalhoz - nem gondolod? Vagy az egész ubuntu telepítésnél rontottál el valamit vagy csak a mysql-nél. Ha utóbbi akkor egy devilboxot (http://devilbox.org/) feltelepítve kiderül, ha az alatt a phpmyadmin rendesen megy. Ha az egész ubuntu telepítés van elrontva akkor nem fog változni semmi docker alatt sem, ugyan olyan szar lesz.
Üdv!
Dudás József
Nem megy
Egész napom ráment eredménytelenül, de már hetek óta kínlódok a localhost használhatóvá tételével. Telepítettem amit javasoltál a devilboxot, de itt már a Drupal telepítésén sem tudok túljutni, mert adatbázishibát dob mindjárt az elején.
Resolve all issues below to continue the installation. For help configuring your database server, see the installation handbook, or contact your hosting provider.
Failed to connect to your database server. The server reports the following message: SQLSTATE[HY000] [2002] No such file or directory.
Is the database server running?
Does the database exist or does the database user have sufficient privileges to create the database?
Have you entered the correct database name?
Have you entered the correct username and password?
Have you entered the correct database hostname?
Fogalmam sincs mi lehet a baja? Amit találtam a guglival azok nem működnek. Azt javasolják módosítsam a settings.php fájlt, de ha abba belenyúlok akkor már el sem indul a telepítő.
Nem kell drupalt telepítened,
hanem el kell menned a devilbox oldalról megnyitható phpmyadmin-ba és bemásolni egy bármilyen adatbázist. Ha gyorsan megy akkor a localhostra telepített mysql rossz, ha ugyan olyan lassan, mint a localon akkor az egész rendszerrel van baj.
Nem írtam, hogy telepíts drupalt a devilboxra az előző hozzászólásomban. Ha mindenáron telepíteni akarsz akkor nekem a settings.php-ban ezekkel a db beállításokkal megy:
Amiben neked a host az érdekes.
Üdv!
Dudás József
Feltelepítettem a Drupalt a DevilBoxra.
Egy teljesen üres (frissen telepített) 10 Mb-os Drupal adatbázist próbáltam feltölteni a phpmyadmin "Import" pontjával, de 2-3 perc szöszmötölés után ezt dobta: 502 Bad Gateway
Feltelepítettem a Drupalt a DevilBoxra. Ugyanolyan lassú mint a Xampp. Semmi különbség.
A drupal telepítéssel nem foglalkozok most,
mert az esetünkben irreleváns. Ha a dockeres adatbázis is lassú akkor a géppel vagy a telepített oprendszerrel van probléma.
Üdv!
Dudás József
Holnap felrakom a másik gépre
Holnap felrakom a másik gépre. Szerintem ott is ugyanez lesz.
Köszönöm az eddigi segítségedet.
Már napok óta ezzel a
Már napok óta ezzel a DevilBoxal kínlódok. Amúgy tetszene és rendben is volt vele minden amíg nem akartam egy drupal adatbázist feltölteni a MyAdmin grafikus felületén. Ott mindjárt dob egy 502 Bad Gateway hibát. Feltölti a 26 MB-os fájl 25%-át egy pillanat alatt és ott megáll és vár. Majd jön egy 502-es hiba. Error text: Bad Gateway (rejected) It seems that the connection to server has been lost. Please check your network connectivity and server status. A php.ini-ben a time-out-okat átállítottam hosszúra, de semmit nem jelent.
Át akartam állítani a gyárilag beállított php7.2-t 7.3-ra, hátha az segít, de ott meg az Ubuntu terminálban az újratöltés parancs után megáll a folyamat. Nem fagy ki csak a terminálban abbamarad a folyamat, nem fejeződik be, csak várakozik. Próbáltam újra indítani, de mindig megáll és nem is mindig ugyanott. Néha tovább fut a korábbi elakadásnál, de be nem fejeződik. Volt olyan, hogy várakoztam, hátha tovább megy és úgy fél óra múlva tovább ment, majd megint elakad, de ekkor már 2 óra múlva is ugyanott maradt és nem ment tovább. Ugyanezt megcsinálja az Ubuntu terminál egy sima apt-get upgrade parancsnál is. Olyan mint egy véletlenszám generátor. Hol itt hol ott akad el. Már a memóriát is leteszteltem és az SSD-ket is, de semmi kimutatható hibát nem találtam. Már hetek óta guglizok és próbálkozok, de nem tudok egy valamennyire normálisan működő localhost tesztkörnyezetet összehozni. Rengeteg időm ráment már és semmi eredménye. Hihetetlen.
Tehát ha jól értrm, Windows10
Tehát ha jól értrm, Windows10 alatt és Ubuntu alatt is egyformán lassú az adatbázis kezelés és vele a D8? Ráadásul csak nálad. Eléggé misztikus ez így együtt...
Felraktam a másik gépre. Valamennyit javult a helyzet.
CPU 4×2,3GHz, 8 Gb RAM, SSD 2×480Gb 550 MB/s, Ubuntu + DevilBox
Gyorsabb lett. ~15 perc alatt települt. Úgy 3-4 mp alatt vált egy admin menüt. Ez még mindig kétszer lassabb a távoli szervernél, de sokat gyorsult. Igaz, hogy a távoli szerveren van bőven tartalom, a localhost pedig üres. Gondolom a helyi tovább lassulna ha letükrözném a távoli szerver adatbázisát. Egy localhosttól azért elvárnám, hogy legalább olyan gyors legyen mint a távoli szerver, de úgy látszik ez nagyon nem így van. Még azért próbálok gyorsítani a localhoston azokkal a beállításokkal amit eddig találtam. Köszönöm mindenkinek aki foglalkozott a problémámmal és segített a megoldásban.
Miért gyorsabb a távoli szerver?
Láthatóan nem a processzor sebessége és a RAM mérete befolyásolja a lassúságot, hanem a háttértár sebessége. Most két 550 MB/sec sebességű SSD van beszerelve nálam, de a távoli szerver még mindig kétszer gyorsabban ad választ ugyanazoknál az admin menüpontoknál mint a localhost. Ennyivel gyorsabb lehet egy SSD-nél a távoli szerver háttértára? Mi lehet ott ami ilyen nagy sebességre képes? Fotonrakéta? Tényleg a háttértár sebessége szabja meg egy szerver sebességét? Milyen háttértárat kellene vásárolnom, hogy legalább elérjem a távoli szerver sebességét?
A szerverek mások.
A szerverek processzorai, memóriái és háttértárai eleve úgy lettek kialakítva, hogy a szerverfeladatokat szolgálják ki a legjobban. A processzorok gyorsítótárai jóval nagyobbak és gyorsabbak. Memóriából is jóval több van az eszközökben, valamint a háttértárak is gyorsabbak, ráadásul sokszor raid-be vannak kötve.
A drupal 8 esetén tényleg érezhető a szerver és a helyi gép közti különbség az admin felületen. Habár, ha egy régi hdd-s szerverre telepítjük php 5.6-ra, hát az is gyenge lesz. Láttam, már ilyet. Használhatatlan.
Érdekes, hogy más rendszereknél nem tapasztaltam ilyen lassulást. Jó kérdés, hogy a drupal admin felülete, mitől lassú.
A 3-4 másodperc átlagos idő. Az újbóli betöltés gyorsabb, de az első lapbetöltések ilyenek.
1
Törlés!
Szerver vásárlás lehet a megoldás?
Köszönöm a hasznos leírásod, magyarázatod. Sokat tanultam belőle amit sejtettem már korábban is, de nem voltam benne biztos. Ezek szerint egy valódi szerver vásárlása megoldhatná a lassúsági problémát?
Milyen összeállítású szervert kellene vásárolni kizárólag otthoni fejlesztés céljára, hogy ne legyen sok késése a Drupalnak? Nem ágyúval szeretnék verébre lőni és milliókat befektetni, mivel csak helyi elérésű szervert terveznék, de olyant sem szeretnék amelyik nem mutat előrelépést. Tudná valaki, hogy fejlesztésre milyen minimum hardware követelményeknek kellene megfelelnie egy otthoni szervernek? Az is érdekelne, hogy egy ilyen szerverre lehetne-e telepíteni Ubuntut vagy inkább FreeBSD-t kell? Laptopot nem lehet szerver verzióban kapni?
Én úgy vagyok vele, hogy ami
Én úgy vagyok vele, hogy ami 'gamer' (laptop, egér, szék, bármi) az minden baromi jó fejlesztésre. Az előző laptopomat 8 vagy 9 év után cseréltem, és csak azért, mert a télen nyitva hagytam az ablakot, ráfúj egy kis havat a szél a power gombra, és a szaki, aki megcsinálta, azt mondta, hogy ettől azért már ne várjak örökéletet.
Ja, és egész életét kvázi 'szerverkerként' élte, kubuntuval, 7/7 0-24 bekapcsolva minimális kivétellel.
----
Rájöttem, miért kérdezek olyan ritkán a drupal.hu-n. Amíg szedem össze az infokat a kérdéshez, mindig rájövök a megoldásra.