Domov › Tarify › Překročení limitu CPU – snížení zátěže hostingu. Jaké metody jsem zkoušel bojovat proti kritické zátěži CPU? Jak došlo k realizaci

Překročení limitu CPU – snížení zátěže hostingu. Jaké metody jsem zkoušel bojovat proti kritické zátěži CPU? Jak došlo k realizaci

Dobrý den, milí čtenáři tohoto blogu. Veselé svátky!

Během této doby (asi půl hodiny) zobrazí administrátorský panel chybu 502, a přestože je web návštěvníkům přístupný, stránky se otevírají poměrně pomalu (od 5 do 15 sekund). Pokud by se na blogu nepoužívalo ukládání do mezipaměti, vypsali by chybu 502. Jediná věc, která pomáhá, je buď dvakrát restartovat server, nebo hloupě čekat, až se vše samo vyřeší.

Navíc v době vysoké zátěže nefunguje vyhledávání na stránkách a neodesílají se komentáře, ale to jsou drobnosti. Obecně je situace, jak chápete, nepříjemná, i když ne kritická. Zdá se to tolerovatelné, ale je to nepříjemné – hrozné.

Obecně platí, že WordPress vyžaduje oko a oko. Ano, motor je zdarma, zároveň profesionální a prostě šílený, ale všelijaké špatné excesy ne, ne, a dokonce i proklouznout. Zde. Tentokrát mě také zaujalo „něco nového“. Byly to tři řádky kódu (nebo spíše tři hypertextové odkazy na služby) opět v záhlaví stránky generované WordPressem:

Po malém googlování jsem si uvědomil, že „toto“ se objevilo ve WordPressu 4.4 a bylo k něčemu potřeba (stále mám mlhavou představu o čem – pokud víte, vysvětlete). Protože Nedávno se objevilo „toto“, nebylo možné vygooglit mnoho receptů na odstranění a to, co bylo nalezeno, fungovalo nějak křivě (první odkaz byl smazán, ale další dva ne a začaly vést na stejnou stránku, kód z nichž bylo otevřeno).

Obecně jsem se rozhodl toto prozatím odložit, dokud se situace nevyjasní a neobjeví se recepty na „odříznutí zbytečných procesů“. Ano, znovu, pokud je to k tématu, řekněte mi, protože tyto odkazy mě opravdu dráždí. Alespoň k čemu jsou potřeba a zda jsou pro propagaci blogu destruktivní. Ale tady jsem se prozatím stáhl.

Kromě toho byl ve zdrojovém kódu také velmi patrný blok:

Pamatuji si, že tam předtím byl. Pamatuji si, že jsem prý už dříve věděl, odkud pochází, ale teď, ať jsem se snažil sebevíc, nemohl jsem si vzpomenout a ani se nedobrat toho, odkud se tato „kráska“ v záhlaví blogu vzala (byla přítomna i na jiných blozích ). V duchu jsem trochu zaváhal a zíral na slovo emoji v kódu. Nedávno jsem psal. Trochu jsem googlil a byl jsem přesvědčen, že ano, tento kód pomáhá zobrazovat stejné emotikony emotikony na stránkách WordPress.

Vzhledem k tomu, že emoji smajlíky zobrazuji pouze ve dvou třech článcích, rozhodl jsem se odstranit tento nešvar, na který jsem hledal recept na internetu. Řešením, jako vždy v takových případech, bylo přidat filtry ze složky motivů WordPress, kterou používáte. Obecně v něm najdeme koncový bod nějaké funkce (středník) a přidáme několik řádků nesrozumitelného (pro mě), ale docela fungujícího kódu:

Remove_action("wp_head", "print_emoji_detection_script", 7); remove_action("admin_print_scripts", "print_emoji_detection_script"); remove_action("wp_print_styles", "print_emoji_styles"); remove_action("admin_print_styles", "print_emoji_styles"); remove_filter("the_content_feed", "wp_staticize_emoji"); remove_filter("comment_text_rss", "wp_staticize_emoji"); remove_filter("wp_mail", "wp_staticize_emoji_for_email");

