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.
Lasă un răspuns