Great suggestions! I woke up this morning with another fix which I'll try (Moving the script from the cifs to the local file system) although RudiC might be onto something to troubleshoot.

This is an outside managed system which doesn't cover backup and the local VM of this entire server runs here with the very same results so its definitely something in the script.

Will report back shortly with results of suggestions.

---------- Post updated at 08:32 AM ---------- Previous update was at 08:12 AM ----------

# Suspend the database
uv -admin -L
# Validate the database
uv -admin -R
#Sync any cached data back to disk
sync


I ran each of these separately to see when the uvsh processes would go nuts (Best info I can come up with to describe what's happening).

uv -admin -L (File suspension happens, no issue)
uv -admin -R (Validation happens, although quickly, Id expect it to take longer than a blip then prompt)

sync, now is when the multiple uvsh processes pop up and what I'm suspecting is the major performance drag, incomplete process etc.

Not wanting to think ahead on this just want to report what Ive found by breaking each part of the script down to manual cli entry and report back.

I'll try the /dev/null and see what happens now.

Decided to watch and see what happens, its definitely the sync'ing of the database command to the server that's causing it (This is not the case actually). I'm now curious why this is happening as it either is something that must be done, fully no matter how long it takes, or is a flag of an issue we're not aware of in the system (Which I doubt.. I know its a reach).