Toto je nejúplnější možnost, jak zakázat podporu emotikonů ve WordPressu. Pokud chcete, nechte to v administračním panelu. To je vše, po tomto byl příjemný pocit čistoty kódu od nejrůznějších věcí.

Na stránkách, kde jsem používal emotikony, jsem musel text mírně upravit. Jednoduše jsem tyto články otevřel k úpravě v admin panelu a hned na začátku (v Html editoru, ne ve vizuálním) přidal právě tento kód, který jsem odstranil z hlavičky všech stránek:

window._wpemojiSettings = ("baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":"..min.js?ver=4.4") );

img.wp-smiley, img.emoji ( display: inline !důležité; ohraničení: žádné !důležité; stínovaný rámeček: žádné !důležité; výška: 1em !důležité; šířka: 1em !důležité; okraj: 0,07em !důležité; vertikální zarovnání: -0.1em !důležité pozadí: žádné !důležité: 0 !důležité )

To je vše, dostal jsem zadostiučinění z alespoň částečného vyřešení problému s čistotou zdrojového kódu a pokračoval ve své rutině (psaní článků a jiných nesmyslů).

Jak došlo k realizaci

Každopádně na základě načasování a toho, že se problém po odstranění kódu podpory emotikonů neobjeví, by se daly vyvodit určité závěry. Udělal jsem je a napsal tento příspěvek. Pokud se problém objeví znovu, objeví se P.S. s lítostí nad ztraceným časem (vámi při čtení a mnou při psaní).

Rozhodnutí se ukázalo být opravdu trapné, alespoň z mého velmi nízkého mentálního hlediska. Kde je logika? Nevím, ale i tak je fajn, že se, byť náhodou, technický incident, který mě docela dlouho trápil, víceméně úspěšně vyřešil. Dovolte mi proto se rozloučit. Děkuji za pozornost a ještě jednou krásné svátky.

Ať se vám daří! Brzy se uvidíme na stránkách blogu

Na další videa se můžete podívat na ");">

Mohlo by vás to zajímat

Levé menu v administračním panelu WordPressu zmizelo po aktualizaci Kde stáhnout WordPress – pouze z oficiálního webu wordpress.org
Instalace WordPressu v detailech a obrázcích, přihlášení do oblasti WP admin a změna hesla Prázdná stránka při prohlížení velkých příspěvků (článků) ve WordPressu
Snížení spotřeby paměti ve WordPressu při vytváření stránek - plugin WPLANG Lite pro nahrazení lokalizačního souboru
Jak se přihlásit do administrační oblasti WordPress a změnit přihlašovací jméno a heslo správce, které jste dostali při instalaci motoru

Zdravím všechny čtenáře tohoto blogu. Dříve nebo později každý autor blogu WordPress čelí otázce - Jak snížit zatížení serveru? Někteří lidé na to předem myslí (mají znalosti), zatímco jiní (nováčci) začnou od hostitele dostávat dopisy „štěstí“. O to smutnější je, když se blog začne pravidelně vypínat kvůli překročení limitů.

Podobný příběh se mi stal v roce 2010. Návštěvnost mého prvního blogu se konečně objevila, pomalu a jistě rostla. Radost na sebe nenechala dlouho čekat. Brzy se mi stalo přesně to, co jsem popsal výše.

Všechno je úžasné, líbilo se mi všechno, kromě ceny - 30 $. Tenkrát to stálo přesně tolik.

Miliony z mého blogu neplynuly a já prošel kolem a nechal použití možnosti ukládání do mezipaměti u MaxCache na později. Můj problém se zvýšenou zátěží serveru jsem vyřešil jiným způsobem. Po další nabídce na změnu tarifu jsem změnil hosting.

