Încărcarea mare creată de blogul wordpress de pe server și o soluție extrem de incomodă pentru această problemă,

O încărcare mare generată de blogul WordPress de pe server și o soluție extrem de incomodă pentru această problemă

Bună ziua, dragi cititori ai blogului KtoNaNovenkogo.ru. C Sărbătorile care au venit!

În acest interval de timp (undeva în jur de o jumătate de oră), panoul de administrare oferă o eroare de 502, dar pentru vizitatori, deși site-ul este disponibil, paginile se deschid destul de încet (de la 5 la 15 secunde). Dacă caching-ul de pe blog nu a fost folosit, atunci ar da și 502 erori. Aceasta ajută numai la repornirea de două ori a serverului, sau o așteptare plictisitoare până când totul rezolvă de la sine.

În general, susțin infobox torturat în timpul acestor luni minuțiozitate (poate fi o mică broșură cu corespondența de a publica). În urma sunt acele opțiuni din această situație neplăcută, care au fost încercate, bine, voi descrie cazul absurd in care a beneficiat de aceste situații murdare, cum ar fi modul de a elimina (sau cel puțin, în trecut nu a respectat cele trei zile, dar dacă vii încă, atunci voi dezabona apoi despre prăbușirea speranțelor).

În mod episodic, încărcarea extra-limită a WordPress pe server

Cum totul a început să nu-mi amintesc exact. Îmi amintesc doar că nu am reușit să facem nici o concluzie obligatorie sau logică. În general, totul a început brusc și motivele nu au putut fi identificate. Deoarece nu cu mult timp înainte, am luptat împotriva virușilor pe mai multe site-uri. apoi, în prima oară după apariția problemei, a păcătuit doar pentru a sparge (sau pentru că nu a curățat complet cochiliile și alte muck). Prin urmare, din acest server virtual dedicat au fost transferate toate site-urile cu excepția a două, dar situația nu sa schimbat.

Nu a existat niciun motiv aparent, așa că am decis că cineva ar putea fi dozat. Însuși pentru a administra servere am Boom (mă tem că acest caz, chiar), așa că am întrebat tehpodderzhu infobox pe acest subiect pentru mine să răspundă nimic, cu toate că acestea nu sunt necesare în această urcare, pentru că nu au un server dedicat regulat shared hosting și virtuale, unde am fost proprietar, comandantul și suport tehnic cu excepția faptului că numai mașina gazdă este responsabilă, în cazul în care se află fizic pe server.

Cu toate acestea, dupa traditionalul „nu avem nevoie, dar va face“ baieti de suport tehnic au spus că se pare că nu există nici o DDOS (deși unele filtrare IP agresive acestea sunt încă configurate pe partea de siguranță). În opinia lor, sarcina este generată de site-ul însuși. Cu toate acestea, câțiva ani mai târziu, am fost încă de atac și apăra ajutat doar Cloudflare (îi mulțumesc pentru asta).

I-am răspuns că, în modul normal, sarcina este extrem de scăzut, pentru ambele bloguri WordPress instalat Hyper Cache plugin cu pagini stocate în memoria cache de actualizare perioadă de 10 zile. De fapt, în Parallels, care este folosit în Infobox. are o priză în cazul în care incarcarea serverului pe procesorul și memoria poate fi monitorizată în timp real. De obicei, există o imagine destul de idealistă afișată:

Dar, de mai multe ori pe zi, aceste valori cresc la 100% (foarte gag incepe atunci cand memoria este lovita de toti 100) iar site-ul, chiar si de la vizitatori, incepe sa se intoarca usor. Sprijinul tehnic pe întreaga perioadă a apelurilor mele la ceva ce încerca să ofere, a monitorizat serverul timp de mai multe zile și nu a observat nimic deosebit în legătură cu acest lucru, care ar putea fi influențat și "să ne facă bine".

Din ceea ce îmi amintesc:

1. A schimbat în toate direcțiile valoarea numărului maxim de conexiuni (și nu a înțeles ce este), dar toate nu au nici un rezultat. După părerea mea, chiar și odată cu creșterea numărului, site-ul de la vizitatori la momentul încărcării ridicate a fost și mai rău.
2. Creșterea planului tarifar (pentru câteva săptămâni în modul de testare - fără taxă suplimentară) de la Linux VPS-2048 până la 4 gigabit RAM și dublarea creșterii performanței procesorului. În mod paradoxal, bug-urile cu încărcare de 100% nu numai că au rămas, ci și au dus la inaccesibilitatea aproape completă a site-ului pentru vizitatori (nu se uită la cache), deoarece paginile s-au deschis pentru un minut. Așa că au luat totul urgent înapoi.
3. Traduceți dintr-un server virtual normal (cum ar fi un container) în cloud. Nimic nu sa schimbat, cu excepția faptului că suprasarcina serverului în acest mod a devenit semnificativ mai lungă. Prin urmare, am revenit din nou totul.

