Prima dată ne-a fost reclamată de Gabi Ursan pe un site de-al lui și de atunci am mai întâlnit-o și pe alte site-uri. Se pare totuși că e aleatoare, pe unele site-uri nu se observă.
Problema se manifestă printr-un consum excesiv de memorie al instanței de WordPress și o încărcare greoaie a site-ului, în special în wp-admin.
După 2 zile în care i-am desfăcut site-ul lui Gabi în bucăți, am reușit să identificăm ce cauzează problema.
E o linie de cod în fișierul taxonomy.php din folderul wp-includes care creează niște cronjob-uri ce nu se șterg apoi automat, cum ar trebui. Astfel, în tabela wp_options din baza de date a WordPress-ului linia cu option_name cron crește și crește până ajunge să conțină zeci de mii de cron-uri invalide.
Pentru cine nu știe cum funcționează cron-ul WordPress, acesta rulează la fiecare afișare de pagină, deci site-urile cu trafic mare vor genera mai multe intrări de cron-uri invalide în baza de date decât cele cu trafic mai mic.
Linia respectivă, cron, din wp_options are setat autoload: yes deci la inițializarea WordPress se va încerca citirea ei. Fiind foarte mare, plină cu intrări invalide, acest lucru va duce la o durată mai mare de executare a interogării bazei de date, o creștere considerabilă de memory usage și de aici și încărcarea foarte greoaie a site-ului.
Problema a fost raportată la WordPress și va fi soluționată în următoarea versiune, 4.3.1.
Până atunci, v-am urcat pe Dropbox fișierul taxonomy.php actualizat, descărcați-l și suprascrieți-l pe cel vechi din folderul wp-includes al instalării voastre de WordPress.
Pasul 2 este să intrați în phpmyadmin, în baza de date a site-ului, și să ștergeți linia cron din tabela wp_options. Don’t worry, se va reface la următoarea accesare a site-ului.
Asta-i tot!
PS: știu că mă laud dar dacă se întreabă cineva vreodată de ce e bine să ai un hosting specializat pe WordPress, ăsta e unul din momentele alea.
De asta va laud eu pe unde va prind, ca aveti grija de noi. Doar ca nu mai stiu acum cum este cu Simplenet, Faster WP si blogrise. 🙂
Banuiesc eu ca le-ati schimbat numele, dar am procesorul mic, doar 2 neuroni…etc… 🙂
Sa revenim ontopic: stiu ca recomandati ca pluginui BruteProtect (se pare ca nu mai va fi updatat, am incercat sa iau eu un API gratuit, nu a functionat, asa ca am „sapat pe net”.
Ce parere aveti de Fastest cache? Eu folosesc versiunea free si sunt foarte multumit, nu apar conflicte.
O singura data am avut in timp o mica problema, l-am contactat pe autor (un turc, cred), iar el a rezolvat in cateva minute problema.
Si m-a ajutat si cu alte chestii pentru site, deci suportul este foarte bun.
Am vrut sa iesim cu solutia de hosting Simplenet si pe piata din Europa dar exista deja un alt Simplenet pe .com asa ca am facut site-ul fasterwp.com. Acum i-am schimbat numele in Blogrise, o sa scriu un articol si despre motivele din spatele schimbarii de nume.
Bruteprotect a fost cumparat de Automattic si face acum parte din Jetpack. Partea buna la el este ca are o baza de date centralizata, in cloud, cu IP-urile de pe care se incearca atacuri.
Fastest Cache e ok, in general nu sunt diferente majore intre pluginurile de cache. Noi folosim si recomandam Hyper Cache, e facut special pentru hosturile shared, ca sa consume putine resurse.
Multumesc, domnule Chira!
N-aveti pentru ce!
Merge și WP Super Cache – e mai user friendly pentru începători.
De mers, merg toate, nu e niciun plugin de cache care sa fie prost, poate W3TC este hai sa zicem nepotrivit pentru un host shared, dar din ce am testat noi pana acum cel mai bine se comporta Hyper Cache la varfuri de trafic.
Depinde foarte mult și de setările făcute pe serverul shared în privința resurselor alocate dar și de cum îți configurezi tu cache-ul prin intermediul pluginului.
La mine a rezistat la un vârf de peste 8.000 de vizitatori într-o oră și mă declar mulțumit.
Am încercat de curiozitate și Hyper Cache iar la testele teoretice nu prea am văzut să fie vreo diferență față de WP Super Cache. Să-l configurez mi-a luat ceva mai mult timp dar aceasta probabil pentru că sunt obișnuit cu celălalt plugin.
În altă ordine de idei am observat că multe bloguri găzduite la SimpleNET folosesc Wordfence (nu știu dacă la recomandarea ta sau nu) și voiam să te întreb dacă nu sughite serverul pentru că și mie mi-a fost recomandat dar consumă prea multe resurse și am preferat să merg pe mâna All In One WP Security care e mai light.
Ba mai mult le-am folosit o perioadă împreună și Wordfence nu a mai raportat nici o tentativă de intruziune.
Nu exista diferente mari intre pluginurile de cache, toate fac acelasi lucru, singura diferenta e ca unele folosesc htaccess altele php. Noi nu recomandam niciun un plugin de securitate, toate afecteaza performanta, intr-o masura sau alta.
O intrebare off-topic – am vazut ca ai inlocuit de ceva vreme Genesis Social Icons cu pluginul de Fan Box Facebook. Nu se incarca mai greu blogul? Crezi ca Google+ si Twitter nu merita promovate in Romania?
Se incarca putin mai greu, asa e. Nu cred ca e ceva relevant in Romania in afara de Facebook.
Și încă un off-topic, dacă nu e prea mult – de ce ai renuntat si la Mailchimp, inclusiv pe Mujo? Sa fi devenit abonarea prin email inutila?
Pe andreichira.ro oamenii gasesc abonarea daca vor iar pe mujo.ro se posteaza zilnic deci cine e interesat oricum intra zilnic sa vada ce s-a mai postat nou deci era inutila abonarea.
Multumesc mult pentru precizari! Imi place ca respingi abordarile conventionale.
Incerc sa fac ce cred ca e mai bine pentru atingerea obiectivului site-ului, timpul arata daca e bine sau nu.
Da, ai avut dreptate.. se încarcă puțin mai repede wp-admin, eu n-am băgat de seamă, pentru că oricum folosesc CloudFlare, și oricum mișcă puțin mai greu de la POP-urile lor.
Ca sa nu-i bagi in ceata pe unii cu DB-ul, sa nu strice si altceva, cred ca e ok si scriptul asta 🙂 https://wordpress.org/support/topic/high-cpu-load-after-update-to-v43?replies=82#post-7330770
Da, e ok scriptul ala.
Am un site de tip anunturi imobiliare, iar de ceva timp de cand numarul de anunturi a crescut, se incarca foarte greu.. Am incercat si metoda ta dar nu a functionat, deci clar problema e din alta parte. Am incercat sa iau legatura cu creatorii temei insa mi-au intors spatele desi tipa ce oferea suport era chiar romanca.. Ceva sugestii?
Un audit de performanta – http://simplenet.ro/optimizare-wordpress/
Nu e chiar aleator. Am intalnit problema (si am rezolvat-o) imediat dupa lansarea 4.3, pe blogurile cu trafic mare (>30k/zi). Ca adaugire… dezactivati cronjob-urile din WP si setati un cronjob clasic (wp-cron.php rulat via php cli sau wget) din cPanel / consola.
Noi nu prea avem clienti cu trafic asa mare, iar la cei cu trafic mic parea a fi cam aleator. Legat de cronjob-uri, e o idee foarte buna (si recomandata pentru performanta) dar am intalnit cazuri in care pur si simplu nu vrea 🙁
Se pare că tocmai ce-au rezolvat-o cu noul update WordPress 4.3.1
Da, era si cazul sa iasa update-ul asta.
Salut Andrei, mie imi tot dă resource limit is reached și nu înțeleg de ce.
Hostul e ok, nu am avut probleme până la update-ul wp, culmea am wp 4.3.1 și am verificat totuși ce ai scris tu, insa nu vad pe nicaieri o linie cron
in schimb cam atat vad pe langa alte procese „SELECT *
FROM `wp_options`
LIMIT 0 , 30
E dificil de dat un verdict fara un audit detaliat de performanta. Ca idee, limitele respective se ating daca ai trafic prea mare, daca sunt ele prea mici sau daca exista niste probleme de performanta cu vreun script PHP de pe contul respectiv care duce la un consum excesiv de resurse.
Am resurse bune pe host. Cred ca am descoperit problema. Am reinstalat wp.
Au fost o serie de erori. Doua pluginuri care au creat niște sperii goale.
O baza de date care aduna spameri și porn încât a ajuns la 280mb
O eroare pein wp-option.
Era prea mult de munca, a fost mai simplu sa reinstalez wp și sa mă apuc sa refac totul.
Cum recomanzi implementarea pluginului facebook pe care il ai si tu pe pagina – cu pluginul Jetpack sau prin copierea codului in widget?
Eu am cu Jetpack, e mai simplu.
Daca-mi permiteti, vreau sa fac o mica sugestie (offtopic). Folosesc un alt serviciu romanesc excelent, Smart Bill Cloud. Cred ca ati putea colabora cu ei, iar aici: http://www.program-facturi.ro/pachet-smart-business-discount/ cred ca ar putea sa apara si un discount Simplenet.
Scuze de offtopic. Ce parere aveti de acest plugin: https://ro.wordpress.org/plugins/shortpixel-image-optimiser/
Se pare ca este un plugin facut de romani, nu? Mie mi se pare tentant.
Nu l-am testat. Eu optimizez imaginile cu jpegmini inainte de a le incarca pe site.
Eu folosesc PhotoRazor de la stormdance.net si Riot, de la http://luci.criosweb.ro/riot/
mi se pare plin de bug`uri Wp`u si este o alegere neprofesionala
Da, din cauza asta 25% din toate site-urile din lume folosesc WP, ca e naspa.
Salut! Dacă serviciul de găzduire are deja un modul de cache este util să mai instalezi hyper chache? Nu intră în conflict unul cu celălalt?
Depinde de ce fel de cache are serviciul de gazduire, daca ofera page cache atunci nu mai este nevoie de inca un plugin care sa faca page cache (Hyper Cache, WP Super Cache sau oricare altul). Daca ofera alt fel de cache (Redis, Memcached, Varnish etc..) atunci se poate instala si un plugin care sa faca page cache.
Mulțumesc pentru răspuns. Nu au page caching, deci voi păstra și hyper cache.
Mai am o întrebare. Ai idee de ce diferă atât de mult statisticile din Google Analytics față de cele din Awstats? Analyitics îmi arată 14.000 de afișări lunar, awstats arată 80.000. E de șase ori mai mult. De unde diferența asta uriașă?
Un raspuns 100% sigur nu as putea sa dau dar, din cate stiu, Analytics incearca sa numere doar vizitatorii reali, in timp ce Awstats contorizeaza tot.
În cazul acesta, pe care să le iau drept statistici de referință?
Google Analytics.
That file isn’t here ! Poti pune un link valid ?
Problema a fost rezolvata in versiunea 4.3.1. WordPress a ajuns la versiunea 4.8.1, nu mai e nevoie de rezolvarea prezentata in articol.