A pak přišel den, kdy jsem poprvé místo jednoho z cachovacích pluginů WordPress nainstaloval MaxCache. V roce 2013, když jsem psal blog o satelitní televizi, rozhodl jsem se ji použít pro ukládání blogu do mezipaměti.

Dva dny jsem používal bezplatnou odlehčenou verzi, přesvědčil jsem se, že jdu správnou cestou a koupil jsem si placenou plnou verzi.

Nyní, když pro někoho vytvořím blog nebo spustím něco vlastního, bez váhání nainstaluji MaxCache pro ukládání blogu do mezipaměti.

Jak vidíte, tento blog slouží také ke snížení zátěže serveru. V současné době je cena MaxCache 10 $.

Algoritmus práce - jak MaxCache snižuje zatížení serveru

Pro přehlednost jsem před použitím cachovacího skriptu a po připojení MaxCache pořídil snímky obrazovky ze zápatí hlavní stránky webu vytvořeného zatížení na serveru.

Pro ty, kteří nevědí, jak zobrazit informace o zatížení serveru, počtu požadavků a době generování stránky, vám to řeknu. Vše se dělá velmi jednoduše.

Otevřete soubor footer.php svého motivu a před uzavírací značku vložte následující kód.

MySQL dotazy Rychlost generování stránekBez skriptu 11,68 MB 31 0,68S MaxCache 0,82 MB 0 0,00025

Zatížení serveru se snížilo více než 14krát!

Počet volání databáze při použití skriptu je nula!

Rychlost generování stránek se zvýšila 2720krát!

Čísla jsou dobrá, ale i bez nich je rychlejší práce blogu vizuálně patrná. Stránky se otevírají mnohem veseleji.

Jak funguje skript pro ukládání do mezipaměti? Uživatel, který navštívil váš web, otevřel stránku, která ho zajímala, MaxCache ji okamžitě umístil jako statickou stránku do složky Cache. Nyní je dán uživatelům z této složky bez dotazů na databázi a bez dodatečného zatížení serveru.

Mezipaměť stránky se resetuje každé 4 hodiny. V případě potřeby můžete zadat vlastní nastavení.

Skript je dodáván s pluginem, který nám po aktivaci umožňuje zobrazit aktuální verze stránek bez mezipaměti, když jsme přihlášeni a pracujeme na panelu administrace blogu. Pro návštěvníky v tuto chvíli, podle očekávání, je skript načte z mezipaměti.

Je možné povolit kompresi provozu gzip. Zvyšuje rychlost načítání „těžkých“ stránek. Povolení komprese gzip zvyšuje zatížení serveru. Zda tuto funkci povolit nebo ne, je třeba rozhodnout na základě dostupnosti limitů zatížení CPU. Před povolením komprese gzip musíte u svého hostitele zkontrolovat, zda tuto funkci server podporuje.

Při psaní článků často používám obrázky a screenshoty na stránkách. Sice je stlačuji na maximum, ale váha, která vyjde, není vždy taková, jakou bych si přál. Mám povolenou kompresi gzip.

Výsledky pro hlavní stránku byly následující.

Před kompresí byla váha mé stránky 23,7 KB, po kompresi 6,5 KB. Úspora činila 72,4 %. Jak se říká - Bez komentáře. Testovací služba komprese gzip se nachází na této adrese - http://www.whatsmyip.org/http_compression/.

V samostatném souboru v nastavení skriptu můžete také určit seznam stránek se zákazem ukládání do mezipaměti. Po vydání nové verze skriptu je aktualizace pro všechny klienty zdarma.

Na závěr článku bych rád zdůraznil, že se mi líbí přístup autora scénáře k jeho prodeji. Po zaplacení MaxCache obdrží kupující verzi skriptu Lite. Tato verze má omezenou funkčnost. Od plné verze se liší tím, že se cache neresetuje automaticky. To znamená, že oříznutá verze funguje téměř stejně jako plná. Na testování autor vyčleňuje dva týdny času. Dále buď odmítnete nákup a autor vám vrátí peníze, nebo zašlete žádost o plnou verzi MaxCache.

