Chyba 503 nemusí znamenat, že potřebujete lepší tarif

Dneska se mi stala velice nemilá věc. Můj blog 404M.COM definitivně neustál nápor “návštěvnosti” a spadl. Popravdě se mi chyby 503 začaly objevovat delší dobu. Ze začátku to bylo ještě snesitelné, ale postupem času už to vadilo i návštěvníkům. Přitom mi bylo divné, že VMS od Českého Hostingu nezvládne nápor ani 10 lidí online (měřeno dle Google Analytics). Sice tam mám s ním nějakých dalších 9 domén, ale to jsou v podstatě mrtvé projekty, kam sem tam zavítá nějaký bot. Navíc vše optimalizované. Ale projdeme si to postupně.

Několik posledních týdnů se mi na 404M začaly objevovat chyby 503 a všechno jelo tak nějak pomalu. Připisoval jsem to větší návštěvnosti a uvažoval o přikoupení tarifu. Co si budeme namlouvat mám tam VMS za 170 CZK, které má k dispozici 512 MB paměti z toho většinu schroupe systém. Takže jsem s tím tak nějak i počítal.

Dneska (7.6.2013) odpoledne to tak nějak definitivně spadlo. Házelo to 503ky pořád. Připisoval jsem to publikování článku Vaše .cz domény na prodej XII. Podle Google Analytics tam v ten okamžik byly jednotky lidí.

Dorazil mi informační email z Českého Hostingu na vyčerpání paměti. Což hodnotím velice kladně. Není nic horšího, než když vám nefunguje hosting a nevíte o tom. Moderní hostingové společnosti by vám měli dát okamžitě vědět, protože mnoho firem na funkčních webech stojí. Takže tady Český Hosting jednoznačně splnil normu pro hosting 21. století a získává zeleného bluďišťáka. Přikládám jej k textu, pokud by se chtěli nechat inspirovat společnosti, které takto nekonají.

Email z Českého hostingu upozorňující na nedostatek paměti
Email z Českého hostingu upozorňující na nedostatek paměti

Smutně jsem si postěžoval na Twitter a připravil se na zaplacení dalších 512 MB paměti. Obecně u VPS skok z 512, kde vám kus sežere systém, na 1024 je velice znatelný. Vím to z Angel Hostingu, kde mi VMS s 1024 MB utáhlo nehorázné věci. Následovala trochu nepříjemná výměna názorů na Twitter s účtem @ceskyhosting.

Přiznám se, že na základě této reakce jsem se trochu, dejme tomu “trucovitě zamyslel” a začal pochybovat. Mám screenshot jak to na tom samém VMS utáhlo bez problémů 28 lidí, přece nejsem blbej a těch deset + nula nula nic na dalších doménách to nemůže takto shazovat. Chyba bude někde jinde!

Začal jsem zvažovat jednotlivé varianty. Tedy chyba cachovaní, nějaká smyčka ve skriptech, hacknutý web a pár dalších spíše sci-fi variant. Napadlo mě že podobně jako u AH by stálo za to restartovat server. Ostatně vypnout a zapnout už vyřešilo dočasně spoustu problémů. Tuto možnost jsem u ČH nenašel. Ale narazil jsem na statistiky a ty ukazovali opravdu podivnou zátěž + spawování, 94% zátěže generovala doména 404m.com. Tehdy jsem začal zvažovat možnost brute force útoku na můj WP. Ostatně když o tom napíšete den předtím článek, tak aby vás to nenapadlo.

Aby jsem měl jistotu, tak jsem musel web pro lidi vypnout a přitom mít ke všemu přístup. Administrace navíc házela 503. Zvolil jsem tedy metodu úpravy .htaccess a přidal jsem do něj:

<Limit GET POST>
order deny,allow
deny from all
allow from 81.200.55.227
</Limit>

Tím byl web přístupný jen pro mě (mojí IP), což jsem si záhy ověřil prostřednictvím Google Analytics. Jenomže nápor na server neustal. Prošel jsem všechny domény, co tam mám. Ukázalo se že na každé je 0 lidí online. Takže na žádné veřejné stránce, kde je Google Analytics nikdo nebyl, ale server cucal paměť odkud se dalo.

Takže jsem se soustředil na problém někdo mi brute forcuje můj blogísek! Vyměnil jsem tam pár pluginů na bezpečnost. Potřeboval jsem jen log. Sice mám logovací skript naprogramovaný, ale ne pro tento účel, takže jsem vzal za vděk Simple Login Log. No a … nic! Tady už jsem si řekl, že bez technické podpory to nepůjde. Potřebuju zjistit kdo mi DoSuje který skript, aby jsem tomu mohl nějak zabránit. Bez logů to prostě nedám.

Zvolil jsem online chat, protože je na tohle nejlepší. Řešení se může protáhnout i na několik desítek minut, než se všechno odzkouší a navíc počítám s nějakým tím CTRL+C a CTRL+V kusů logů. Tohle je po telefonu nereálné a po emailů moc na dlouho. Na operátora jsem čekal nějakých pět minut, takže jsem si dopředu připravil texty a zesumarizoval myšlenky. Bylo mi jasné kam mě bude při chybě 503 tlačit (standardní problém) ale ze zkušenosti vím, že se stačí chovat slušně a dát jasně najevo co chci.

