Fórum Root.cz
Hlavní témata => Server => Téma založeno: ondrejondrej 27. 06. 2018, 16:13:57
-
Zdravím,
máme výpočetní aplikace, které potřebují hodně vláken (desítky) a cca 2 GB paměti na vlákno po dobu několika dní.
Uvažujeme o tom, jestli by bylo vhodné a realizovatelné spojit několik pracovních stanic (3-4x workstation, 4-16 jader, Intel i AMD) do nějakého virtualizovaného stroje, který by se vůči výpočetním aplikacím prezentoval jako jeden stroj s mnoha jádry (kvůli kompatibilitě s aplikacemi).
Má smysl řešení typu virtuální cluster ubuntu s VMWARE nebo VirtualBoxem?
Jaké můžeme očekávat snížení reálného výkonu oproti jednoduchému součtu výkonů jednotlivých stanic?
Díky za rady.
-
Mas cloud k dispozicii: AWS, GCP,.. . Naklikas si masinu(y) aku potrebujes a ked skoncis vypocty po 2 dnoch tak ju zrusis.
-
no a ta aplikace je SMP nebo MPI? MPI je triviální
na SMP potřebuješ něco jako Beowulf cluster
-
máme výpočetní aplikace, které potřebují hodně vláken (desítky) a cca 2 GB paměti na vlákno po dobu několika dní.
Desítky, takže třeba AMD ThreadRipper nebo EPYC?
Jaké můžeme očekávat snížení reálného výkonu oproti jednoduchému součtu výkonů jednotlivých stanic?
Podle aplikace. Pokud vlákna nesdílí prostředky, tak žádné. Pokud je to hodně propletené sdílením dat, může to klidně být v poměru latence technologie co použijete na propojení ku latenci L3 cache (tj. třeba 1000x).
-
Mas cloud k dispozicii: AWS, GCP,.. . Naklikas si masinu(y) aku potrebujes a ked skoncis vypocty po 2 dnoch tak ju zrusis.
Tohle je cesta, kterou bych šel já, automatizuješ si deployment, pustíš výpočty, uložíš si výsledky a zhodíš mašinu.
Nadupaný mašiny tě budou stát cca jednotky dolarů na hodinu. Taková c5.18xlarge s 72 CPU a 144 GB RAM je za $1.116/hr, viz https://calculator.s3.amazonaws.com/index.html.
Takže pokud pracuješ v podmínkách, že včera bylo pozdě a všechno chceš hned, tak cloud je skvělá volba. Jestli se ti spíš vyplatí opečovávat inhouse hardware, si spočítej sám...
-
Molekularni simulace se delaji na MPI clusterech, jednotlive procčsy komunikuji zasilanim zprav MPI.
-
Molekularni simulace se delaji na MPI clusterech, jednotlive procčsy komunikuji zasilanim zprav MPI.
a uzly se propojovaly myrinetem, ktery mel nizsi latence nez ethernet.
-
Díky za reakce.
- software je proprietární, primárně SMP, pro proteomické a metabolické výpočty
- používá lineární solvery (IPOPT apod.), generování extenzivních databází a jejich prohledávání, NVMe a mnoho vláken je nutnost
- je to hodně interaktivní proces, takže předplacení na výpočetním cloudu není ekonomické
- ano, threadripper je příští volba, s tou latencí vůbec nemám představu. Mohu je propojit gigabitovou linkou, což je asi maximum.
Máte někdo zkušenost s virtual SMP řešením od VMWARE nebo VirtualBoxu?
-
Pokud jsčm cetl spravne, tak nejde spojit vice uzlu v siti, aby se to
chovalo jako jeden SMP stroj.
myslim, ze ani vmware ti tohle neudela.
-
Smp z clusteru snad pomoci ScaleMP.
-
Díky, ScaleMP by bylo asi to pravé, ale chtějí certifikovaný HW i pro free variantu.
-
Kdysi jsem zkusil mosix, ale to uz je hafo let, tak nevim zda to ma smysl.
-
Zdravím!
Mosix jsem taky zkoušel, ale ten řešil jen meziprocesovou komunikaci pomocí souborů a rour. Sdílenou paměť a virtuální SMP neměl. Beowulf je podle mně ten správný odkaz. Ale je to špatný nápad. Na pracovních stanicích s gigabitovým Ethernetem bude vážně to zpomalení řádově 1000x.
Dost záleží na tom, jestli jste výzkumná instituce. V tom případě bych radil obrátit se na Metacentrum, kde jsou k dispozici výpočetní prostředky sdílené mezi veřejnými ústavy a univerzitami. Jste-li soukromá výzkumná instituce a máte granty, nejspíše se tam také dostanete, a nebo na superpočítače v Ostravě.
Pokud ne, mohu nabídnout u Homeatcloud výpočetní uzly s až 32 vlákny a 384 GB RAM. Dají se naklikat normálně v konfigurátoru Server Hosting ze serverů HPE co máme skladem a pronajímat s měsíčním závazkem https://www.homeatcloud.cz/server-hosting/konfigurator (https://www.homeatcloud.cz/server-hosting/konfigurator). NVMe bohužel nemáme, ale dají se zainvestovat. To bychom se ale museli domluvit nějak soukromě a sepsat na to smlouvu.
-
Kolik toho realne potrebujete a na jak dlouhou dobu? Do nejakych 60k vlaken? Nebo netusite a k tomu mate nejakou debilne napsanou aplikaci ktera neumi skalovat? Klidne pres sz.
-
Díky za info o latenci na Beowulf řešení i o Mosixu.
Metacentrum bez vyčleněného stroje je nepoužitelné. Když člověk zadá job na 48 cpu, tak akorát spadne do nekonečné čekací řady, a časem ještě hlouběji, protože optimalizátor vyhodnocuje úlohy pro 1-6 cpu jako realizovatelnější. Navíc je to velmi interaktivní práce, takže vlastní zdroje jsou nutné.
SW je kvalitně napsaný, škáluje sám a čím více zdrojů dostane, tím dříve se dopočítá řešení.
-
Ono pokud to jede nad intenzivně sdílenými daty v RAMce, tak může být i rozdíl mezi 1x 32core vs. 2x16 vs. 4x8 core (jedna/dvě/čtyři patice) - za předpokladu, že propoj mezi paticemi (HT/QPI) je pomalejší, než interní sběrnice v rámci patice. Každopádně snaha emulovat SMP (NUMA) nad Ethernetem je už na první pohled špatný nápad :-)
Takhle kdyby ten software uměl řešit "lokalitu" alokované RAM a CPU jádra. Tzn. kdyby si byl vědom NUMA struktury stroje. Resp. aspoň kdyby úloha byla s ohledem na nestejné latence v NUMA topologii nějak optimalizovatelná. Linux má o těchto věcech interně přehled (https://queue.acm.org/detail.cfm?id=2513149) a údajně může proces "svoje" alokované "virtuální" stránky přestěhovat na konkrétní NUMA uzel (http://man7.org/linux/man-pages/man3/numa.3.html) (resp. má právo o to požádat.) Jenom mi ohledně linuxu/libnuma není jasné, jestli se baví jenom o procesu (pid) nebo v jemnějším smyslu slova o vlákně. Našel jsem třeba zmínky, že Linux se snaží vlákna v rozvlákněném procesu spouštět na jádrech v rámci jediné "patice" (numa uzlu) - ale "co když chci aby vlákna běžela napříč celým NUMA strojem a měla přehled o svých alokacích paměti" ? To je podle mého téma na další googlení (https://www.google.com/search?q=running+multi-threaded+on+numa), průzkum bojem a debatu v LKML. Náznak jsem zažil kdysi když jsem zjišťoval, jak si nechat probudit kernelovým timerem konkrétní vlákno (https://lkml.org/lkml/2010/10/17/181), tzn. nikoli celý proces. (Pozn.: syscall gettid() je tuším už normálně k dispozici i skrz glibc.) Všimněte si třeba nejednoznačného užívání termínů proces, vlákno a hlavně "task" - člověk musí pořád zkoumat, jestli se bavíme o user space, kernelu a na jaké úrovni abstrakce, jak to mapuje NPTL apod. Konkrétně: výše odkázaná manpage knihovny libnuma používá "task" ve smyslu rozvlákněný proces, kdežto v kernelu "struct task_struct" odpovídá jednotlivému user-space vláknu :-( Přesto se domnívám, že jestli je někde šance, tohle všechno rozplést a "nalinkovat po svém", tak je to v Linuxu. Jindy taktéž velice pokrokové FreeBSD zde patrně teprve dohání náskok (https://lists.freebsd.org/pipermail/freebsd-current/2018-January/068145.html).
S uvedenou problematikou volně souvisí další finta: snažit se, aby algoritmus pokud možno "běžel v CPU cache" - v rámci jednoho vlákna na konkrétním CPU jádře (popř. v rámci NUMA uzlu). Což je ovšem těžko splnitelné, pokud jsou data křížem krážem provázána odkazy (pointery) = úlohy typu "procházení rozsáhlého grafu" se takto optimalizovat z principu nedají :-( a budou vyžírat vždycky ty nejhorší latence.
Závěrem odkaz na jedno hezké PDF (https://www.cse.wustl.edu/~angelee/cse539/papers/numa.pdf) o těchto věcech...
-
Používal už někdo tady to ScaleMP? Vypadá to jako spása pro různá nasazení (neexistuje něco obdobného?). Může se o tom někdo rozvykládat? Mimo zajímalo by mě zda už existuje nějaký distribuovaný operační systém, který se nainstaloval na více serverů a následně by se chovali jako 1?
Řešíme totiž nyní jak jednoduše spouštět více stejných aplikací na různých servrech; jsou to to síťové aplikace a je potřeba zajistit jejich dostupnost ideálně z jedné ip a rozlišit mezi tím, který uživatel je zapnul / a přistupuje k nim (data by měly mít nějak vhodně synchronizovaná)
Pokud by se totiž, všechny počítače chovali jako jeden dohromady, tak by to řešilo hodně různých situací vcelku elegantně.
-
vcera prislo, spot price server je za par dolaru (tech ARM 96 jader ale moc rychle nepocita)
packet.net (http://packet.net)
The AMD EPYC Challenge
You all know how much we enjoy partnering up with our friends in the hardware ecosystem, and AMD has been no exception. Great people, great tech and that good old “AMD” vibe. With that spirit, we cooked up our own version of the Ice Bucket Challenge (remember that?).
Here’s the deal:
1. Try Your Workload on EPYC - We’ll give you $250 towards usage of our c2.medium config. Just fill out the form over here and you can kick the tires, courtesy of AMD and Packet.
2. Publish a Detailed Teardown - If you blog about your results, we’ll hook you up with $1500 in additional credit (while it lasts). The more technical the better! Not bad for a weekend, right?
3. Win EPYC For a Year - We’ll run a community Slack channel vote for the most impressive and geeky published results. The winner gets a pair of c2.medium machines, free for a year! Boom.
-
Používal už někdo tady to ScaleMP? Vypadá to jako spása pro různá nasazení (neexistuje něco obdobného?). Může se o tom někdo rozvykládat? Mimo zajímalo by mě zda už existuje nějaký distribuovaný operační systém, který se nainstaloval na více serverů a následně by se chovali jako 1?
Řešíme totiž nyní jak jednoduše spouštět více stejných aplikací na různých servrech; jsou to to síťové aplikace a je potřeba zajistit jejich dostupnost ideálně z jedné ip a rozlišit mezi tím, který uživatel je zapnul / a přistupuje k nim (data by měly mít nějak vhodně synchronizovaná)
Pokud by se totiž, všechny počítače chovali jako jeden dohromady, tak by to řešilo hodně různých situací vcelku elegantně.
hledal bych SSI (single system image)
openmosix
andy tanenbaum delal davno amoebu, ale to uz je dneska mrtvy system.
-
Hm > tak ten Mosix sice žije, ale nepodporuje vícevláknové aplikace (dle dokumentace, by to asi umělo dělat to co je potřeba). Openmosix je imho mrtvý.
Divím, se trochu tomu, že tohle není mnohem více používané a že v minulosti bylo spousta programů, ale nyní téměř žádné případně s restrikcí. Tušíte někdo kolik to scalemp stojí např pro 20 /60 CPU a zda je to možné nějak vyzkoušet?