benchmarkok
A 10 GB-os gyorsítótár-korlát az igazi CI szűk keresztmetszet
40 000 munkafolyamatot műszereztünk. A gyorsítótár viselkedése jobban megjósolta a fali órát, mint a vCPU-szám, és a legtöbb csapat átlépi a határt anélkül, hogy észrevenné.
Tomás Rivera · Teljesítménytechnika · 2026-07-02 · 9 perc olvasás
A GitHub Actions-ban van egy hibaüzemmód, amely nem produkál hibát, figyelmeztetést és naplósort. Az adattár 10 GB gyorsítótárat tesz át, a legkevésbé használt bejegyzések kiürítésre kerülnek, és attól a naptól kezdve a futtatások egy része csendesen lehűl.
Senki nem kap lapot ezért. Az építkezés még mindig megy. Csak lassabb, örökké, és mire bárki megvizsgálja a változást, már hat hónapos.
Amit mértünk
A bekapcsolt adattárak 40 000 futtatása során rögzítettük a gyorsítótár találati arányát, a visszaállítás időtartamát, a futó méretét és a teljes falióra-időt. Két dolog tűnt fel.
A második eredmény a gyakorlatiasabb: nagyjából 80% alatti a gyorsítótár találati aránya, a vCPU-k hozzáadásával alig mozgatták meg a teljes folyamatidőt. A csapatok nagyobb gépeket vásároltak, hogy kompenzálják a hideg gyorsítótárakat, ami közel áll a probléma legdrágább megoldásához.
A visszaállítási sebesség ugyanolyan fontos, mint a találati arány
Az a gyorsítótár, amelynek helyreállítása négy percet vesz igénybe, és három perc munkát takarít meg, nettó veszteséget jelent, és 100%-os találati arányt jelent, miközben időt veszít. Több adattárat is láttunk pontosan ebben az állapotban.
Mit kell tenni ellene
- Mérje meg a teljes gyorsítótár méretét tárhelyenként – a legtöbb csapat soha nem nézett rá
- Mérje meg a visszaállítás időtartamát, ne csak a találati arányt
- Nagyobb futók vásárlása előtt javítsa ki a gyorsítótár kulcsait
- Ha szerkezetileg több mint 10 GB, akkor a kupak a probléma, és semmilyen kulcs nem fogja megoldani
A következő buildje kétszer gyorsabb lehet, fele áron
Kezdje ingyen. A távozás ugyanaz az egy sor, és azt a diffet is közzétesszük.