Ahoj,
dělal se v poslední době nějaký “výzkum” ohledně toho jak současná konfigurace VPS vyhovuje jednotlivým členům? Z mé zkušenosti a i ze zkušenosti těch pár lidí s kterými se bavím je pro náš workload typické větší využití RAM než CPU. Dávalo by smysl zauvažovat o změně konfigurace (změnit poměr CPU vs paměť), bylo by něco takového pro komunitu spíš užitečné? Dá se uvažovat o něčem takovém realizovat?
Uvazovat lze o leccem, ale nekdo to musi zaplatit. Tu RAM moc levneji dat nepujde, muze tam maximalne tak nebyt ten zbytek k tomu, kdyz ho nechces…
EDIT: levneji to jde, hodne na hrane, pri tak dvojnasobne velikosti, nez jsme ted; do te doby, leda ze bychom to mohli dotovat z nejake dalsi cinnosti (napr. Contabo jede ciste z investorskych penez a takove Forpsi ten VPS cluster dotuje z provozu jinych veci) – pak bychom se mozna mohli dostat na dvojnasobek RAM za ± stejne penize, obzvlast, kdyz do toho vstoupi “economy of scale”; jinak ale RAMka zas tak zasadne nezlevnila, abychom mohli uvazovat o navysovani - museli bychom na to koupit HW a ten se musi zaplatit, rozdavat moc neni z ceho, mame jen to, co spolecne vysbirame 
Jeste pridam: CPU se da snadno agregovat, protoze neni v podstate nikdy nikde vyuzite naplno; vyuzita RAM je uz ale vyuzita a dokud se neuvolni, nikdo jiny na ni nesahne… vic RAM do masin dat nemuzeme, protoze bychom museli prejit vsude ze 64G na 128G DIMMy, kde bychom museli nejen zaplatit vsechnu RAM znova, ale jeste priplatit za ten dvojnasobek + extra za to, ze to jsou min bezny, vic premiovy zalezitosti, ty 128G DDR4 sticky… dalsi nejaky zlom vidim pri obnove HW za DDR5, kde by ty 128G sticky pak mohly stat tolik, co ted 64G - ale to je pro nas tak nejdriv za 4 roky od ted…
Jinak bych chtel dodat, ze jsem rad, ze se o tom bavime; ja tohle resim v hlave uz tak 3 roky, kdyz vidim, kolik ty aplikace, po kterych se ani nic moc nechce, zerou pameti… ekonomicky to ale nevychazi, i kdyz bych hodne chtel.
Co ale vychazet muze, je podpora swapovani a nejaky ten prideleny swap. Tam nas ted brzdi cgroup v1, kde swappovat dost dobre nejde, protoze ten system muze deadlockovat. S cgroup v2 to uz ale pujde - a tam jsme akorat v bode, kdy muzeme nasazovat, jak rychle to pujde, bude zalezet akorat na tom, jak se vsem bude chtit to resit Az budeme mit domigrovano na cgroup v2, myslim, ze to s tim swapem pujde vymyslet. Samozrejme to nebude pro vsechny, protoze zapnuty swap tak nejak implikuje nizsi vykon, ale pro malo vyuzivane aplikace myslim, ze by to mohlo docela situaci resit 
A snad posledni dodatek: cela tahle vec by se resila zasadne jinak, kdyby se o tolik nezdrazily energie a v tandemu s nimi vsechno ostatni, meli jsme pekne nakroceno na navyseni RAM o dost driv, protoze by nam prebyval hardware, kdybychom ho nemuseli spoustu vypnout… ne kazdny nutne oceni novejsi zelezo. Ale i kdyz jsme sundali spotrebu na polovinu urovne 2019, vratili jeden rack, jen na housingu rocne i tak zaplatime o 150 tisic navic. Je to pro mne srdecni tema a citim velke zklamani, protoze jsem mel ocekavani nastavena na vic, nez ceho se ted da dosahnout. Timhle jsem mel celou odpoved zacit, pardon
Jak psal Snajpa, V aktuální době žerou i aplikace které prakticky nic nedělají hodně RAM. Chtělo by to přidat, ale je jasné že by to bylo drahé.
Osobně taky mám s velikostí RAM problém, ale prozatím to řeším tak, že co žere málo ram tak nechávám u VPSFree, ale náročné aplikace/workload na RAM běží buď u Contaba, nebo pokud žerou hodně RAM a je na nich malá zátěž z internetu tak si to provozuji doma (doma mi běží 2 servery [CPU 12 a 8 vláken] a každý má 64GB RAM a několik TB disku, bohužel konektivita je slabá). Je to jediné řešení na které jsem aktuálně přišel a pohrávám si i s myšlenkou kompletního přesunu do režimu Contabo + domácí hostování a opuštění VPSFree. Rozhodnu se až mi bude končit předplacené členství, jestli pokračovat, nebo ne.
Dalsi vec, co se hodi zminit v kontextu vpsFree vs jinde, je, ze nejsou 4 GB, jako 4 GB
U nas do tech 4G pocitame jenom a pouze uzivatelskymi procesy vyuzitou pamet, ani ZFS cache, ani zadna dalsi jaderna pamet, se do toho nepocita. Cili na tech 4G je dneska docela dobre mozne provozovat to, co jinde uz ted chce 8 GB. Schvalne si to vyzkousejte :))
Opticky to nevypada tak sexy, ale jestli by to nejak zasadne pomohlo verejnemu obrazku o vpsFree, klidne muzeme to uctovani jaderne pameti zapnout a navysit to opticky na tech 8 GB, pritom ale zmena nenastane ± zadna, jedine tak u tech aplikaci, ktere fakt nic nedelaji (a tak nepotrebuji peakovat, co se treba rozpracovanych dat nad soubory tyce). Ostatni budou cekat OOMy uplne stejne, jako ted pri 4G uctovani jen userspace pameti Proto ted tlacim spis na to, abychom meli masiny pripravene na zapnuti swapu, to pokryje IMHO mnohem vic, nez delat takove nejake zmeny jen na oko, aby to vypadalo.
(also: primarni duvod, proc tu kernel pamet neuctujeme, je vyssi vykon celeho systemu, ale to uz by dneska mohlo jit snad vyladit lip, tohle rozhodnuti jsme delali nekdy jeste v dobach kernelu 4.x)
l zauvažovat o změně konfigurace (změnit poměr CPU vs paměť), bylo by něco takového pro komunitu spíš užitečné?
Něco jako víc počítat a míň ukládat (cachovat)?
Dá se uvažovat o něčem takovém realizovat?
To se asi na úrovni aplikací hůře realizuje.
Systémově by se dal použít zswap. Pro začátek by byl jednodušší ten obyčejný swap, jak již bylo zmíněno.
RAMka zas tak zasadne nezlevnila … kdyby se o tolik nezdrazily energie
Jen pro zajímavost, dá se odvodit, zda stojí jednotka RAM za čas více na odpisu ceny HW nebo své vlastní spotřebě?
Jen pro zajímavost, dá se odvodit, zda stojí jednotka RAM za čas více na odpisu ceny HW nebo své vlastní spotřebě?
To jsou moc vysoky uvahy zakladni problem je bariera porizovaci ceny, vybavit jednu z tech dvou velkych masin 4 TB RAM v 32ks 128G modulech vyjde na pul milionu U dvou masin jsme na milionu (aktualne koukam cca 522 EUR bez DPH za 128G DDR4 modul) + 2 mensi masiny = 1.5M, to je vicemene kolik nas staly ty dve velke masiny s 64G modulama cele, i s SSDckama… a to bychom meli cele jeste jednou utratit za navyseni RAM na dvojnasobek? Bral bych 
Kdyby bylo z ceho.
Jak ja jsem rad za moznost editace, ze k tomu muzu pridat, aniz bych musel posilat dalsi zpravu… to navyseni cen energii/housingu a postupne taky zvedani se nakladu na bydleni adminum, nam ukrouhnulo presne ten volny rozpocet, co jsme mohli na takovy nejaky nakup pouzit. Ono to puvodne bylo v planu tak, ze bychom nechali bezet minimalne vsechno, co ma v sobe DDR4 pameti, mozna i neco DDR3 based - a tim bychom meli v clusteru zasadne vic RAM, nez ted - obzvlast, kdyz se daji 64G moduly koupit v porovnani hodne levne, co bychom mohli byvali menit postupne po jedne masine. Jenze ted ty kW spotreby navic uz neni, jak zaplatit.
Mne osobne dava vic smysl kombinace zram a NVMe pod tim; v cem by mel zswap vyhodu? Mne to prijde jako horsi reseni, kdyz tezko ovlivnim, co do swapcache jde, nebo kolik ji vubec muze byt…
Díky za rozepsání těch nákladů pamětí, zkalibroval jsem se tím.
kombinace zram a NVMe pod tim; v cem by mel zswap vyhodu?
Nevím, která varianta by byla lepší 
, jen mě to první napadlo.
I ten zswap prvně využívá RAM (zpool), než to odejde na block device. Dá se to regulovat per-memcg. U zram si nejsem jist, komu je CPU (de)kompresní práce účtováná (system vs CPU cgroup). (Ale to možná tolik nevadí, když i kernel memory je sdílená.)
zram by imho určitě stál za pokus, to by snad mělo jít rovnou nasadit na playgroundu nebo na stagingu bez dalších úprave, ne? Na druhou stranu nemáš záruku, kolik na tý kompresi reálně vyděláš.
Vedle toho se ale přímo nabízí jiný řešení - navýšit členské poplatky. Jak dlouho se na ty poplatky nesáhlo? 10 let? Kdyby se poplatek zvýšil třeba jen na 350, mohlo by to cash flow vylepšit dostatečně na to, aby se ta RAMka ufinancovala třeba nějakým střednědobým úvěrem?
Tohle je poměrně zásadní informace, která by se imho měla objevit na nějakym prominentním místě. Zvlášť v kontextu konkurence, kde to fakt pak opticky vypadá blbě.
Ja vidim jednu jeste primocarejsi moznost. Posnazme se vsichni, at vyrosteme jeste cca o 500 clenu a sedne nam to diky economy of scale (nejvetsi naklad totiz je na lidi, co se o to staraji, co se mnohem snaz rozpousti mezi vic clenu).
Akorat zatim nevim, jak by to “posnazeni se” melo vypadat
Zvysovani clenskych zas znamena, ze to da impulz neznamo-kolika-clenum odejit…
To by taky bylo hezký, ale otázka je - máme na to hardware? Těm členům je třeba něco nabídnout a 4G ram (i když reálných) už dneska bohužel není žádná sláva.
Má to chicken-and-egg ekonomický řešení?
Imho by mohlo pomoct advertisovat čísla ve stejných škálách, jako konkurence, bo 4G fakt na letáčku vypadá blbě. A možná zkusit ten zram a třeba to číslo zvednout aspoň o trochu - třeba 9G (tj. 5G reálných)
Novi clenove == novy prijem == dalsi hardware, to neni moc problem. Problem je v tom, ze soucasny prijem je rozalokovany tak, ze se s tim obtizne pohne na nejakou stranu, aniz by nas to dostalo do platebni neschopnosti. Leda az pri dalsi iteraci nakupu vseho hardware, proto az za tak dlouho, jak jsem psal puvodne. Jinak pri tomhle levelu prijmu vic muziky vykouzlit nejde, kdyz nam skokove zdrazily vstupy.
Jakoze vydavat swap za ram? To neee
jako… technicky to swap je, no, ale v ramdisku. Efektivně to zvýší využitelnou paměť s minimálním overheadem. In theory. V praxi by to chtělo nějakej test, jak si s tim vpsfree-specific workload poradí - trashing u page swapů a tak (ne že bych tomu nějak rozuměl 
) Co to nahodit na staging?
(na laptopu to mam, tušim že Fedora to snad chce zapínat by default, a nepozoruju žádný negativní efekty)
Jenze benefit ty komprese je tak nejak uplne teoretickej, v praxi tam moc neni. Rozhodne ne na takovy cisla, jaky si predstavujes. Ziskat volnou pamet jeji kompresi moc nejde. Jde pouzit NVMe-backed swap, ale to pak uz vubec nejde vydava za RAM (a zram-backed swap vydavat za RAM nejde taky, uz jenom proto, ze se to vsude projevuje jako swap, ve vsem accountingu).