Při nákupu tohoto zařízení, abych snížil zatížení serveru, jsem požádal, aby mi byla okamžitě zaslána plná verze, protože jsem byl již dlouho obeznámen s prací skriptu a byl jsem s jeho prací spokojen. MaxCache je ideálním řešením pro blog WordPress.

Ahoj. Po pokusech o hacknutí jednoho z mých stránek jsem o tom psal v článku, vše bylo tak nějak v klidu, zatížení hostingu se stalo normální a nebyly žádné problémy. Ale v jednu krásnou chvíli jsem šel na panel ihc.ru a otevřel záložku „Načíst“, abych viděl, jak to tam chodí, a abych byl upřímný, byl jsem trochu vyděšený. Zatížení CPU už přesáhlo povolenou mez a to bylo teprve ráno.

Okamžitě jsem začal analyzovat, co jsem na webu v poslední době dělal, ale jak se ukázalo, nic jsem nezměnil. Díval jsem se na návštěvnost, ta byla normální, tedy nezvyšovala se a nemohla v žádném případě vést ke zvýšení zátěže a to tak prudké.

Okamžitě jsem si myslel, že hosting teď mé stránky vypne. V tomto panelu mám pouze jeden navštívený web, přibližně 10 000 zobrazení stránek za den, to není málo na sdílený hosting za 400 rublů měsíčně. Ale zátěž byla vždy přibližně uprostřed, pokud je na CPU přijatelných 120, tak jsem měl 70.

Posadil jsem se, abych napsal dopis podpoře ihc a vysvětlil situaci. Odpověď přišla velmi rychle, jako vždy. Psali, že stránky nikdo nevypne pro jednorázové zvýšení zátěže, huuu, uklidňovali mě. Poukázali také na stránku, která vytváří velké zatížení, a uvedli jednu IP adresu, která se chová velmi podivně a na stránku odesílá mnoho požadavků. Také nám doporučili analyzovat soubor protokolu domain_access.log.

Okamžitě jsem zablokoval IP adresu, kterou uvedli v souboru .htaccess v kořenovém adresáři webu. Jednoduše přidáte řádek deny z **.***.***.** . A začal jsem očekávat, že tohle všechno skončí a zátěž hostingu klesne.

Je jen víkend, jel jsem na dovolenou. Jak se ale ukázalo, druhý den se zátěž ještě zvýšila. Znovu jsem napsal na podporu a řekli mi, že potřebuji analyzovat protokoly. Pracoval jsem přes takový internet, že pro mě bylo obtížné je stáhnout. Navíc už jsem se díval do těchto logů a nic jsem tam nepochopil.

Druhý den, včera, se zátěž CPU na hostingu ještě zvýšila, z přípustných 120 na 300. A já se rozhodl, že těmto logům ještě potřebuji porozumět a začal jsem se dívat na soubor domain_access.log, který jsem si stáhl přes FTP z hostingu. Tak velký soubor, otevřít ho pomocí poznámkového bloku, bylo těžké pochopit. Tady mi přišel vhod můj oblíbený Notepad++, vše se tam zobrazovalo na novém řádku, zkrátka vše bylo jak má být.

Dlouho jsem se na tento soubor díval, zobrazuje IP adresu, čas požadavku, typ požadavku atd. Podíval jsem se na něj a zavřel. Dnes ráno jsem se probudil a šel se podívat, co se děje s nákladem, už překračoval povolenou mez. Rozhodl jsem se, že na to musím přijít. Znovu jsem otevřel protokol serveru a začal si ho pečlivě prohlížet. Všiml jsem si několika IP, ze kterých byly požadavky na stránku velmi aktivní i v noci. Navíc za sekundu může být více než 10 požadavků na stejnou stránku webu. A takových žádostí bylo hodně. Zablokoval jsem všechny IP, které mi v .htaccess připadaly divné.

