bloghoved ole tange

GNU-sjov med 48 cores og 0.5 TB RAM

Hvormange processer kan man egentlig køre på en GNU/Linux server?

Nå, jeg skal jo bruge min nye, brugte server til et eller andet. Så hvorfor ikke finde ud af, hvormange samtidige processer den kan klare?

Jeg starter med at ramme i nogle begrænsninger, men når de er ryddet af vejen så kan jeg køre:

#!/bin/bash

s() {  
  perl -e 'for(1..shift){ if(not fork()) { sleep 10000; exit } }' $@;  
}  
export -f s  
seq 193 | parallel s 10000

Det starter 193 * 10000 processer. OK, det er ikke det mest interessante program, men er programmet meget større, så løber jeg tør for RAM.

Herefter rammer jeg en grænse igen. Ved 1935253 +- 1000 går det galt: Der er en hård grænse, som jeg ikke kan finde ud af grunden til. Den er ikke den samme fra gang til gang.

Men det er en grænse per bruger, så hvis jeg logger ind som en anden bruger, kan jeg igen køre:

#!/bin/bash

s() {  
  perl -e 'for(1..shift){ if(not fork()) { sleep 10000; exit } }' $@;  
}  
export -f s  
seq 67 | parallel s 10000

Så er vi oppe på 2600000 processer, og så begynder der at komme en global grænse:

ProcesserStatus
2640682problemfrit - næsten alt kører normalt (se nedenfor)
2670685langsommere at starte og stoppe processer
2672266serveren stopper med at svare i visse terminaler og kan ikke køre flere programmer
2678008presset men overlever
2700727presset men overlever
2708174serveren stopper med at svare i visse terminaler og kan ikke køre flere programmer

Her er grænsen endnu mindre præcis end de 1935253.

Man kunne tro, at det skyldtes manglende RAM, men jeg kan køre:

$ \time -v perl -e '$a="x"x1000_000_000; for (1..10) { push @a,$t++.$a; }'

som bruger 10 GB RAM på 40 sekunder.

Når processerne alle dør på samme tid, så får maskinen lidt travlt:

18:56:13 up 22 min, load average: 2035025.72, 1167147.72, 482550.11

(Ja: et load på TO MILLIONER!)

Men skægt nok er den fint responsiv ved 2.6 Mproc.

Dog ikke, hvis man laver noget, der kikker på alle processer:

$ ls /proc | LC_ALL wc -l

tager 12 (tolv!) sekunder.

$ ps aux | LC_ALL wc -l

tager 4.5 minut.

Ctrl-C eller Ctrl-Z til en million processer tager også ret lang tid.

Nogle programmer går itu: pstree er helt død - det virker som om den laver noget O(n*n), og det går galt langt tidligere end 1 Mproc.

top og specielt htop piver gevaldigt. top kan opdatere hvert 10. minut - htop endnu sjældnere.

Under max load ser det sådan ud:

top 20:20:36 up  1:46 load average: 2707746.05, 2687605.06, 2184768.12  
Tasks: 2708372 total, 72623 running, 2635504 sleeping,   0 stopped  
%Cpu(s):  1.5 us, 97.5 sy,  0.0 ni,  0.0 id,  1.0 wa,  0.0 hi  
GiB Mem :  472.397 total,   16.104 free,  456.077 used,    0.215 cache  
GiB Swap:  300.098 total,  286.845 free,   13.254 used.   14.796 avail  

3562017 bash       27964   4420   4076 R 100.0  0.0   1:25.50 perl  
1267231 tange    3115520 2.898g   2360 R  37.9  0.6  29:02.45 top  
    380 root           0      0      0 D  14.4  0.0   6:16.22 kswapd3  
    384 root           0      0      0 S  14.2  0.0   6:07.50 kswapd7  
    381 root           0      0      0 D  12.2  0.0   5:11.82 kswapd4  
    382 root           0      0      0 S  10.7  0.0   4:00.30 kswapd5  
1807120 parallel   27964    288      0 D   7.8  0.0   1:41.64 perl  
1767502 parallel   27964    336      0 D   7.7  0.0   1:40.19 perl  
1745951 parallel   27964    292      0 D   6.3  0.0   1:22.81 perl  
1693199 parallel   27964    288      0 D   5.4  0.0   1:10.85 perl  
    383 root           0      0      0 S   5.4  0.0   3:38.04 kswapd6  
