De geheugenreservering van de allocatie groeide 104 GB na de domeinmigratie, terwijl het werkelijke gebruik gelijk bleef

[jipclaassens]

De migratie van de trede en de zeef naar 25 meter in #759 heeft de rekentijd verkort en het werkelijke geheugengebruik ongemoeid gelaten, maar de reservering fors verhoogd. Dit issue is om die reservering te begrijpen en terug te brengen.

Gemeten

Hetzelfde zichtjaar, dezelfde machine (OVSRV08, 32 kernen, 128 GB, wisselbestand 600 GB), uit de staart van de allocatielogs in batch/log/run2120:

	29 augustus, voor 786f862	4 september, na 786f862
Highest CommitCharge	213 GB	317 GB
Highest allocated	197 GB	185 GB
rekentijd BAU Y2040	69 min	49 min

De migratie is dus op twee van de drie assen een verbetering: 29 procent sneller en 12 GB minder werkelijk toegewezen. Wat groeide is de reservering, met 104 GB. Het gat tussen gereserveerd en toegewezen is daarmee 132 GB.

Ter aanvulling: NbSGenuanceerd Y2040 op 4 september piekt op 368 GB CommitCharge in 61 minuten. Daar zit de waterbergingsallocatie bij die BAU niet heeft.

Waarom dit toch aandacht verdient

Op deze machine gaat het goed, want het wisselbestand is 600 GB. Maar 317 GB reservering voor een run die 185 GB gebruikt betekent dat de configuratie op een machine met een kleiner wisselbestand omvalt zonder dat er iets mis is met de berekening. Dat is een onnodige eis aan de omgeving, en het maakt de run gevoelig voor een tweede proces ernaast.

Waar het vandaan komt

De richting is bekend, de details niet. Alleen Templates/VariantData_T/Trede.dms ging van 184 items op AllocDomain naar 185 op AdminDomain, en een cel van 100 meter telt 9,1 miljoen keer tegen 145,6 miljoen op 25 meter. Als bool gerekend is dat voor dat ene bestand ongeveer 1,7 tegenover 26,9 GB. De commit raakte negentien bestanden.

Dat verklaart waarom er meer wordt gereserveerd, maar niet waarom het werkelijke gebruik gelijk blijft. Kennelijk worden lang niet alle tredevlaggen tegelijk vastgehouden. De vraag is dan of de reservering die ruimte wel opeist terwijl zij hem niet nodig heeft.

Aanknopingspunten

Geen daarvan is onderzocht; het is een lijstje om mee te beginnen.

1. De log noemt zelf Highest uncommitted: 55750 MB op 29 augustus. Kijk wat die post in de nieuwe situatie is en of de groei daarin zit.
2. Veel van de 185 tredevlaggen zijn bool. Een bitset of een samengesteld klasse-attribuut in plaats van een attribuut per vlag scheelt direct een factor.
3. De vlaggen per sector of per sequentie opbouwen en loslaten in plaats van als blok.
4. Niet elke laag hoeft op 25 meter. De fout die De allocatie is sinds #508 op 25 meter, maar 527 items staan nog op het domein van 100 meter #759 oploste was een toets die op 25 meter besliste met een antwoord van 100 meter; lagen die alleen als grove context dienen kunnen grof blijven, mits ze nergens met een fijne toets worden gemengd.

Voorbehoud bij de aanleiding

Dit issue verving een eerdere formulering van mij waarin stond dat het geheugen van 70 naar 180 GB ging. Dat klopte niet: die 70 GB was de werkset van de lopende run op een willekeurig moment en geen meting van een eerdere run. De vergelijking hierboven is wel like-for-like, uit de logstaarten van beide runs.

Zie #771, dat op deze meting is gesloten, en #770 voor de correctheidskant van dezelfde commit.

[jipclaassens]

Doorgevoerd in commit bdddee9 op NL2120.

De reservering zat in de opbouw van de tredeladder, en die is omgebouwd. Gemeten op de testkopie, GeoDms20.17.0.m, dezelfde machine als de allocatielogs.

Waar de 104 GB vandaan kwam

Templates/VariantData/Trede_T bouwde de ladder als een ArgMin over een attribuut per klasse: Klassen/<klasse> is per cel de klasse-index waar alle asvlaggen waar zijn en anders null, als uint32. Een ladder voor wonen heeft 144 klassen, voor detailhandel 288 en voor NbSGenuanceerd tot 432. Op AllocDomain was dat 9,1 miljoen cellen maal vier bytes maal 144, ruim 5 GB per ladder; op AdminDomain is het 145,6 miljoen cellen, dus 84 GB per ladder. De trede staat sinds #759 op AdminDomain, en Zichtjaar_T/TredeDynamischeUrbanContour bouwt de ladders per zichtjaar opnieuw op. Dat verklaart de sprong in de reservering, en ook waarom het werkelijke gebruik gelijk bleef: GeoDMS rekent per tegel en houdt de 144 attributen niet tegelijk vast, maar reserveert er wel ruimte voor.