Vesměs to tak i probíhalo. Když jsem řekl, že se může jednat o brute force útok, koukl do logů a sdělil mi, že tam je velké množství požadavků z nějaké domény 80legs.com. Říkám si super. Chtěl jsem jej poprosit zdali by s tím mohl něco udělat na serverové úrovni, ale řekl mi že je to z více IP adres a nic s tím neudělá a je to na mě. Říkám není problém, jen potřebuju ten log. Řekl, že si jej můžu aktivovat sám a nasměřoval mě kde. Poděkoval jsem a nastal čas to řešit.

Po aktivaci záznamů, se mi za nějakých pět minut vygeneroval zhruba megabajtový soubor. Za 20 minut 3876 požadavků, skoro vše od toho šmejda. Problém byly ty IP adresy. Prakticky jediná možnost bylo všechny naházet do .htaccess a zakázat jim přístup. Jenomže ta společnost co to provozuje má k dispozici 50 tisíc strojů. Jedná se o nějaký privátní crawler. Naštěstí se hlásí jako:

"Mozilla/5.0 (compatible; 008/0.85; http://www.80legs.com/webcrawler.html) Gecko/2008032620"

Takže s trochou snahy a rad se mi podařilo dát do .htaccess následující:

<Limit GET POST>
BrowserMatchNoCase 80legs 80legs
order allow,deny
deny from env=80legs
allow from all
</Limit>

Zkusil jsem pustit návštěvníky na 404M.COM a vše se rozjelo neuvěřitelně rychle. Zkusil jsem oznámení spuštění na Twitter a přišlo v jeden okamžik 15 nových lidí. Vše bez jediného záseku. Navíc bylo před šestou, kdy začínala soutěž o 5 kódu na .eu domény.

Závěr

Přiznám se bez mučení, že když jsem viděl výsledek byl jsem hodně naštvaný na reakci ČH na Twitter a tento článek jsem chtěl psát v jiném duchu (emoce, bez racionálního důvodu). Místo toho jsem si šel ale zaběhat, vychladnul a zkusil jej napsat neutrálně, což se myslím i povedlo. Bohužel nemám screenshot diskuze s technickou podporou, ale osobně si myslím, že tam nic špatného nebylo. Samozřejmě jsem dostal menší “přednášku” že současná varianta nestačí a bude zřejmě potřeba větší. Ale to čert vem.

Teď popravdě nevím jak se k tomu postavit. Jako BFU by jsem si asi koupil větší tarif, který by možná tu zátěž utáhl. Nevím. Ten robot tam pral v průměru 4 požadavky za vteřinu. Možná i víc, pokud by to server stíhal. A to mě na tom asi nejvíc štve. V dobré víře by jsem podlehl masovému řešení, které nebylo vlastně potřeba.

Neodpustím si otázku na odbornou veřejnost. Dá se těmto věcem nějak předcházet, aby se to neopakovalo? Je moje provizorní záplata vůbec řešením?


Jak bude reklama vypadat?
-
Nechceš zde reklamu napořád jen za 60 Kč?
Zobrazit formulář pro nákup

