A wordpress blog által létrehozott nagy terhelés a szerveren és rendkívül kínos megoldás erre a problémára,

A WordPress blog által generált nagy terhelés a kiszolgálón, és rendkívül kínos megoldás erre a problémára

Helló, kedves olvasó a blog KtoNaNovenkogo.ru. C Az ünnepek, amelyek eljöttek!

Ebben az időintervallumban (kb. Fél óra alatt) az admin panel 502 hibát ad ki, de a látogatók számára a webhely elérhető, de az oldalak meglehetősen lassan (5-15 másodpercig) nyílnak meg. Ha a blog gyorsítótárát nem használták fel, akkor 502 hibát is felmutattak. Ez csak a szerver kétszeres újraindítását támogatja, vagy egy unalmas várakozást, amíg mindent megold.

Általánosságban elmondható, hogy az Infobox támogatja ezeket a hónapokat alaposan megkínozva (kis brosúrát közzé lehet tenni levelezéssel). Az alábbiakban ezeket a lehetőségeket ki ezt a kellemetlen helyzetet, ami már kipróbált, jól írom le, az abszurd helyzet, hogy részesültek a piszkos helyzetekben, mint például hogyan megszüntetésére (vagy legalábbis a múltban nem vette figyelembe a három nap alatt, de ha még mindig jön ki, akkor én is leiratkozni majd a remények összeomlásáról).

Epizódszerűen a WordPress terhelése a szerveren túl

Hogy kezdődött minden, nem emlékszem pontosan. Csak emlékszem, hogy nem sikerült bármilyen kötelező vagy logikus következtetést levonni. Általánosságban elmondható, hogy minden hirtelen kezdődött, és az okokat nem lehetett azonosítani. Mivel még nem sokáig, számos vírusom ellen küzdöttem. akkor először a probléma megjelenése után vétkezett azért, mert megtörte (vagy nem teljesen tisztította meg a kagylókat és más kagylókat). Ezért a virtuális dedikált szerver átkerült minden helyre, kivéve kettő, de a helyzet nem változott.

Nem volt nyilvánvaló oka, úgyhogy úgy döntöttem, hogy valaki beadható. Magát beadására szerverek Van Boom Boom (Félek, hogy ez esetben is), ezért megkérdeztem tehpodderzhu infobox ebben a témában nekem válaszolni semmit, bár nem szükséges ez a mászás, mert nincs rendszeres megosztott hosting és virtuális dedikált szerver, ahol már én vagyok a tulajdonos-mester és a technikai támogatás, kivéve, hogy csak a fogadó gépre válaszol, ahol a szerver fizikailag található.

Azonban, miután a hagyományos „nem kell, de ez nem” srácok a tech support azt mondták, hogy látszólag nincs DDOS (bár bizonyos IP-szűrés agresszív még mindig beállítva a biztonság kedvéért). A terhelést, véleményük szerint, a webhely maga termeli. Néhány év alatt még mindig nagyon megtámadtak, és csak a CloudFlare segített megvédeni magam (hála neki).

Megmondtam nekik, hogy normál módban a terhelés rendkívül alacsony, mert mindkét WordPress bloghoz Hyper Cache plug-in van, 10 napos frissítési idővel a gyorsítótárazott oldalakon. Valójában a Parallels-ban, amelyet az Infoboxban használnak. van egy aljzat, ahol a processzor és a memória terhelése valós időben figyelhető meg. Általában van egy nagyon idealisztikus kép:

De naponta többször is ezek az értékek 100% -ra emelkednek (a nagyon gágás akkor kezdődik, amikor a memória mindössze 100-os kalapáccsal kezdődik), és a helyszín még a látogatók közül is elkezd kanyarodni. A technikai segítségnyújtás egész ideje alatt a fellebbezésemre, amit valami próbáltam kínálni, megfigyelte a kiszolgálót néhány napig, és nem vette észre semmi különöset, ami befolyásolható és "mindannyiunk számára jó".

Amit emlékszem:

1. Minden irányban megváltozott a kapcsolatok maximális számának értéke (és nem értette, hogy mi az), de mindehhez hiába. Véleményem szerint még a szám növekedésével a látogatók nagy terhelés idején még rosszabb helyszíne volt.
2. Megnöveltem a díjcsomagot (néhány héten teszt üzemmódban - nem számítanak fel további díjat) a Linux VPS-2048-tól a 4 gig RAM-ig és dupláztam meg a processzor teljesítményét. Paradox módon, de a 100% -os terheléssel járó hibák nemcsak maradtak, hanem a webhely látogatóinak szinte teljes hozzáférhetetlenségéhez is vezetett (nem a gyorsítótárazás miatt), mert az oldalak egy percre nyitottak. Tehát mindent visszavettek.
3. Fordított egy normál virtuális szerver (például egy konténer) a felhőbe. Semmi sem változott, kivéve, hogy a kiszolgáló túlterhelése ebben a módban jelentősen hosszabb lett. Ezért mindent visszaadtunk mindent.