1733547 parallel   27964    332      0 D   4.4  0.0   0:57.30 perl  
1740658 parallel   27964    348      0 D   4.4  0.0   0:57.19 perl  
    377 root           0      0      0 S   4.1  0.0   2:19.27 kswapd0  
1776134 parallel   27964    328      0 D   3.1  0.0   0:40.75 perl  
1768307 bash       27964    348      0 D   2.6  0.0   0:33.72 perl  
1713869 parallel   27964    340      0 D   2.4  0.0   0:31.66 perl  
1729947 parallel   27964    344      0 D   1.5  0.0   0:20.23 perl  
   2330 gdm      7907136  48320  19128 S   1.5  0.0   6:32.17 gnome-sh  
1790073 parallel   27964    292      0 D   1.3  0.0   0:16.57 perl  
1760296 parallel   27964    308      0 D   1.2  0.0   0:15.58 perl  
1770488 parallel   27964    316      0 D   1.1  0.0   0:14.89 perl  
    310 root           0      0      0 S   1.0  0.0   0:41.90 khungtas  
1784486 bash       27964    316      0 D   1.0  0.0   0:12.76 perl

Hvornår har du sidst set top bruge 3 GB RAM?

Fork bomb

$ :(){ :|:;}  
$ :

Vi har vist alle prøvet det - og oplevet, at det skal man kun gøre, hvis man alligevel skal slukke for sin maskine.

Men med 48 cores så mærker man det næsten ikke - naturligvis bortset fra programmer, som kikker på hele processlisten (top, pstree, htop og lignende).

00:56:25 up 16 min, load average: 689967.88, 576005.24, 301198.60

Det er lidt uvirkeligt, at man uden problemer kan logge ind som en anden bruger og køre videre.

CPU speed

De 48 AMD 6174 cores er ikke just verdens hurtigste. En compile af Linux 4.4.2 tager 234 sekunder. Det er 15.4 compiles/hour og på linje med en EPYC 7302P (øverst i tabellen).

Men selv med 2.6 Mproc i baggrunden tager det kun 250 sekunder. Det er kun hvis man presser maskinen (som i tabellen ovenfor), at den bliver væsentlig langsommere: så tager start og specielt slut af en process ret lang tid. En compile tager nu 1178 sekunder.

Alt i alt er jeg positivt overrasket over, at 2.6 Mproc ikke sløver andre processer ned.

Hvad kan maskinen ellers bruges til

Jeg faldt i snak med nogle storage folk (ja, ZFS). De var imponerede over pris per GB RAM. Man får næppe nogen SSD eller RAID, der er lige så hurtig som middelmådig DDR3 RAM, så alene som cache bliver det interessant. ZFS vil desuden som tommelfingerregel gerne have 1 GB RAM til 1 TB disk, hvis den skal lave deduplication og sånonsmarte ting. Så gør det mindre om CPU'en ikke er et lyn. Med 0.5 TB RAM ville maskinen kunne være være storage server for 0.5 PB disk (med nogle externe disk arrays og nogle 10 Gbps kort naturligvis).

Men det er ikke lige et behov jeg har idag, så jeg slukker for min 48 core server for idag.

Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Andreas Rønne-Hansen

I forbindelse med mit studie (Matematik-Økonomi) skal jeg skrive et speciale, inden for området "stokastiske dynamiske ikke-lineære programmeringsproblemer" - dvs. noget med økonomisk og finansiel modellering.

I den forbindelse har jeg også købt en "regnemaskine" bestående af brugt server-hardware. Man kan virkeligt få noget der ryger ret højt på "flops/$" ratioen :)

Jeg har selv købt 2x Intel Xeon E5-2670 v3 (2stk. 12C/24T) m. 128 GB DDR4 RAM og et matchende motherboard. Massere af kerner, og så RAM nok til at jeg nok ikke helt tror jeg får brugt det hele.

Og derudover er der jo den fordel at serverhardware har mange PCI-E lanes, som kunne blive nyttige hvis jeg på et tidspunkt skulle give mig i kast med noget ML.

Og alt sammen inden for noget som kunne lade sig gøre på en studerendes økonomi, uden at jeg har forgældet mig resten af mine dage.

  • 5
  • 0
#3 Jonas Iversen

Det tilskynder gode folk til at kører svinske servere. Min I3 server bruger 25Watt, kører KVM/QEMU: VPN firewall, SQL server, web-server, Win10 virtual desktops (flere brugere) MariaDB server, Samba server m.v. ingen problemer! Hvis man ikke har behov for Xenon så lad hver med at ha' en server kørende på flere hundrede watt!

  • 3
  • 13
