Výpadek MyPower.CZ 14.3.2020

[mypower.cz]

Ahoj, omlouvám se za dnešní několkahodinový výpadek.
Důvodem bylo opakované přetížení virtuálního serveru. Došlo tedy k přestěhování MyPower.CZ na nový server s větším výkonem, více CPU, větší RAM, atd.

Ještě to postupně ladím, ale zdá se, že většina věcí funguje. Kdyby něco tak prosím hlásit.

Já se díky tomu dnes ani na minutu neodlepil od klávesnice.

Děkuji za pochopení a za trpělivost.

[tomas]

Díky. No jo všichni sedí doma v karanténě a studují mypower a řeší soběstačnost a tak nám to tu přetížili.

[PavelR]

nevim jestli to je nejakej placebo efekt ale me se zda ze se rychlost nacitani fora i hl. stranky zvysila nekolikanasobne.

[mypower.cz]

nevim jestli to je nejakej placebo efekt ale me se zda ze se rychlost nacitani fora i hl. stranky zvysila nekolikanasobne.

Ano .. homepage zhruba 390 milisekund trva serveru, nez to splácá dohromady. A slo by to jeste nejmene o jeden rad vylepsit. Tim jsem si jist.

Priznavam se bez muceni, ze od zacatku doted jel mypower.cz na jednom jedinem CPU s jednim jadrem a 2GB ram.

Takovy pocitacek, ktery uz mame doma vsichni nekolikanasobne rychlejsi (bezne 4 jadra, 4-8 giga ram a podobne).

Tak jak vidime, i s jednim CPU a 2 GB ram se da castokrat fungovat a udelat celkem zajimava parada, jen je potreba hodne moc premyslet a nektere veci delat opravdu hodne efektivne. I tak s ohledem na rust fora, nekdy umele vytvorene zatezi ze site a podobnym jevum to uz nestacilo.

Puvodni serverik hodlam dale vyuzit, ale uz pro ponekud jine (trivialnejsi) ucely.

[unicast]

Dělali jsme podobné věci se 486DX2 66 MHz a DX4 100MHz s 16 nebo 32 MB RAM a taky to šlo. Linux na tom běhal, Apache na tom běhal, php na tom běhalo a tehdy často i BIND, sendmail, ssh, mysql spousta scriptů atd. Léta 1996 - 1999, pak jsme to zmigrovali na Pentia 133 MHz a 64 MB RAM To jedno jádro a 2 GB RAM je pro jednoduchý webový server luxus a že nestačí, to je dáno jen současným krutě neoptimalizovaným software.

[mypower.cz]

Dělali jsme podobné věci se 486DX2 66 MHz a DX4 100MHz s 16 nebo 32 MB RAM a taky to šlo. Linux na tom běhal, Apache na tom běhal, php na tom běhalo a tehdy často i BIND, sendmail, ssh, mysql spousta scriptů atd. Léta 1996 - 1999, pak jsme to zmigrovali na Pentia 133 MHz a 64 MB RAM To jedno jádro a 2 GB RAM je pro jednoduchý webový server luxus a že nestačí, to je dáno jen současným krutě neoptimalizovaným software.

Na tehle puvodni VPSce to bylo dano dle meho nazoru i okolnimi virtualy. Rekl bych ze se tam casto nekdo dost roztahoval a stroj proste uz nemel kapacitu na to, aby pro mypowerovou VPS pridelil dost strojoveho casu. Nevim, to jsou jen me spekulace. To byly nekdy vypadky ze to vicemene ani moc nic nedelalo az tak zasadniho, ale server load treba 50-90 klidne. To uz samozrejme je pak problem se i prihlasit na SSH a neco s tim vubec udelat. Nedej boze jak to lizne nejak mohutne swap tak to je uplna konecna. Jinak teda podle popisu vyse koukam ze jsme zazili podobnou dobu Jo tehdy se delaly veci sakra efektivne, a slapalo to v poho. Dnesni programatori o nicem takovem nemaji paru. Nikdo je dostatecne nepriskrtil. A to je moc potreba. Jakmile se dela vyvoj na minimalnim stroji, tak pak pri vstupu do produkce na lepsim zeleze to sviha nadsvetelnou rychlosti.

[unicast]

Server load zase není tak kritické číslo, znamená to pouze počet procesů čekajících ve frontě na to, až ho jádro pustí k CPU. Pokud každý udělá deset instrukcí a CPU se mu zase odebere nebo se ho dokonce dobrovolně vzdá (pošle se do idle nebo čeká na výsledek nějakého systémového volání), tak čísla kolem 50 ničemu nevadí. CPU load je výrazně zajímavější hodnota (a zjistíš ho třeba příkazem top a pak zmáčkneš jedničku, abys to viděl po jednotlivých jádrech/procesorech).

[nextclick]

To jedno jádro a 2 GB RAM je pro jednoduchý webový server luxus a že nestačí, to je dáno jen současným krutě neoptimalizovaným software.