Már elkezdtem gondolkodni a saját lelkesedéssel, ami ennek a bajnak az oka lehet. Megpróbáltam játszani a Hyper Kesha beállításaival - a letérés nélküli gyorsítótárazással, még mindig néhány érthetetlen me kullancs kísérletekkel. By the way, útközben, készítettem egy reaktív design a blog, és sikerült befejezni az támogatást az InfoBox, hogy hozzanak fel a nginx cache a statikus elemek a felhasználók böngészők. De mindez várhatóan nem okozott semmiféle előrehaladást a probléma megoldásában a kiszolgálón egy epizodikusan nagy terheléssel.

A francba, az előző bekezdés írása közben eszébe jutott, hogy ebben az irányban már gondoltam: Hogyan védheti webhelye admin területét a hackeléstől? és ez nem eredményezte a várt eredményt sem. Kiderült, hogy már átmentem a második fordulóban. Attól tartok, különben valamilyen oknál fogva, mert hozzáférést kell adnom az oldalhoz, és ez hülyeség. A srácok a tárhelyről azt mondják, hogy nincs időnk, még akkor sem, ha nekem időt és erőfeszítést fizetnék nekik.

Tulajdonképpen annak a ténynek köszönhető, hogy miután kipróbáltam minden volt tudtam volna képzelni, nekem, vagy azok, akik erről a témáról az interneten (a legjobb én korlátozott szellemi kapacitás, természetesen), hogy hisz a „csoda” Azt állítani, és a szokásos módon teljesen váratlanul jött.

Hogyan lehetett megoldani a problémát (remélem, hogy végre)

Mindez azzal kezdődött, hogy néhány napja valami ihletett, hogy megnézzem a blogom egyik oldalának forráskódját. Ez nagyon hasznos, mert a fejlécben (a Head tagek között) a WordPress rossz szokása teljesen felesleges metatagok és szolgáltatási kapcsolatok kiküszöbölésére szolgál. ami csökkenti a keresőmotorok arányát a helyszínre.

Például nem kell sokáig járni - nemrégiben felfedezte, hogy a haj a végében áll. Az észleléséről és eltávolításáról még egy külön bejegyzés is írta (bár a téma már régóta felszínre került, de nem vettem figyelembe komolyan) - Az All in One SEO Pack és annak megoldása.

Általánosságban a WordPress-nek szüksége van a szemekre és a szemekre. Igen, a motor szabad, ugyanakkor professzionális és egyszerűen könyörtelen, de a feleslegesek mind rosszak, nem, nem, és igen, csúsznak. Itt. Ezúttal a tekintet "valami újdonságra" került. Három sornyi kódot (vagyis három szolgáltatási hiperlinket), a WordPress által generált oldal fejlécében ismét:

Ezenkívül a forráskódban is nagyon feltűnő blokk volt:

Ez a lehetőség az Emoji támogatás legteljesebb lekapcsolására a WordPress-ben. Szeretné elhagyni az admin panelben. Minden, miután a kódex tisztaságát kellemesen érezte másképp.

Mindegyik megkapta a probléma legalább részleges megoldását a forráskód tisztaságával, és továbbra is rutinszerűen dolgozott (írásos cikkeket és egyéb értelmetlen dolgokat).

Hogyan jött a tudat

A következő napon azonban kétség merült fel - valami régen nem volt hiba. Úgy tűnik, hogy hosszú ideje dolgoztam a webhelyen, és az 502 nem jelenik meg az admin területen. A csoda csodája nem volt a kezével, mert már tízszer kezdte ünnepelni a győzelmet, és a következő zavenson visszahozta a földre.

Azonban várakozás után egy kicsit közben eszébe jutott, hogy ha keres megoldást, hogy távolítsa el támogatást Emoji megjegyezni, hogy ez a kód megjelent WordPress verzió óta 4.2, és valójában ez kiment csak a tavasszal, amikor elkezdtem, és a bajok. Valószínűleg ez volt a WordPress frissítése a következő verzió előtt, amely egy epizodikusan nagy terhelésű bug megjelenését okozta.

Mindenesetre az időzítés és az a tény, hogy a probléma nem jelentkezik az Emoji támogatási kód eltávolítása után, lehetséges volt bizonyos következtetések levonása. Én készítettem és írták ezt a hozzászólást. Ha a probléma újra megjelenik, megjelenik egy kissé alacsonyabb P.S. sajnálja az elvesztegetett időt (olvasol és írok).

A döntés keménynek bizonyult, legalább a harangtoronyra nézve, ami nagyon alacsony a mentális síkon. Hol van a logika? Nem tudom, de még mindig kedves, még ha véletlenül is, de eléggé meggyötört a technikai incidens többé-kevésbé sikeres megoldása. Ehhez engedjék meg, hogy kiüljek. Köszönjük figyelmét és újra az elkövetkező ünnepeket.

Sok szerencsét neked! Hamarosan találkozunk a blog KtoNaNovenkogo.ru oldalain