17 komentářů

  1. Zajímavá skušenost, kterou nikomu nepřeju… zaujala mně věta: “Mám screenshot jak to na tom samém VMS utáhlo bez problémů 28 lidí”.Znamená to, jestli to dobře chápu, že na tvém webu bylo 28 lidí současně online a web nespadl? Protože mě přijde, že 28 lidí online není sakra žádná velká zátěž, proč by ten web měl padat? To musí s přehledem utáhnout i těch 512 RAM. Což vlasně dokazuje i to, že ten bot ti tam šmejdil v síle nějakých 3000 lidí a až pak to spadlo. Jen mne zaujala ta tvá argumentace (nebo obava), že to přece již dříve vydrželo 28 lidí. Možná jsem to špatně pochopil, ale píšu to vlastně proto, že mě napadla otázka: kolik by to těch online lidí mělo vlastně ustát (podle vyjádření hostingu a podle tvého názoru)? Protože já si myslím, že minimálně to musí dát bez problému o řád výše lidí současně, než co jsi uvedl v té citované větě (28), ale osobní zkušenost s tímto hostingem nemám, jen mi to přijde, no…

    1. pet: těch 28 lidí jsem na tom v jeden okamžik viděl maximálně a nějak extra se to nesekalo, takže počítám že vydrží něco víc. Ale nedělám si zase moc velké iluze. On se špatně ten výkon dá odhadovat zvláště u WordPress. Hlavně jsem to použil jako porovnání.

  2. Taky mě to překvapuje…žil jsem v tom, že normální hosting (třeba od wedosu) musí dát stovky lidí online bez problémů. To je zajímavé…zase jsem chytřejší 🙂

    1. petr: tak ono je otázkou jak měřit člověka online. Konkrétně u wedos jsem dělal testy a MFAčko postavené na PHP skriptu bez přístupu do databáze zvládne vygenerovat za 0,002 vteřiny. WordPress za 0,2 – 0,8 vteřiny (cn130.com konkrétně). Když to podělíš 5ti vlákny dostaneš se na teoretickou návštěvnost za vteřinu. Samozřejmě nepočítáme nějaký zásek, kde by se to mohlo křížit.

      Realita je opravdu pomalejší než si myslíme. Naštěstí lidé nerefreshují stránku každou vteřinu a jsou si ochotni nějakou tu vteřinu počkat když se to nakupí 🙂

  3. No v celku pekne reseni. Mnohem elegantnejsi (pokud mas VPSku) je zablokovat pristup primo na routovaci casti pro rozsah IP adres pomoci iptables. Nevycerpava ti to zbytecne Apache, odrizne to hned routing. Lze taky nastavit povoleny pocet pozadavku za minutu/hodinu pripadne pridelit danemu rozsahu malou rychlost. Maji sice “Most powerful crawler”, ale ten zavisi samozrejme na rychlosti odpovedi prochazeneho webu 😉

    1. Unreal][: přišlo mi že se zamotal do stránek generovaných kalendářem. Nemám u nich žádné cachování, protože tam nikdo nechodí.

      Jinak tam mám VMS, instalovat se tam asi nic nedá. Musím kouknout jestli tam nějaké nástroje na ukazování návštěvnosti jsou.

  4. Hlavne tady se projevuje nevyhoda externiho mericiho nastroje pro nastevnost, protoze v nich proste roboty neuvidis .. 99% z nich funguje pres JS nebo obrazky v .php a to proste roboti nenacitaji. Takze v GA, a podobnych nikdy neuvidis opravdu realnou nastevnost webu (vcetne botu) jako v internich nastrojich co se generuji z logu webserveru (AWstats, Webalizer, atd …).

    Takze mit k dispozici takoveto statistiky nastevnosti a muzes predchazet zvysujicimu se poctu robotu od nejakyho crawlera, nez ti sestreli web uplne.

  5. Ahoj Ivane,

    jsme rádi, že jsi se nakonec spojil s naší podporou a že jsme ti mohli pomoct k tvé spokojenosti 🙂

    Článek je super. Určitě platí, že optimalizací aplikace a vyhodnocováním provozu jde dosáhnout vysokých úspor, i když ne každý uživatel to zvládá a WordPress zrovna moc úsporný není.

    VMS Mini, který máš i ty, utáhne 10 lidí najednou bez problémů. Max. počet lidí najednou je teoretický. Není to ani o návštěvnosti (poslední týden jsi měl i 3 500 UIP/den), ale o skladbě domén a aplikací na nich běžících.

    Na VMS Mini máš k dispozici 512 MB paměti, pro systém i PHP aplikace – ty mají k dispozici cca 300 MB. 1 proces WP ti bere 70 MB paměti, máš tam 10 domén, na kterých ti něco běží, někdo tam chodí a tvé ostatní domény si rezervují procesy, aby je 404m.com úplně „nevytlačila“, v tom je celý problém.

    My doporučujeme navýšit paměť, protože nyní máš dočasné řešení než přijde nový robot nebo ti vyroste návštěvnost. Podle nás je pro tebe snazší si dokoupit 512 MB RAM za 100 Kč a vědět, že máš provozní klid a nebudeš s tím ztrácet čas. WP je bohužel náročný na paměť

    Měj se a spokojený provoz 😉

    Matěj

    1. Matěji samozřejmě souhlasím. Skok z 512 na 1024 je obrovský. Zažil jsem to u AH.

      Většina těch domén je v podstatě mrtvých (v porovnání s tím co mám jinde). Dal jsem je na ČH, kvůli testování různých widgetů atd. U ČH jsou weby rozdělené. To teď nikde jinde nemám, tak jsem to chtěl zkusit. Projdu kolik má která a kdyžtak to nějak přehážu.

      Z těch 3,5K den měl 2/3 ten robot. Řešení je provizorní a popravdě mám pocit, že trochu zlobí.

  6. GA umožňuje také nasazení měřícího kódu na straně serveru, pokud je to skutečně potřeba.

    dá se k tomu napsat vice infa?

  7. Že by statistiky byly analyzovány z dostupných dat podle požadavků na straně serveru a ne podle informací sbíraných na straně klienta? 😉
    Ale jinak jsem to nijak blíže nezkoumal, pokud to běží na nějakém starém principu pomocí skryténo souboru, tak to stejně analytiku z logu nikdy nenahradí. Spíš by to mohlo započítávat různé ty roboty a screenshot generátory, kteří web hodně aktivně prolízají, ale nespouští javascript.

    můj tip pro WP kdo nezná: WassUp Real Time Analytics

  8. Ahoj, mohl bys trošku víc popsat generování potřebného logu?
    “Po aktivaci záznamů, se mi za nějakých pět minut vygeneroval zhruba megabajtový soubor. Za 20 minut 3876 požadavků, skoro vše od toho šmejda.”
    Byl to klasický Apache access_log nebo něco jiného?
    Díky, Jirka

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.