#4 Nis Schmidt

Ældre læsere husker sikkert Gotha Andersen's "Flid, fedt og snyd", som efter forårsemestret har vist sig nærmest profetisk. (Optaget er steget, men optagelses-gennemsnittet er faldet.)

L1I-cachen rummer per core: 512 linjer af 64 bytes. Så der kan højst køre 48 gange 512 = 12288 processer på server, hvis de skal have bare én cachelinje hver.

Så Oles "eksperiment" viser et aspect af det, der kaldes: "graceful degredation" på udenspansl. (Spild af tid, strøm og spalteplads.)

FF+S: https://www.youtube.com/watch?v=8NDX3H9-1J4

  • 0
  • 0
#5 Ole Tange Blogger

Det tilskynder gode folk til at kører svinske servere.

Jeg læste en undersøgelse for et par år siden: 80% af en desktops CO2-forbrug er sket, før du køber den. For laptops var tallet endnu højere, og forventligt er det endnu værre for mobiltelefoner, idet deres strømforbrug er ret lavt.

Det skyldes naturligvis at produktionen af hardware sviner ret meget. Derfor giver det mening at holde liv i desktops, laptops, og mobiltelefoner så længe som muligt.

Mit gæt er, at for servere er tallet lavere end 80%: Servere står normalt tændt 24/7, og har derfor et større CO2-udslip efter produktion end end en desktop, der kun er tændt 37 timer om ugen, men mit gæt er, at tallet stadig er af en væsentlig størrelse.

Så lad dig ikke forblænde af, at ḿoderne servere kan lave samme ydelse til mindre strømforbrug: Ud fra en samlet CO2-beregning kan det sagtens være bedre at holde liv i nogle gamle servere i nogle år mere. I hvert fald er det værd at lave helhedsberegningen, hvis målet er at være miljøvenlig.

Derudover er jeg sådan set enig i din grundpræmis: Strømprisen bør mindst dække, hvad det koster at rette op på den skade, som produktionen gør på miljøet.

I mit tilfælde kan du være ganske rolig: Som du ser af den sidste sætning i artiklen, så bliver min 48-core tændt, når jeg skal bruge den, men ellers er den slukket.

  • 8
  • 0
#6 Victoria Hansen

Jeg har en del af sådan nogle maskiner, og forsøgte på et tidspunkt at installere linux på den ene, lave en 120GB RAM disk, dele den via NFS, og så fra en anden tilsvarende maskine der kørte ESXi, kunne jeg mounte NFS drevet som et datastore, og på den måde installere en komplet Windows VM i ram på den anden maskine.

Til trods for 10GbE netkort, så kørte det ikke hurtigere end med SSDer, men det fungerede, og var ganske underholdende :)

  • 1
  • 0
#7 Jesper Frimann

@Ole Tange

Så lad dig ikke forblænde af, at ḿoderne servere kan lave samme ydelse til mindre strømforbrug: Ud fra en samlet CO2-beregning kan det sagtens være bedre at holde liv i nogle gamle servere i nogle år mere. I hvert fald er det værd at lave helhedsberegningen, hvis målet er at være miljøvenlig.

Når man nu bruger den så lidt, som du skriver du gør, kan det sagtens være rigtigt. Jeg fandt frem til det her estimat fra Dell selv om, hvor meget en server (2 socket) afgiver af CO2 over dens lifecycle.

https://i.dell.com/sites/csdocuments/CorpComm_Docs/en/carbon-footprint-p...

Her kan der nok også stilles en masse spg. mht. til 'grøn strøm' mv. i ovenstående, men tja ja. Det er da nok ikke helt ved siden af, sådan generelt. Personlig ville jeg nok ikke købe en gammel server, men istedet opgradere 'hvad der er nødvenigt' i min hjemmePC.

Og Ole, jeg kan ikke lade være, det er altså ikke en Brugt Ferrari, du har der, men nok nærmere en brugt Ford Transit fra 90'erne eller sådan noget. Hvis man bruger bil metaforen :)

// Jesper

  • 1
  • 0
#9 Jesper Frimann

En mere korrekt sammenligning ville være en Volvo FH16...

Det er jeg ikke helt enig i, altså at en 2U 4 socket x86 R815 fra 2010ish, igen når vi bruger bil metaforen, er at sammenligne med en Volvo FH16.

