While NetWorker 7.6 is not available for download as of the time I write this, the documentation is available on PowerLink. For those of you chomping at the bit to at least read up on NetWorker 7.6, now is the time to wander over to PowerLink delve into the documentation.
The last couple of releases of NetWorker have been interesting for me when it comes to beta testing. In particular, I’ve let colleagues delve into VCB functionality, etc., and I’ve stuck to “niggly” things – e.g., checking for bugs that have caused us and our customers problems in earlier versions, focusing on the command line, etc.
For 7.6 I also decided to revisit the documentation, particularly in light of some of the comments that regularly appear on the NetWorker mailing list about the sorry state of the Performance Tuning and Optimisation Guide.
It’s pleasing, now that the documentation is out, to read the revised and up to date version of the Performance Tuning Guide. Regularly critics of the guide for instance will be pleased to note that FDDI does not appear once. Not once.
Does it contain every possible useful piece of information that you might use when trying to optimise your environment? No, of course not – nor should it. Everyone’s environment will differ in a multitude of ways. Any random system patch can affect performance. A single dodgy NIC can affect performance. A single misconfigured LUN or SAN port can affect performance.
Instead, the document now focuses on providing a high level overview of performance optimisation techniques.
Additionally, recommendations and figures have been updated to support current technology. For instance:
- There’s a plethora of information on PCI-X vs PCIeXpress.
- RAM guidelines for the server based on the number of clients has been updated.
- NMC finally gets a mention as a resource hog! (Obviously, that’s not the words used, but it’s the implication for larger environments. I’ve been increasingly encouraging larger customers to put NMC on a separate host for this reason.)
- There’s a whole chunk on client parallelism optimisation, both for the clients and the backup server itself.
I don’t think this document is perfect, but if we’re looking at the old document vs the new, and the old document scored a 1 out of 10 on the relevancy front, this at least scores a 7 or so, which is a vast improvement.
Oh, one final point – with the documentation now explicitly stating:
The best approach for client parallelism values is:
– For regular clients, use the lowest possible parallelism settings to best balance between the number of save sets and throughput.
– For the backup server, set highest possible client parallelism to ensure that index backups are not delayed. This ensures that groups complete as they should.
Often backup delays occur when client parallelism is set too low for the NetWorker server. The best approach to optimize NetWorker client performance is to eliminate client parallelism, reduce it to 1, and increase the parallelism based on client hardware and data configuration.
(My emphasis)
Isn’t it time that the default client parallelism value were decreased from the ridiculously high 12 to 1, and we got everyone to actually think about performance tuning? I was overjoyed when I’d originally heard that the (previous) default parallelism value of 4 was going to be changed, then horrified when I found out it was being revised up, to 12, rather than down to 1.
Anyway, if you’ve previously dismissed the Performance Tuning Guide as being hopelessly out of date, it’s time to go back and re-read it. You might like the changes.
Preston,
To your knowledge, does the 7.6 Performance Tuning Guide contain much information geared particularly towards that revision of NetWorker (7.6)? I have tried and found the performance guides of yore wanting. I’m currently running 7.4.5.
I don’t believe there’s any content in the 7.6 performance tuning guide specific to that release – it remains a general purpose guide that should be relevant to any admin running a 7.3 or higher system.
(It’s safe to say that 7.2 or lower would be a different kettle of fish, as the introduction of nsrjobd played a significant part of adjusting the way performance is handled in NetWorker.)
Why do you propose decreasing default parallelism setting to 1?
I think default parallelism setting of 4 is a good starting point.
That places an awful large onus on the client to keep tape moving in the drive at maximum speed.
/C
The reason I think it should be set to 1 by default is that it forces administrators to actually think about the appropriate parallelism settings for each system, rather than running with defaults that can push systems beyond reasonable limits in terms of resources. By forcing administrators into thinking about the implications of adjusting the parallelism settings, you’d find that a lot of sites would run more smoothly as performance tuning would then become something done by default, as part of client setup.