[vpsFree.cz: community-list] Návrh jak motivovat členy k optimalizaci VPS

Thu Mar 26 18:41:11 CET 2015

Zobrazovat statistiky IO v administraci by bylo super, ale obalovat to v
administraci podobnýma hláškama mi příjde trochu ujeté :D

S pozdravem
*Pavel Sieder*

Dne 26. března 2015 17:47 Martin Koutecký <m at ef5.cz> napsal(a):

> 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 at 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 at 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 at lists.vpsfree.cz
>> >>>> http://lists.vpsfree.cz/listinfo/community-list
>> >>> _______________________________________________ Community-list
>> >>> mailing list Community-list at 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 at lists.vpsfree.cz
>> > http://lists.vpsfree.cz/listinfo/community-list
>>
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz
>> http://lists.vpsfree.cz/listinfo/community-list
>>
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20150326/b5707d59/attachment-0002.html>