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:
| Processer | Status |
|---|---|
| 2640682 | problemfrit - næsten alt kører normalt (se nedenfor) |
| 2670685 | langsommere at starte og stoppe processer |
| 2672266 | serveren stopper med at svare i visse terminaler og kan ikke køre flere programmer |
| 2678008 | presset men overlever |
| 2700727 | presset men overlever |
| 2708174 | serveren 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?
$ :(){ :|:;}
$ :
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.
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.
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.
Den tænder jeg kun når solcellerne laver strøm.
En ting jeg bruger min maskine til er benchmarks: Når man kan lave en ramdisk der er stor nok til at have "det hele" bliver falder standard afvigelsen på benchmarks markant og de kører som regel, men ikke altid lidt hurtigere.
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.
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!
Æ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.)
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.
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 :)
@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
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
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?
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?
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.
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