Ahoj trochu upřesnim to co říkáš. Ve světě windows aplikací toto určit platí. Pro svět linuxu o je spíše naopak. Například PHP se od verze 5.3 do aktuálních 7.4 zrychlilo cca o 30% a to díky lepší kompilaci. Apache,mariadb,nginx je taky o pár fousů rychlejší. Spíš je problém s tím že na těch serverech žijou už letitý projekty takže se velmi zvětšili jejich databáze co ty stroje musí obsluhovat. Taky provozuju pár for a ten update php mne kdysi zachránil od nutnosti upgradovat hw. Z přetíženého stroje se stal stroj co stíhá úplně v pohodě.

[diablo007]

Systém mi omezuje velikost přílohy na 2MB já mám pocit že to bylo předtím navýšeno ta velikost že?

[nextclick]

To bude omezení výchozího nastavení linuxu na který se to asi zmigrovalo. Tedy je to potřeba upravit v php.ini ?

[mypower.cz]

Systém mi omezuje velikost přílohy na 2MB já mám pocit že to bylo předtím navýšeno ta velikost že?

Mas tam opet 16 mega jako na puvodnim serveru. Opet ale i pres to podotykam: nezneuzivat a naucit se fotky zmensovat, tudiz nedelat ze serveru photoshop.

[mypower.cz]

Vazeni, dnes pozde vecer, rekneme tak ve 22:00 probehne jeste restart serveru, tak snad to bude rychle a nic se nepo*. Tudiz prosim dnes tedy jeste o strpeni s pripadnym vypadkem. Dik za pochopeni a trpelivost.

[nextclick]

Držim palec a ještě se podívej na nastavení https a certifikát .. zjevně to nefachá.

[mypower.cz]

Držim palec a ještě se podívej na nastavení https a certifikát .. zjevně to nefachá.

Ano na řešení portu 443 jsem se zatím nedostal. Je toho tolik že nevím kde mi hlava stojí.

(Zadarmo.)

[nextclick]

Je mi to jasný! Az to bude tak to bude. Neni to tak dulezite.

[mypower.cz]

Tak restart hotový, ne vše se úplně povedlo, proto zatím teď ještě nejedou grafy, takže dneska tak ještě do dvou do rána.

Má-li někdo chuť podpořit fórum, tak opravdu budu vděčen - viz podpis každého mého příspěvku.

Zítra mě čekají další práce, páč někde to ještě trochu občas výkonnostně drhne a zatím nevím proč přesně.

Snad na to brzy příjdu.

[unicast]

To jedno jádro a 2 GB RAM je pro jednoduchý webový server luxus a že nestačí, to je dáno jen současným krutě neoptimalizovaným software.

Ahoj trochu upřesnim to co říkáš. Ve světě windows aplikací toto určit platí. Pro svět linuxu o je spíše naopak. Například PHP se od verze 5.3 do aktuálních 7.4 zrychlilo cca o 30% a to díky lepší kompilaci. Apache,mariadb,nginx je taky o pár fousů rychlejší.

Další problém je, že přibývají další vrstvy software. Konkrétně s phpBB zkušenost nemám, ale kupříkladu WordPress vyžaduje postupně další a další funkčnosti od webového serveru, což samozřejmě znamená nárůst komplexity (a to se už vůbec nebavím o modulech pro WP atd.)

[mypower.cz]

Pánové linuxu znalí, pojďte se mi s chutí hlasitě zasmát.

Od rána řeším problém. Používám rsync na synchronizaci dat předpočítaných wattstatistik. Rsync samozřejmě má předhozen ssh -i s cestou na privátní klíč tak aby přes ssh mohl přenést data. A jelikož je přenos spouštěn cronem, tak samozřejmě aby se to neptalo na heslo.

V rámci interní VPN sítě mezi master a slave servery a taky mezi jednotlivými slave servery používám bind, abych mohl krásně používat názvy a nemusel používat IP.

Hodiny googlím proč mi ssh při přihlášení se pomocí klíče píše:

Kód: Vybrat vše

debug1: Offering DSA public key: .ssh/ssh-key
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@s7.vpn3's password: 

a následně se ptá pořád dokola na heslo. Proto wattstatistiky od rána nejedou a stojí.

Tisíce googlení, tuny pokusů omylů na remote serveru i na local serveru s konfigurací sshd_config a ssh_config a nic.

Furt se to ptá na heslo jak blbý.

Důvod?

V konfiguraci bindu byla chyba a resolvoval mi místo VPN IP správného slave serveru VPN IP jednoho běžícího raspberry pi na mé chatě, konkrétně to, které se mi stará o muziku a přehrávání pohádek pro malého 3letého synka, když jsme na chatě. Dříve se jmenoval s7, dnes rpi2.

Pane bože za co!!!!!!

Celou dobu valím privátní klíč proti rpi místo proti slave serveru, na který data potřebuju přenést. To pak na serveru i na lokále můžu konfiguraci SSH měnit jak chci a nepomůže mi ani svěcená voda.

Pffff ... 6 hodin doslova v prdeli kvůli takovému renoncu.



No nic... Zachvilku wattstatistiky zas pojedou.

Jdu si dát snad panáka. Tohle není možný.

[Jan Novák]

Dneska celé ráno řešíme proč najednou z ničeho nic nefunguje ověřování v jednom IS proti OpenLDAP, po hodinovém debugování jsme přišli na to, že login neni cn=michalprijmeni ale cn=milanprijmeni. Nikdo si toho nevšiml