Whilst avtar might be a particularly 'demanding' user of the file system as it walks through the files and processes the changed ones, it's just one user. A busy file server may have a large number of other users concurrently writing or updating files. Also be aware that avtar's priority is set to below average so we could reasonably expect non-avtar requests to be served with much more 'gusto'.
I discussed avtar prioritisation with Engineering a while back and documented the following in KB 335284
CPU Process Prioritization
- The avagent process automatically sets all processes it spawns to be at a nice level.
- In Linux, priority levels range from -20 to 20, where -20 is the highest priority .
- By default, processes are spawned with priority 0.
- Avtar is created with priority 10, which is much lower than the default priority.
- Windows manages priority levels ranging from 1 (lowest) to 31 (highest).
- Avtar is created with BELOW_NORMAL_PRIORITY_CLASS, which means that threads owned by avtar by default are created with priority 6.
- For reference, threads created by processes on Windows have a default priority of 8.
This is more likely to be a challenge if the data-set is so large or high-change that it can't be backed up within the quiet hours of the day.
Edit: The KB article also refers to Avamar bug 240762 where we discussed with Engineering the possibility of providing a flag to tune avtar's priority to be more or less 'polite'. Unfortunately, although it's possible to change the CPU priority for the process, Engineering found that doing this didn't affect the I/O priority, at least on Windows... and since providing such a flag wouldn't have yielded the desired benefit it was decided to not implement it.
Avtar priority levels aside, exhausting all the regular options (KB 335029) to hunt out bottlnecks is advised if you haven't already travelled that route.
Thank you for the reply - very good information.
FWIW, in this particular situation, it isn't so much a case of wanting a higher priority for avtar - it is more a case of understanding whether avtar is "performing at its full potential" in terms of what else might be running on the system, especially relative to what else might be accessing the same disks as avtar.
I have been using the KB listed to investigate the performance issues, but unfortunately in many cases, we don't just have to prove that the Dell EMC side isn't the issue - we have to point out what the actual issue is in order for the customer to acknowledge our findings that it wasn't the Dell EMC side.