De cachelimiet van 10 GB is het echte CI-knelpunt

Er is een foutmodus in GitHub Actions die geen fout, geen waarschuwing en geen logregel produceert. Je repository overschrijdt de cache van 10 GB, de minst recent gebruikte vermeldingen worden uitgezet en vanaf die dag begint een deel van je runs stilletjes koud.

Niemand wordt hiervoor opgeroepen. De bouw gaat nog steeds door. Het is alleen langzamer, voor altijd, en tegen de tijd dat iemand de verandering onderzoekt, is deze zes maanden oud.

Wat we hebben gemeten

Bij de 40.000 uitvoeringen op opslagplaatsen die zich hiervoor hadden aangemeld, hebben we het cachetrefferpercentage, de herstelduur, de runnergrootte en de totale wandkloktijd geregistreerd. Twee dingen vielen op.

De tweede bevinding is de meest bruikbare: bij een cachetrefferpercentage van ongeveer 80% zorgde het toevoegen van vCPU's er nauwelijks voor dat de totale pijplijntijd werd verplaatst. Teams kochten grotere machines om koude caches te compenseren, wat bijna de duurste manier is om dat probleem op te lossen.

Herstelsnelheid is net zo belangrijk als het aantal treffers

Een cache die vier minuten nodig heeft om te herstellen en drie minuten werk bespaart, is een nettoverlies en rapporteert een trefferpercentage van 100% terwijl u tijd verliest. We hebben verschillende opslagplaatsen gezien die precies in deze staat verkeerden.

Wat eraan te doen

1. Meet de totale cachegrootte per repository; de meeste teams hebben er nog nooit naar gekeken
2. Meet de herstelduur, niet alleen de hitrate
3. Herstel cachesleutels voordat u grotere hardlopers koopt
4. Als je structureel meer dan 10 GB hebt, is de cap het probleem en kan geen enkele sleutel dit oplossen