UNSOLVED
A
AndrewGraySparq
2 Posts
0
1974
March 13th, 2012 23:00
server_param command returning error
In the VNX documentation "Configuring NDMP Backups on VNX 7.0", it mentions a bunch of possible performance tuning options on page 75 of that document. Eg, it suggests tuning paxWriteBuf to 256.
However, when running the command to make the change, an error comes back as follows:
[nas@nas01 ~]$ server_param server_2 -facility PAX -modify nThread -value 128
server_2 :
Error 2225: server_2 : : invalid operation
Am I completely missing the plot here? It's like I'm on the wrong version or something. I've tried to find this parameter in the output of the command:
server_param server_2 -facility PAX -list
But it doesn't list it. What am I doing wrong with tuning the performance here? Why doesn't this command work?
The reason I am doing this is because our backup performance to LTO4 Tape drives is maxing out at 170GB/hour, which is less than half the speed we should be getting, and more often than not, it's much less. We are Using CommVault v9 to initiate the NDMP backups but we can't get it to perform. Any ideas on how to get these backups to start approaching LTO4 speeds?
Your help is much appreciated.
-A
492
0
Posted April 9th, 2012 15:00
Thanks for that. Really though? Why would they put instructions for changing this parameter in a user guide?
492
0
Posted April 9th, 2012 18:00
hmm..i can change it ok on my 5700
[nasadmin@vnx5700~]$ server_param server_2 -facility PAX -list
server_2 :
param_name facility default current configured
checkUtf8Filenames PAX 1 1
dump PAX 0 0
readWriteBlockSizeInKB PAX 64 64
nPrefetch PAX 8 8
nThread PAX 64 64
filter.dialect PAX
writeToArch PAX 1 1
filter.numDirFilter PAX 5 5
filter.caseSensitive PAX 1 1
filter.numFileFilter PAX 5 5
paxWriteBuff PAX 64 64
nFTSThreads PAX 8 8
paxReadBuff PAX 64 64
paxStatBuff PAX 128 128
writeToTape PAX 1 1
noFileStreams PAX 0 0
scanOnRestore PAX 1 1
nRestore PAX 8 8
allowVLCRestoreToUFS PAX 0 0
[nasadmin@vnx5700 ~]$ server_param server_2 -facility PAX -modify nThread -value 128
server_2 : done
[nasadmin@vnx5700 ~]$
492
0
Posted April 9th, 2012 19:00
you have a lemon 5700 , can you return it ?
492
0
Posted April 9th, 2012 19:00
The 5700 i have in the lab running the latest code does not have it:
[nasadmin@BottleCapsCS0 ~]$ server_param server_2 -f PAX -l
server_2 :
param_name facility default current configured
checkUtf8Filenames PAX 1 1
dump PAX 0 0
readWriteBlockSizeInKB PAX 64 64
filter.dialect PAX
writeToArch PAX 1 1
filter.numDirFilter PAX 5 5
filter.caseSensitive PAX 1 1
filter.numFileFilter PAX 5 5
paxStatBuff PAX 128 128
writeToTape PAX 1 1
noFileStreams PAX 0 0
scanOnRestore PAX 1 1
nRestore PAX 8 8
allowVLCRestoreToUFS PAX 0 0[nasadmin@BottleCapsCS0 ~]$ server_param server_2 -f PAX -i nThread -v
server_2 :
Error 2111: server_2 : Unsupported argument: nThreadI can adjust it using the debug commands (of which i'm not allowed to give out) so i know its there, it's just not customer setable through server_param.
377
0
Posted April 10th, 2012 06:00
why was it removed, incorrectly set values were causing more harm than good ?
366
0
Posted April 10th, 2012 06:00
Starting with 6.0.42.1 and 7.0.27.1 code, this param along with a few other NDMP related params were changed from public user-tunable to private.
492
0
Posted April 10th, 2012 06:00
That explains it. These paramaters have been removed from being customer setable in the more recent code. In addition, the latest paramater guide reflects this AND the latest NDMP guide has the Tune Backup and restore paramaters flow chart removed. This is the section that Andrew was refering to above on page 75 of the OLD document.
492
0
Posted April 10th, 2012 06:00
really old, back from august.
251
0
Posted April 10th, 2012 06:00
Yes. If these values are set too high, it can cause the DM to use too much memory and panic.
They can still be tweaked using internal commands by Support if needed though.
sthulin
2 Intern
•
181 Posts
492
0
Posted April 3rd, 2012 10:00
Andrew,
This paramater is not customer adjustable. It is only suposed to be changed by support. If you haven't already, you might want to open an SR with the support lab to investigate your backup performance problem.