Zrovna dnes ráno jsem obdržel dopis, že zatížení hostingu bylo několik dní v řadě zvýšeno. Odpověděl jsem jim, popsal situaci, že jsem IP zablokoval a počkám na výsledek. V reakci na to podpora poslala seznam pěti IP adres, které podle jejich názoru vytvářejí velké zatížení, se téměř shodovaly :).

Po zablokování těchto IP se zdálo, že se zátěž ustálila. V noci, kdy ještě nebyly blokované IP, bylo zatížení patrné, ale tento den se zdá být vše v pořádku.

No a zítra bude možné vyvodit závěry, zda blokování těchto IP adres pomohlo nebo ne. Nyní opravdu nechci měnit tarif; existuje prémie za 1 000 rublů měsíčně. Jenže při takové zátěži ani tento tarif nemusí stačit. Nicméně počkám do zítřka a něco se rozhodnu.

Pokud jde o hostitele ihc.ru v této věci, zdá se mi, že jsou skvělé. Za prvé, web s deseti tisíci zhlédnutími denně na virtuálním hostingu za 400 rublů měsíčně, myslím, že je to v pohodě. Moc děkuji za pomoc při řešení problémů s načítáním a hledáním těchto IP.

Téměř všechny mé weby běží na custom enginech, ale donedávna jeden z nich ještě běžel na dnes tak rozšířeném WordPressu. Faktem je, že wordpress byl původně nainstalován kvůli snadnému použití administračního panelu osobou provozující tento web (ne mnou). Ale po vydání řady verze 2.8 jsem si uvědomil, že už to tak není...

Zátěž na hosting se výrazně zvýšila, s počtem zásahů, dejme tomu 500-600, Wordpress již třikrát překročil limity na využití zdrojů MySQL, což znamená, že řešení bylo buď v mezipaměti (dost hemoragické, opět ve Wordpressu ), nebo při přechodu na jiný motor.

Vyzkoušel jsem většinu hotových blogových enginů v národních prostředích a došel jsem ke zklamání:
žádný z nich (!), dokonce ani s importem z wordpressu, nemohl poskytnout stejnou CNC strukturu (a ještě více v automatickém, intuitivním režimu), což znamená, že při přechodu na -> 301 přesměruje a není jasné, jaký druh reakce od PS z hlediska stávajících pozic.

Nakonec to dopadlo jako vždy: podíval jsem se na zdroje WordPressu, naimportoval data z existující databáze a napsal malou zdání CMS.

Zátěž: na MySQL klesla v průměru 10krát, na procentech 2krát. Zdá se mi, že z hlediska optimalizace je stále co zlepšovat, ale musíte souhlasit, že i toto je již orientační výsledek!

Závěr z tohoto příspěvku není takový, že by se každý měl hned vrhnout na psaní vlastních skriptů (alespoň myslet na ochranu proti hackingu), ale že byste si před instalací Wordpressu jako enginu blogu měli párkrát rozmyslet, protože později to může být problematické změnit CNC a ještě více adresy stávajících odkazů (pokud samozřejmě nejsou zakoupeny).

15 komentářů

Dobré myšlenky, ale každý je má. Rád bych si přečetl možné řešení problémů s načítáním databáze změnou parametrů motoru

Hlavním směrem významné optimalizace WordPressu je ukládání do mezipaměti na straně serveru. Myslím, že si to můžete přečíst na mnoha jiných blozích. V současné době nemám jediný web postavený na Wordpressu, a proto nemohu popsat řešení problémů s optimalizací.

