Mně se to líbí, ale taky to neumím naprogramovat :)
On Thu, Mar 26, 2015 at 5:02 PM Martin Malec | TIERRA VERDE <
mm.tierraverde(a)gmail.com> wrote:
Mám návrh jak citlivým způsobem napomoct lidem, aby si
optimalizovali
své VPSky:
Monitorovat spotřebu zdrojů (CPU, paměť, IO...) u VPSek a dávat ve
vpsadminu informaci o tom, jak si daná VPSka stojí v poměru k jiným
VPSkám na stejném stroji a na všech ostatních strojích - percentil a to,
poměr toho, jakou "výpočetní stopu" daná VPSka má, a kolik takových
fyzických serverů by bylo potřeba, kdyby se všichni ostatní chovali
stejně - analogie výpočtu "ekologické stopy" a počtu planet, které
bychom potřebovali, kdyby 7 mld. lidí mělo fungovat jako průměrný
Američan nebo Čech.
Těm, kteří by konzumovali zdroje tak, že by bylo potřeba třeba 10x a
víckrát silnějšího fyzického stroje, než je teď, kdyby se takhle chovali
všichni, by se v nějakých intervalech tyhle statistiky posílali i do
kontaktního mailu s výzvou se na tom pokusit něco dělat - to vše ještě
před tím, než by se přistupovalo k tomu omezování IO apod.
Příklad:
"Tvoje VPS byla v měsíci březnu 2015 ve srovnání s jinými VPS na témže
fyzickém stroji (brq2):
- VELMI NÁROČNÁ na paměť RAM (3750 MB/4096 MB, 94. percentil)
- PRŮMĚRNĚ NÁROČNÁ na využití CPU (přispívá 0.42 k průměrnému cpuload
fyzického stroje 15.98, 54. percentil)
- SPÍŠE NENÁROČNÁ na využití úložného prostoru (1,4 GB/60 GB, 15.percentil)
- SPÍŠE NENÁROČNÁ na dobu pořízení ZFS snapshotu (zálohování) (4,5
minuty, 20.percentil)
- VELMI NENÁROČNÁ na množství přenesených dat z/do internetu (1,5 GB za
poslední měsíc, 4. percentil)
- EXTRÉMNĚ NÁROČNÁ na špičkové/opakující se IO operace (98.percentil)
Kdyby všichni na tomto fyzickém stroji používali VPS jako ty, byl by
potřeba průměrně 3,2x výkonnější stroj (4,8x více paměti RAM, 1,1x více
CPU jader, ...
Doporučení:
Omezení IO operací: Zkus omezit pravidelně se spouštějící skripty, které
kontrolují celý souborový systém, např. ClamAV, který se standardně
spouští příliš často a na mnoho VPS najednou. Návod, jak omezit
spouštění na jednou denně, nalezneš na xxx.clamav.zzz nebo na naší
wiki.vpsfree.cz/clamav...
Omezení spotřeby RAM: Zkontroluj, které služby se spouštějí a nejvíce
potřebují RAM. Velkou spotřebu mívá webový server (Apache), databázový
server (MySQL), Tomcat apod. Využívání paměti lze správným nastavením
upravit, nebo lze náročnější webový server (Apache) nahradit za méně
náročný (nginx).
Poradit se s ostatními, jak optimalizovat VPS, můžeš v našem
community-listu community-list(a)lists.vpsfree.cz.
Dává vám to smysl? Úspěch těchto "vzdělávacích" strategií je dávno
ověřen u různých pro-environmentálních iniciativ třeba v supermarketech
a hotelích, národních parcích atd. Naprogramovat to co výše uvádím
nedokážu, ale můžu poslat odkazy na studie, které říkají, jaké metody
komunikace se osvědčily ;-)
Martin Malec
TIERRA VERDE s.r.o.
www.tierraverde.cz
737 740 166
On 26.2.2015 14:56, Pavel Snajdr wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 02/26/2015 02:46 PM, Vaclav Dusek wrote:
Uzitecnost VPS nech posoudi provozovatel. Co ho
na to alespon
upozornit?
Samozrejme, spolu s oznamenim o nasazeni limitu prijde i duvod, pravda
je, ze obcas tim limitovanim srazim i VPS, ktera delala bordel jenom
chvilkove, ale to se da vzdycky vykomunikovat a limit vratim, kdyz k
nemu neni duvod.
Also, v souladu s tim, co pises, "provozovatel" casto neumi posoudit
uzitecnost toho ClamAV. Jinak by ho tam ani vetsina IMHO nemela. Ale
to je vec nazoru, vsak instalujte si kdo co chcete, pokud je to legalni
:)
Bud nabizim neomezene sdilene VPS a nebo musim
nastavit pravidla,
lepe limity a priority. User o tom netusi a nevi, jak se chovat.
Tady je trochu
problem v tom, ze kdyz nastavim IO limit, je to limit
realizovany pres cgroup io controller, kteryzto omezuje jakekoliv IO
tech procesu, takze i treba output do FIFO. Nebo IO na /dev/null a
/dev/zero.
Cili nastavit vsem limit == olimitovat i podobne nevinne pripady, coz
se mi nelibi.
Je zapotrebi najit nejuzsi misto a tam nasmerovat
sve snahy o
odstraneni problemu:
Proto tu rozebirame ClamAV, ktery se probira zrovna na
node2.brq
jednou za hodinu nemalo VPSkam a vybombi to IO na kompletku.
- vykon diskoveho pole
Neni problem, to
pole dava stabilne okolo 1.1k IOPS, to je IMHO az az.
- nacasovat jinam zalohovani
Neni kam.
Sotva se stihaji v rozumnem case ted, zacinaji v 1 rano a
konci okolo 12te - spravne by melo byt okolo 8me hotovo, nez ty
servery jsou opravdu potreba. Problem je v rsyncu, kdyz to Aither
nekdy dodela, tak pri send-recv bude po problemu se zalohovanim, zbyde
akorat problem s "hlucnymi sousedy".
- priorita migrace
Neni souvisejici
problem, jenom rikam, ze to v tuhle chvili byl dalsi
zdroj IO operaci
- limitace
Viz vys.
/snajpa
- ?
Nejsem schopen dat vsem na sdilenem prostredi vykon dedikovaneho
serveru
Dne 26.2.2015 v 14:39 Pavel Snajdr napsal(a):
> No a ted na node2.brq bezi 3 procesy:
>
> clamscan --recursive --no-summary --infected /
>
> Velmi uzitecny full scan VPS :)
>
> K tomu dobihaji zalohy a bezi jedna migrace VPS.
>
> Chudak node2.brq, trochu to nedava.
>
> /snajpa
>
> On 02/26/2015 11:16 AM, Pavel Snajdr wrote:
>> Ahojte,
>> mam par dotazu na vas, co pouzivate ClamAV:
>> 1) ta blbost je vubec k necemu dobra? 2) chyti to nekdy neco
>> vubec? 3) da se nastavit vic random interval na freshclam?
>> Tahle blbost se probira najednou vsem, co to maji nainstalovany
>> a spolehlive to zabiji IO. Typicky node2.brq tim ted dost
>> trpi.
>> Ja jsem nasazoval uz peknejch par mail serveru, ale ClamAV
>> nikdy, nebo jsem ho po par dnech vyhodil, protoze stejne k
>> nicemu nebyl.
>> Mate ho tam nekdo naschval, nebo je to jenom soucast nejaky
>> instalace neceho hotovyho, jako ISPConfigu nebo tak?
>> Dik za info.
>> /snajpa _______________________________________________
>> Community-list mailing list Community-list(a)lists.vpsfree.cz
>>
http://lists.vpsfree.cz/listinfo/community-list
> _______________________________________________ Community-list
> mailing list Community-list(a)lists.vpsfree.cz
>
http://lists.vpsfree.cz/listinfo/community-list
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlTvJfsACgkQgRwOVqYrsFWuHAD+NazfkiG6BKSWreXzaOZS26o+
W2rLkq8lxWHgg6uNFmABAM0ZFgaGoVMulmghkFJbbrcvJ2R71m8QdL0q6b2X51dZ
=zOQw
-----END PGP SIGNATURE-----
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list