atc

UI freezes are completely client side and related to the elm implementation and your browser's execution of the code. The size of your VM doesn't matter at all. ATC is a more of a dependency scheduler. The code [1] shows that it basically gets all pending jobs, and then runs them. There's no concept of queueing or maximum number of jobs, you just have to hope your limits are high enough (max containers, max tasks in systemd, max fds in the same) and that your machine doesn't fall over in the attempts. The "massive" scheduling system also has no idea what nodes need work and which do not [2] so the idea is to heavily overprovision until it doesn't fall over (on top of already beefy requirements which others have alluded to in this thread). You can not serialize multiple pipelines. Only within pipelines. If I have 10 pipelines, they will al

> However it performs like a dud. No scheduling to speak of, just runs everything as soon as it can. We've run into nodes dying under load (-not- underprovisioned, could run all these jobs manually at once on these monsters). We've run into problems with volume reaping, fork bombs, ui freezes, everything under the sun. I've used concourse as a consumer for 3 years and I've very, very rarely seen any of the problems you're describing, even on the older versions and certainly not in the last year or so. > no scheduling to speak of Concourse has a massive scheduling system built into it.. https://github.com/concourse/atc Furthermore, you can configure jobs to run in serial (default is parallel). > ui freezes Put your `web` binary on a decently-sized VM and your problem should disappear. Also, don't have your workers on the same VM as your `w