Na internetu vždy říkali, že VP je snadné, a já tomu věřil, i když ve svém životě používám Drupal. V září jsem pak dostal zákazníka s přáním „přejít z tohoto buggy VP na Drupal“. Ukázalo se následující:
1. Stránka běžela na VPS 500Mhz a 384 snímcích
2. Návštěvnost je asi 1000 návštěv za den.
3. Všechny myslitelné a nepředstavitelné keše jsou zahrnuty.
Celý tento systém neustále padal jednou denně a po zbytek času byl bezbožně pomalý. V důsledku toho začal drsný a pečlivý proces přechodu na Drupal:
1. Všechny materiály byly znovu nataženy.
2. Kde byly adresy URL uspořádány, nechali jsme je tam, kde nebyly uspořádány, vytvořili jsme nové adresy URL, 301 přesměrování na staré.
3. Pohybovali jsme se absolutně bez ztrát. Se stejnou funkčností a na některých místech ještě více.
Nyní zatížení procesoru serveru v nejtěžších okamžicích, kdy dorazí Gosha a Yasha, nepřesahuje 30 procent, s deaktivovaným ukládáním do mezipaměti.
Takže přemýšlejte o Drupalu, není to tak špatné, jak všichni říkají.
Zde je pacient - surlaterre.ru

Nemám nic proti Drupalu, je to dobrý systém. Moje hlavní stížnost je, že moderní motory nemají jednoduchý systém pro přechod z jiného CMS při zachování starého CNC systému.

Pokud vezmeme stejný přenos z VP, pak se stávající modul přenese spolu s adresami URL VP, ale přenesl jsem ho se svým modulem, všechno bylo pro mě trochu jiné

Jestli je ten či onen modul schopen přenést jakýkoliv typ adresy, kterou lze vytvořit pomocí standardních nástrojů Wordpressu, čest a chvála, +1 Drupalu, ale když jsem něco takového hledal mezi motory, nenašel jsem cokoliv, nebo jsem to našel, ale ne vše bylo implementováno.

Obecně mohu říci: „Není nic, co by nebylo přenosné“, pokud je téma zajímavé, pak vítejte na ICQ/mail/Skype. Kontakty na mém webu

Nevím, jak jste nakonfigurovali WordPress, server a mezipaměti. Ale mám weby běžící na WP, které mají na virtuálních strojích 4000 návštěvníků denně a bez problémů. Existují stránky s 10 000 návštěvníky na jedno zaklepání, ale v soukromí. Tam zatížení nepřesahuje ve špičkách 10 %. Takže WP je pořád rockový!

Momentálně se učím MovableType. Navzdory své neobvyklé povaze (používá perl a generuje statický html) je tento CMS velmi lehký a docela funkční. Mnohem rychlejší než WP.

MovableType je dobrý, ale v ruštině je o něm stále málo informací.

Osobně nemohu přijít na to, jaký druh zátěže tam je. Nikdy jsem neměl žádné velké WP projekty a nemohu to sám zkontrolovat. A bez ohledu na to, kde čtu, nic nepochopíte: někteří říkají pravidla wp, jiní říkají, že motor je svinstvo. Obecně jsem nikde neviděl, jakou zátěž a jaké wp vydrží. Zůstává jedna otázka: proč je potom wp v zóně ru na předních pozicích, možná kvůli své jednoduchosti?

Uplynulo období přibližně 30 dnů, v provozu stránky již nejsou žádné problémy a server není příliš vytížen, procesor již není sledován. Nyní bych vám měl říci, jak se mi podařilo vyrovnat se s periodickou vysokou zátěží WordPressu na procesoru a serveru.

Všechno to začalo zcela spontánně a každým dnem byla odezva serveru delší a delší. Pak se v jednom okamžiku na panelu webmastera Yandex objevilo odpovídající kritické oznámení. Ve kterém byla na téměř 40 - 50 stránkách webu uvedena dlouhá odezva serveru. Všechno je v pořádku.

Obsah článku: Vysoká zátěž vytvořená webem WordPress na CPU serveru - hlavní příznaky tohoto problému

Na mých stránkách problém vznikl zcela spontánně a v různých časových obdobích. 100% zatížení CPU serveru bylo způsobeno přechody mezi stránkami webu. Kolem 2. stránky došlo k prudkému skoku ve výkonu procesoru serveru. Rád bych poznamenal, že v tuto chvíli nemá RAM prakticky žádné výkyvy. A počet procesů je zcela zanedbatelný a neměl by tak škodlivě zatěžovat procesor serveru.

