Lassú localhost, phpMyAdmin, MySQL

Joee képe

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?

Drupal verzió: 
Joee képe

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.

0
0
bcsaba képe

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.

0
0
Joee képe

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.

0
0
bcsaba képe

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.

0
0
Joee képe

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.

0
0
dongodani képe

Itt írnak a témáról
Klikk ide...
Nálam az Acquia Dev Desktop alatt nem volt semmi gond.

0
0
Joee képe

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.

0
0
dongodani képe

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.

0
0
Joee képe

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?

0
0
Joee képe

Ú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?

0
0
dongodani képe

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.

0
0
HF leon képe

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.

0
0
Joee képe

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.

0
0
HF leon képe

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.

0
0
Drufan képe

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.

0
0