Gitlab pipelines uruchamia się ze sporym opóźnieniem

Hej czy korzysta ktoś z gitlaba (hostowanego przez gitlaba) i obserwuje ostatnio spore opóźnienia w uruchamianiu pipelinów. W większości projektów używam własnych runnerów zainstalowanych na własnym serwerze. Mimo tego ostatnio obserwuję spore lagi w uruchomieniu pipelinu. Np. Przy 2 stagach wygląda to tak:

10 minut oczekiwania na start
stage 1 wykonuje się w 3 minuty
5 minut oczekiwania na stage 2
stage 2 robi się w 1 minutę

I tym sposobem deploy trwa prawie 20 minut z czego ~15 to oczekiwanie na odpalenie runnera. Da się to jakoś przyspieszyć?

Ok pozwolę sam sobie odpowiedzieć.

Okazało się, że jest to prawdopodobnie bug w gitlabie, który pojawia się, gdy mamy >1 runnera na danej maszynie. Workaround to ustawić w pliku /etc/gitlab-runner/config.toml pole concurrent na ilość większą niż mamy runnerów na maszynie.

Po tej zmianie wydaje się działać poprawnie.

Trochę z twojego opisu nie wygląda to na buga w gitlabie, ale mogę się mylić bo nie znam wszystkich twoich parametrów runnerów, gitlaba, ogólnie CI. Wcześniej też miałeś zdefiniowaną wartość concurrent ?. Z tego co napisałeś to na jednej maszynie masz zdefiniowanych kilka runnerów, i mogło się tak zdarzyć, że te przestoje były powodowane tym, że właśnie inne runnery obsługiwały już jakieś joby, przez co zapełniły limit równoległości na maszynie a runner który miał obsłużyć te joby musiał poczekać. Parametr concurrent odnosi się do całej maszyny, nie poszczególnych runnerów.

Tak wcześniej miałem ustawione na wartość domyślną czyli 1. Na tej maszynie mam wiele runnerów, ale w 95% tylko ja je odpalam i praktycznie nigdy nie odpalam 2 jobów na raz, a ten efekt o którym pisałem miałem zawsze i faktycznie wraz z kolejnymi runnerami coraz bardziej się wydłużał. Wygląda to tak, jakby dany runner np. przez minutę nasłuchiwał i potem przekazywał pałeczkę następnemu. Gdzieś na Gitlabie jest na to bug założony (wczoraj na niego trafiłem).

Możesz wrzucić linka do tego buga? Ogólnie to polecam poczytać doca gitlaba odnośnie korelacji pomiędzy concurrent, limit, oraz ilością runnerów na maszynie i jej korelacją interwałem odpytywania o joby do przetworzenia. Zobacz na sekcję check_interval. Jest tam opisany algorytm w jaki gitlab-runner odpytuje o joby i jak to się ma do ilości runnerów na maszynie w kontekście przestojów o których opisujesz. I jak najlepiej wykorzystać zasoby.

Niestety nie mogę tego buga znaleźć - wczoraj zeszło mi ponad godzinę na szukanie tego buga i znalazłem go w jakiś odmętach internetu. W sumie nawet nie wiem jaki miał status - pewnie jest tak jak piszesz, że to nie bug a feature.Dzięki za link - przeglądam bo runnery sobie ogarniałem na podstawie randomowych tutoriali i się nie wgłębiałem. Tak to jest jak się programista zabiera za devopsy ;-)

Możliwe, że to był ten ticket, który to jednak nie jest BUGiem po stronie gitlaba, tylko właśnie w konfiguracji runnera u osoby zgłaszającej ;). Jednak i Gitlab też czasami ma rózne wtopy i wcale bym się nie zdziwił, że mogło coś takiego wystąpić u nich. Jak się dłużej pracuje z Gitlabem to warto wiedzieć ogólnie "co jest na rzeczy" dlatego pytałem czy czasem nie masz do niego linka ;)