Hlavní charakteristické znaky pracovní zátěže, se kterými se mnozí webmasteři setkávají, jsou:

Zvýšení limitu zatížení CPU na hostitelském serveru.
WordPress začal vytvářet nepřijatelné zatížení procesoru.
Špičkové hodnoty, velké přetížení CPU na hostingu.
Dlouhá odezva serveru, proměnná hodnota se pohybuje od 5 do 30 sekund.
K nadměrné zátěži dochází spontánně, v různých časových obdobích.
Web se zpomaluje, stránky se téměř nenačítají nebo tento proces trvá velmi dlouho.
Web se zhroutí na nejvyšší úrovni.
WP vytváří dlouhou odezvu serveru, web není stabilní. Během špičkových rázů CPU pracuje RAM ve svém normálním stabilním režimu.
Počet ovlivněných a provedených procesů během období přepětí je minimální.
Dávkový přístup ke streamování a připojení na nginx nebo Apache jsou minimální.
Tato anomálie se vyskytuje několikrát denně, v různých intervalech. Končí to stejně rychle, jak to začalo.

Přesně to se stalo měsíc na mém webu. Dobrým příkladem by byly následující obrázky:

Jak vidíte, počet zapojených procesů je minimální. RAM je udržována na stabilní hodnotě s přihlédnutím k otevřenému prohlížeči a obrovskému počtu stránek. Ale všechna jádra CPU pracují pod kritickým zatížením a zpočátku není možné vůbec pochopit důvod.

Jaké metody jsem zkoušel bojovat proti kritické zátěži CPU?

Nejčastější je, že jsem se provinil WP pluginy a nedostatkem paměti. I když abych byl upřímný, motor využívá pouze 16 MB paměti z povolených 512 MB, které jsem přidělil. Co jsem vlastně zkusil:

Provedl úplnou aktualizaci Debianu a poté vyčistil celý systém.
Smazáno 99 % uložených revizí databáze na VestaCp.
Dvacetkrát jsem prohledal konfigurační soubory ve VestaCp, zda neobsahují chyby.
Na poštovním serveru Exim jsem našel velké množství systémových protokolů (zcela smazáno).
Zkontroloval jsem stránky na viry (žádné nejsou).
Provedl jsem trasování na stránce, zkontroloval rychlost internetového připojení.
Na webu jsem zakázal ukládání revizí záznamů, nic jiného jsem na webu nedělal. Stránka je z 98 % optimalizována pro její kontrolu.

Po všech provedených krocích nebyl problém vyřešen. Během měsíce pokračovaly skoky a špičkové kritické zatížení WP na procesoru serveru.

V čem přesně byl problém nadměrné zátěže WP na CPU a jak jsem to vyřešil

Problém byla chyba WP Cron. Asi před čtyřmi měsíci jsem nainstaloval plugin, který zabraňuje aktualizaci enginu, témat a pluginů. Prvním voláním, jak tomu rozumím, byly chyby v protokolech serveru webu adresovaných na wp-cron.php. Chyba byla v alokaci paměti pro proces, respektive nedostatečná paměť. Když jsem si na tuto situaci vzpomněl, okamžitě jsem zpozorněl.

Co mi pomohlo:

Nainstaloval jsem si plugin WP Crontrol - plánovač úloh wp cron. Doporučuji vám jej okamžitě nainstalovat, velmi dobré řešení.
Po instalaci jsem viděl obrázek špičkového zatížení přibližně 900 stejných událostí, které, jak jsem pochopil, se týkají obrázků.

Nejjednodušším řešením je resetovat všechny události wp cron do původního stavu, to se provádí ve functions.php. Stačí jej vložit na úplný začátek souboru pod

Oblíbené v kategorii: