Thanks again for reporting the issue and for sharing your example.
After reviewing, we confirmed that both servers have the same tool version and resources allocated. The difference is that the EU server’s really large clusters (needed for this tool) happen to be very busy right now. This means that a job like yours that runs on the largest clusters will queue for a much longer time. The size of the inputs do not really matter – the resource use is mostly related to the massive indexes.
What to do
Please leave these jobs queued and avoid re-running.
All new jobs are added back to the end of the queue again. If deleted and rerun often enough, the job may never get a chance to run!
My test job from Wednesday at the EU server is still queued too. I’ll watch to over the weekend and your history too if you leave it shared.
Job execute as resources become available so it is difficult to predict the exact timing. Much depends on the cluster load at any particular time. By chance, the ORG server was “faster” but don’t rely on that always being true.
Tools that utilize the very largest clusters will queue the longest. Why? Because the currently processing jobs tend to take longer to complete which leads to slower turnover for new jobs.
I’ll also leave this quote below as a reference for anyone that happens to read this topic later on.
Thanks again and feel free to ask for an update next week! 