Am început deja să gândesc cu propria mea minte îngrozitoare, care poate servi ca motiv al acestui necaz. S-a încercat să se joace cu setările Hyper Kesha - cache-ul deconectat în zbor, încă cu unele experimente de neimaginabile căpușe. Apropo, pe parcurs, am realizat un design receptiv pentru blog și am reușit să închei suportul InfoBox-ului, astfel încât să mă instaleze în caching-ul nginx al elementelor statice în browserele utilizatorilor. Dar toate astea sunt de așteptat să nu fi adus absolut nici un progres în rezolvarea problemei cu o încărcare episodică mare pe server.

La naiba, în timp ce scriu paragraful anterior am amintit că în această direcție m-am gândit deja - Cum de a proteja zona de administrare a site-ului dvs. de hacking? și apoi nu a adus nici rezultatul așteptat. Se pare că am trecut deja în a doua rundă. Apropo, mi-e teamă pentru un motiv oarecare, pentru că trebuie să-i dau acces la site și este prost. Băieții de la găzduire spun că nu au timp, chiar dacă le plătesc timpul și efortul.

De fapt, datorită faptului că au încercat era tot ce am putut să-mi imagina sau cei care au scris pe acest subiect pe internet (cel mai bun din capacitatea mea mentală limitată, desigur), să creadă în „miracol“ M-am oprit și acesta, ca de obicei, a venit complet neașteptat.

Cum a fost posibilă rezolvarea problemei (sper că în cele din urmă)

Totul a început cu faptul că acum câteva zile mi-a inspirat ceva să mă uit la codul sursă al uneia dintre paginile blogului meu. Acest lucru este foarte util, deoarece în header (între etichetele Head) WordPress are un obicei prost pentru a împinge metataguri complet inutile și link-uri de serviciu. care poate degrada raportul dintre motoarele de căutare și site-ul.

De exemplu, nu este necesar să umblăm mult timp - destul de recent a descoperit un astfel de mușcătură că părul se afla la capăt. Despre detectarea și eliminarea ei, chiar și un post separat a scris (deși subiectul a apărut deja o lungă perioadă de timp, dar nu l-am luat serios) - Problema cu All-One SEO Pack și soluția sa.

În general, pentru WordPress aveți nevoie de ochi și ochi. Da, motorul este liber, în același timp profesionist și pur și simplu agitat, dar excesele sunt toate rele, nu, nu, și da, ele alunecă. Aici. " Și de această dată, privirea se prăbușește pe "ceva nou". Au fost trei linii de cod (sau mai degrabă trei hyperlink-uri de servicii) din nou în antetul paginii generate de WordPress:

În plus, a existat, de asemenea, un bloc foarte vizibil în codul sursă:

Aceasta este opțiunea de deconectare completă a suportului Emoji în WordPress. Vrei să pleci în panoul de administrare. Totul, după care a venit un sentiment plăcut de curățenie a codului de la altfel.

Toți au primit satisfacția de la soluția cel puțin parțială a problemei cu puritatea codului sursă și au continuat să se angajeze în rutină (scriind articole și alte prostii).

Cum a ajuns conștiința

Cu toate acestea, a doua zi, o îndoială a căzut în - ceva cu mult timp în urmă nu au existat bug-uri. Se pare că am lucrat cu site-ul pentru o perioadă lungă de timp, iar 502 nu apare în zona administratorului. Credința în miracol nu a fost cu mâna, pentru că deja de zece ori a început să sărbătorească victoria, iar următoarea învățătură mi-a adus înapoi pe pământ.

Cu toate acestea, după ce am așteptat un pic în timpul care a amintit atunci când caută soluții pentru a elimina suportul emoji amintiți-vă că acest cod a apărut în WordPress începând cu versiunea 4.2, și, de fapt, a ieșit doar în primăvară, când am început, și necazuri. Este probabil ca această actualizare la următoarea versiune de WordPress și a fost cauza bug-ul cu încărcare mare ocazional.

În orice caz, în funcție de momentul și de faptul că problema nu se manifestă după eliminarea codului de suport Emoji, a fost posibil să se tragă anumite concluzii. Le-am făcut și am scris acest post. Dacă problema apare din nou, apare un mic P.S. cu regrete despre timpul pierdut (citiți și scriu).

Decizia sa dovedit a fi foarte ciudată, cel puțin mă uit la clopotnița mea, care este foarte joasă în planul mental. Unde este logica? Nu știu, dar totuși frumos că, chiar dacă accidental, dar ma chinuit de ceva timp incidentul tehnic mai mult sau mai puțin rezolvat cu succes. Pentru asta, permiteți-mi să plec. Vă mulțumesc pentru atenția dvs. și din nou cu sărbătorile următoare.

Mult noroc pentru tine! Ne vedem în curând pe paginile blogului KtoNaNovenkogo.ru

Trimiteți-le prietenilor: