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@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@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:
- 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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________ Community-list mailing list Community-list@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list