Wat er nu staat

De ladder wordt per as opgebouwd. Elke as levert een uint8 per cel met de eerste ware klasse van die as (Impl/Assen/PerAs/<as>/Index), en de klasse-index is de mixed-radix som van die asindices, in dezelfde volgorde als combine: het eerste argument telt het zwaarst. Dat is rekenkundig gelijk aan de ArgMin over de conjuncties, want die conjuncties zijn het cartesisch product van de asvlaggen, en het kost een handvol bytes per cel in plaats van een uint32 per klasse.

De assen worden uit de combine-unit zelf afgelezen, via de first_rel, second_rel enzovoort die combine aanmaakt, met unique voor de asklassen en de pijl naar RefSrc voor de vlagexpressie. Een nieuwe as of een andere volgorde in VariantParameters/Tredes komt zo vanzelf mee. Een alias als NbSMax := BAU wordt via PropValue tot twee niveaus gevolgd. Twee assen waren zelf een alias van een classificatie-unit, UrbanContourK en BouwregimeK; de pijl volgt zo'n alias tot de onderliggende classificatie, waar RefSrc niet staat. Die twee zijn nu eigen units met de namen van de classificatie.

Klassen staat er nog, alleen voor de visualisatie per klasse; niemand rekent er meer mee.

Meting

Vier ladders in een aanroep, als tif op AdminDomain weggeschreven met het meetharnas van #759: wonen eengezins vrije sector in BAU en NbSGenuanceerd, zakelijke dienstverlening en nijverheid in BAU. De logstaart van GeoDmsRun, dus dezelfde bron als de tabel in het issue.

	oud (ArgMin per klasse)	nieuw (per as)
Highest CommitCharge	166.033 MB	8.439 MB
Highest allocated	2.797 MB	4.656 MB
rekentijd vier ladders	400 s	43 s

De uitkomst is gelijk: op alle vier de ladders verschilt geen enkele van de 145,6 miljoen cellen, en de klassenlijsten zijn identiek. Daarnaast schrijft het harnas voor alle 44 combinaties van variant en subsector de ladderexpressie en de vlagexpressies per as weg; de kardinaliteiten per as vermenigvuldigen overal tot het klassenaantal (4x2x3x3x2 is 144, 2x4x2x3x3x2 is 288, 2x4x3x3x3x2 is 432), ook door de aliassen heen.

Het werkelijke gebruik ligt iets hoger omdat de asindices nu als attribuut bestaan; dat is een uint8 per cel per as, dus 146 MB per as, en die staan in de plaats van de conjuncties.

Wat dit voor de reeks betekent

De productiereeks is hier niet mee gedraaid; de tabel hierboven is een meting van de ladders los, niet van een zichtjaar. De verwachting is dat de reservering van een allocatie terugvalt naar de orde van voor 786f862, want van de negentien bestanden die die commit raakte is Trede.dms het enige dat honderdduizenden cellen per klasse aanmaakt. De eerste volledige allocatie na deze wijziging hoort de logstaart naast de 213 en 317 GB uit het issue te leggen.

Aanknopingspunt 4 uit het issue (niet elke laag hoeft op 25 meter) is hiermee niet gevolgd, en dat is bewust: de vlaggen zijn goedkoop, het waren de klassen die de reservering maakten.

Openstaande punten Object Vision

• de logstaart van de eerstvolgende allocatierun naast de 317 GB van 4 september leggen, om te bevestigen dat de reservering terug is

[jipclaassens]

Bevestigd in een volledige allocatie. BAU, zichtjaar Y2040, alle zeven sectorregels, op dezelfde machine als de metingen in het issue.

	29 augustus, voor #759	4 september, na #759	nu, na #775
Highest CommitCharge	218.328 MB	324.378 MB	201.893 MB
Highest allocated	202.232 MB	189.358 MB	187.842 MB
rekentijd	4.195 s	2.988 s	2.630 s

De reservering is daarmee niet alleen terug van de 104 GB die #759 erbij zette, maar komt 16 GB onder het niveau van voor de migratie uit. Het werkelijke gebruik blijft waar het was. De rekentijd is 12 procent korter dan die van 4 september; het verschil met de 4.195 s van 29 augustus komt van de tussenliggende wijzigingen en niet van deze commit.

De run van 4 september is 20260904_035902_allocatie-BAU-Y2040.log in batch/log/run2120 van de productiekopie, die van nu draaide in de testkopie op commit 774850dc met dezelfde casus, hetzelfde zichtjaar en dezelfde ontkoppelde basisdata.

Wat de reservering nu bepaalt is dus niet meer de tredeladder. Wie hem verder omlaag wil brengen moet naar de allocatie zelf kijken, niet naar de trede.

Wat mij betreft kan dit issue dicht.