Du skal jo huske på at den skal sammenlignes med f.eks. en IBM x3950 (16 sockets) eller en DL980 fra HP. Og hvis man så virkelig beefer op så er der jo på samme tidspunkt servers som f.eks. den SPARC64 VII(+) basererede M9000 eller en POWER7 p795 mv. Servers som basalt var/er et datacenter in a can.

// Jesper

  • 0
  • 0
#10 Michael Cederberg

Med 0.5 TB RAM ville maskinen kunne være være storage server for 0.5 PB disk (med nogle externe disk arrays og nogle 10 Gbps kort naturligvis).

Men til ZFS har du ikke brug for alle dine kerner. De vil blot være idle hele tiden.

ZFS dedup er vist en anakronisme (disk space er billigt), så det er ikke en fornuftig brug af memory . Men ZFS er generelt glad for memory og hvis man har mod på at tweeke så kan 0.5Tb bruges som read cache og "write cache" (med en hurtig SLOG). På den måde kan man opnå extrem read og write performance. Men hvornår har man brug for at læse eller skrive 0.5Tb extremt hurtigt i et privat setup?

  • 0
  • 0
#11 Nis Schmidt

Processer hvis aktivitet mest består i at sove er ret uspændende. Gode gamle matrixmultiplikation er der lidt mere "kød" på.

Man kunne prøve to slags i forskellige (kvadratiske) størrelser:

Type 1. Traditionel matmul i sidestr 3000, 4000 og 5000, med 8 byte floating point celler - dobbelt sidestr for 4 byte celler.

Type 2. Liniær matmul i samme sidestr. Multiplikation af linier fra A med linier fra transponeret-B.

Det sjove ved AMD er at L1-cachene er 64 kB - mod Intels 32 kB.

Vi kan udvikle algoritmer sammen her.

Senere kan vi måske se på en klassisk SAMBA-server;-)

Går det godt, kan vi senere se på en mere genere SW-optimering.

Tanker?

  • 0
  • 0
#12 Poul-Henning Kamp Blogger

Du skal jo huske på at den skal sammenlignes med f.eks. en IBM x3950 (16 sockets) eller en DL980 fra HP.

Da vi indkøbte fem stk. af disse 48-core "Magny-Cours" maskiner i for ti år siden, var de den eneste maskine på markedet der havde CPU kraft nok til at lave real-tids adaptiv optik på ESO's ELT teleskop.

Idag løser vi samme opgave med en dual-socket Epyc maskine.

Så jo: Vi er i Volvo FH16 territoriet.

Det kan godt være der var maskiner der havde hurtigere CPU, men der var ingen der havde større RAM-båndbredde.

  • 0
  • 0
#13 Jesper Frimann

Da vi indkøbte fem stk. af disse 48-core "Magny-Cours" maskiner i for ti år siden, var de den eneste maskine på markedet der havde CPU kraft nok til at lave real-tids adaptiv optik på ESO's ELT teleskop.

Idag løser vi samme opgave med en dual-socket Epyc maskine.

Jeg tvivler slet ikke på at en r815 på det tidspunkt var den rigtige maskien for 'jer'.

Men igen så snakker vi en 4 socket x86 fra 2010ish, et tidspunkt hvor du altså kunne få UNIX servers, der var i en helt anden klasse. Hvis du f.eks. sammenligner med en POWER 795 fra 2010, med 32 socket 256 cores 4TB RAM og op til 640 PCIe slots. Så er du altså i en helt anden klasse, på alle parametre. (ikke mindst pris).

Så hvis sætter baren efter hele servermarkedet på det tidspunkt, så bliver en 4 socket R815, altså aldrig mere end en Kassevogn, sammenlignet med 'de store lastbiler'.

Så jo: Vi er i Volvo FH16 territoriet.Det kan godt være der var maskiner der havde hurtigere CPU, men der var ingen der havde større RAM-båndbredde.

Men igen kontekst er vigtigt. Og igen så brugte Ole oprindelig eksotiske håndbyggede sportsvogne som metafor, derfor er det nok også relevant at se på Servers i servermarkedet, der ikke lige var/er mainstream.

Men hvis du siger x86 server segmentet, ja så er jeg enig i at på daværende tidspunkt var en R815 en lastvogn i 'det server segment'.

// Jesper

  • 0
  • 0
Log ind eller Opret konto for at kommentere