potiuk commented on issue #35806: URL: https://github.com/apache/airflow/issues/35806#issuecomment-1828080424
And just to explain it - as I see it now. The problem is precisely as you described it, your description very well describes the unintended behaviour here - and resulting bursts of triggerer doing stuff (but then pausing) potentially. The whole Idea of triggerer loop is to make sure triggers are fired as soon as they happen. But limiting the CPU for it, hampers its ability of doing so. The whole purpose of enabling Triggerer is to free resources for everyone else so that triggerer can process triggers and tight event loop and invole the (workers mainly) to be triggered as soo as possible and then Auto-Pilot should automatically scale them up as they are needed (via auto-pilot mechanisms). So having a busy and working triggerer that is run on an instance that it can rely on having 1 CPU is crucial to process things as soon as possible and scale them as soon as possible. This way you save a lot on the workers (who do not have to take busy slots for waiting tasks in sensors for example or for constant serializing/deserializing to just check what happened). The price to pay is to have Triggerer that has 1 CPU available and can "command" the deferred workers to be woken up and deserialized as soon as an event happened. With 250ms it means that it will work in bursts. and if it happens that it takes 300 ms to process a single trigger event it will automatically get delayed by almost a second extra (and potentially the efects of it might compound). So having request CPU = 1 makes sense in this case. And of course If you have an idea how to improve it for lower limits - I think you are still free to do it, though I see setting CPU limit to < 1 makes very little sense. Maybe you could come up with a proposal to only include active time in the calculations - it should be possible, I think. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
