Paměťové nároky - průzkum #153
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Spotter-Cluster/Spotter-VM#153
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Až budeme mít SW nainstalovaný, potřebuji vědět odhad paměťových nároků pro běh VM.
Předpoklad je, že by měly běžet současně v pohodě alespoň 3 velké aplikace, případně mapserver tj. uživatel by měl mít pocit plynulé práce (bez intenzívního swapování atd)
Má smysl se bavit zda je potřeba 16GB paměti, nebo 32 GB? pro celý HW. Tj. pokud to poběží v hostitelském OS ve VM, něco spolkne OS a možná další apps,
Máte k tomu nějaký názor?
assigned to @Disassembler
VM na které testujete má 2 GB RAM a 4 GB swapu. Zatím vidím, že bylo ze swapu historicky využito maximálně 1 GB. Snažím se aplikace integrovat tak, aby žraly co možná nejméně paměti, pokud nejsou využívány. PHP i uWSGI umí on-demand módy, kdy se pracovní vlákna aplikace nastartují až když na danou aplikaci dojde nějaký požadavek. Otázka je tedy spíše na Vás, do jakých parametrů se chcete vejít. Víceméně od začátku pracuji s variantou 2 CPU, 4 GB RAM, 4 GB swap a cca 20 GB na OS a aplikace, tj. bez uživatelských dat. Samozřejmě pokud s aplikací bude pracovat pět lidí, bude potřeba méně paměti, než když těch lidí bude pět set, nehledě na to kolik aplikací na VM poběží.
můj odhad je, že reálně (alespoň zpočátku) by mohlo s VM pracovat jednotky lidí, nanejvýš desítky lidí v konkrétní pracovní skupině.
Záleží i na způsobu připojení klientů. Přál bych si, aby klienti bez obav lezli na VM jak z mobilů, tak desktopu, pochopitelně pokud budou existovat mobilní klienti, tak s pomocí klientů.
operační paměť bych odhadl 8 minimal, 16 comfort.
Netuším jak moc budou vytěžovat paměť nějaké běžící procesy pod zátěží. K tomu se asi ještě dostaneme a probereme.
Celkový swap je momentálně otázkou, protože chování mapserveru a jeho nároků na paměť a výkon je samostatná kapitola.
Pokud se podaří rozjet mapserver s bitmapovými dlaždicemi, pak dlaždice zaberou hodně místa na HDD, při použití více uživatelů to bude vytvářet traffic a bude hodně swapovat, rychle zaplní paměť. Asi docela hodně.
Pokud se podaří rozjet mapserver s vektorovými mapami, které se renderují do bitmap až po requestu, tak by zdrojových dat mělo být méně, rendery se budou ukládat do cache a bude větší nárok na CPU (?GPU?).
Moje představa je nakloněna spíš k vektorovým podkladům právě z důvodů šetření místem, ale sám nevím co to všechno obnáší a jak se podaří rozchodit.
Týkalo by se to přednostně Sahany (asi bude potřeba aktualizovat OpenLayers) a pak už je to věc průzkumu, nenaléhám. (Sahana může mít přepnutí více VMS,takže jedna bude offline, ostatní online. Mapové vrstvy v ostatních aplikacích by prostě byly jak jsou.
Případ s HOT Task managerem je lehce jiný, tam se pro offline práci stahují bitmapové fotomapy konkrétní lokality... Pro načtení do Mapového editoru patrně taky zaberou nějakou paměť. Ale jejich ukládání na HDD je vlastně přechodné jen pro vyřešení mapovacího úkolu.
Snažení s offline OSM mapou mi stačí jako ukázka technologického konceptu že to jde, ... Ostatně GISáci s nadsázkou říkají, že kvalitní GIS aplikace se pozná z toho, že mapa jede i offline. :))
OSM se bojím. Proto kolem něj chodím jako kolem horké kaše a ještě jsem s ním nezačal. Očekávám, že s ním nároky na cokoliv raketově vzrostou. XML je na takovou věc ten nejdebilnější možný formát a když jsem si s tím na konci června hrál, mapa světa skvící 807 GB mě dokonale uzemnila. Doufám, že ten jejich proprietární PBF formát je co do rychlosti dostatečně optimalizovaný. Nicméně tam máme hromadu aplikací, které jedou jen s Google Maps, takže si nejsem úplně jistý, jak moc celé tohle snažení vlastně bude užitečné. Stejně tak aktualizace OpenLayers je sice vznešená idea, ale F&B to už pět let odkládají, takže to asi nebude vůbec sranda.
chápu... ok, ... zkusme něco, co bude na půl cesty a když to bude velký špatný, tak teprv to vzdáme. Určitě se nechci vydat cestou stovek GB, to je nesmysl.
prozkoumejte co jsem naházel za odkazy #142 a nainstalujte si někde odděleně mapový engine, jen pro to abychom zjistili co to dělá s pamětí, co to dělá se swapem a CPU.
Já se na tuhle věc dívám jinou optikou, než z pohledu admina, který zná jen vysokorychlostní připojení.
Prakticky permanentně používám odporně pomalý internet a tak velmi dobře vím, jaké frustrace mají uživatelé z aplikací, které se zpomalují kvůli trafficu. Proto možná vznikal i celý koncept VM, ale nejen proto. Mapy jsou velký žrout trafficu. Ale na lokální síti zas odvedou skvělou odezvu.
Je to pro mne zkouška, v nejhorším to budu muset poptat po někom kdo mapy dělá rutinně.
Jde o to objevit který typ knihovny a rendereru použít na render vektorových map a zkusit. jestli je to Mapnik http://mapnik.org/ nebo nějaké jiné.. píšou o tom asi tady
https://openlayers.org/en/latest/examples/mapbox-vector-tiles-advanced.html
Např. mapová data celé ČR mají ve vektorech 790 MB. Zde bych začal pokud by šlo o stahování dat.
https://openmaptiles.com/downloads/dataset/osm/europe/czech-republic/#5.97/49.82/15.474
čas zkoumání samozřejmě uhradím
nevím jestli by to k něčemu pomohlo ohledně té správy systemových resources, našel jsem https://github.com/google/cadvisor
píší, že to může běžet autonomně. Nevyžaduji, zatím se jen ptám.
O cAdvisoru vím. Nepracoval jsem zatím s Docker kontejnery v tak velkém množství, aby mi stálo za to jej použít. Vzhledem ke způsobu jakým systémy obvykle stavím (tj. jako minimum viable product, bez zbytečností, které by se mohly hodit) nemyslím, že jeho výstup bude kdovíjak odhalující, protože moc možností pro performance tuning jednotlivých aplikací pak už nezbývá.
Nicméně pro jeho použití je potřeba aplikace nejprve nakontejnerovat, na čemž tento týden pracuji a budu pravděpodobně i celý příští týden. Pak se uvidí. Zatím je stavím na Alpine linuxu a mám z toho mám celkem dobrý pocit, protože oproti Debianu jsou fakt titěrné (např. Postgres+PostGIS narvu do 180 MB. Na Debianu jsem rád, když se dostanu pod 700 MB)
taky jsem našel toto https://www.gocd.org nevím jestli by to komukoliv v budoucnu mohlo nějak vylepšit budoucí vývojové postupy. Jen si to odložím.
code: https://github.com/gocd/gocd
changed milestone to %3
tak spodní hranici paměťových nároků jsem prozkoumal dostatečně :D Na novém současném HW už pravděpodobně nemusím mít obavy.
closed