Hi,
I have found previous questions that relate to this issue, but not an answer.
I am on the latest build of Octopus Server (I have just upgraded tonight). All tentacles are on the latest build too.
I am running 20 deployments in parallel. The task cap has been raised to 20.
All 20 kick off at the same time, but progressively as I look through the task, they are each waiting on a task in a different deployment to finish eg “Waiting for the script in task ServerTasks-XXXXX to finish as that script requires that no other Octopus scripts are executing on this target at the same time.”
What can I change to prevent this. I need them all to be running in parallel with each other, otherwise the deployment takes too long.
I should mention the steps are mostly child steps, not sure if that is what is causing the issue, but I would still not expect one deployment to wait for another one.
Greetings, thanks for reaching out! Would you be able to tell me if all 20 deployments are going against the same target? Is it the target or are workers also getting this?
What you’re encountering is called deployment mutex (Run multiple processes on a target simultaneously - Octopus Deploy). Octopus is designed to have only one task against the same target at a time in order to protect two deployments from simultaneously altering the same file. The best example is to think of the IIS metabase (from older IIS versions), if two deployments were trying to update it at the same time, it would wreak havoc.
That being said, you’re on the right track thinking of workers, especially for databases. Workers can run multiple processes at the same time, so you wouldn’t run into the mutex issue (there are some exceptions, but it would be better). In addition, workers don’t count against your license, so you can have as many as you want. Databases are one of the perfect use cases for workers. It also comes with the added benefit of not needing the Tentacle software on the database server itself. Does that make sense?
Thanks Shaun.
I found the mutex variables and updated them for my project and guess what. It wreaked havok!
I think I can change my process to be better, and may revisit turning them back on again. I will also investigate workers (and setting them up).
Thanks again for your help.
Wow. Thats a very kind gesture, thanks so much for that offer.
I think I am good for now. The minute I actually did get it running in parallel(eg mutex), it highlighted so much to me that I need to change, but I know what I need to do with that. At some stage (possibly months away) I may need to look at workers, but for now, I think I am good.
Thanks again so much for your help.
