About 40 o 50 days ago, we installed ReadyNASOS 6.2.0 on a ReadyNAS 2100 and a RNDP4220. After testing the new OS and updating it to 6.2.2 we began to use it for doing backups of our five node Proxmox cluster and then started the problems.
OS 6.2.2 seems to hang under heavy use of NFS v3 tcp (both the 2100 and the RNDP4220), we reduced the concurrent writing processes on the NFS shares and it seemed to work better but sometimes the system hanged again. We tried to downgrade to 6.2.0 and the system seemed to work well so we retried the original backup process (the 5 nodes of the cluster writing on the nfs share concurrently) and it worked fine for two weeks. After that we experimented 3 more hangs.
I installed OS 6.2.3-T1718 on Saturday 21 and the 2100 is working fine until then. It's too early to draw conclusions but we've thought that it would be good to give some feeback about this beta.
How many writing processes did you configure to make things work better with the newer 6.2.3 firmware?? I have seen similar NFS issues on a ReadyNAS 516 so I am wondering if such a change would help our backups. Thank you, Tom
I only installed the 6.2.3-T1718 beta. I didn't do changes in the nfs server's process number because 8 processes is enough for us. Now we're doing the backups the same way as ever, 5 proxmox servers writing concurrently during 4 or five hours. The NAS has worked well during all week untill yesterday.
Last night the backup process finished ok. NFS server is still working but I have no access to the web manager nor ssh. With 6.2.3-T1718 beta it has worked better, but I hope next beta will be the one! 😉
I'm doing a hard reset now and then I'll try the new 6.2.3-T1730 (Beta 7) firmware.
Why is 8 considered a high nfs count and what is a suggested nfs count?? What factors determine an appropriate nfs count??
We have backups running from/with a backup appliance VM that runs several backup jobs concurrently and is therefore sending a lot of data to the NAS, particularly a lot of small units of data.
The performance charts show:
1) maximum volume peaks of 469.4 (what unit?? kb?? mb?? what??????? the graph does not say) read and 696.4 (what unit?? kb?? mb?? what??????? the graph does not say) write over the past week's period, usually everything is considerably lower.
2) maximum network peaks of 60M RX and 12.7M TX over the past week's period, everything else is considerably lower
A NFS thread count that is low as will do what you need is recommended.
And how would we know how to figure that out?? Please give more details on this. The appliance is doing a fair amount of concurrent disk access. Netgear defaults to 8, why?? Thank you, Tom
Trial and error can be used for that. I believe for systems reset on 6.2.3 there is a lower default thread count.
How many jobs are you running concurrently to the NAS using NFS?
OIC. Several VMs are backed up per backup job by the backup appliance, plus the backup appliance can have started some post-processing on the backups. The backup appliance can run up to 8 simultaneous backups, would each backup be considered a 'client'??
In our backups, the most VMs in a job is 8, the fewest is 4.
Our ReadyNAS is set to 8 nfs threads, I've not changed it ever since it was set up.
It is set for 8, the only remaining options are 1, 2, 4, then 12, 16, 24, 32.
Is any logging done by the ReadyNAS about how many connections it receives while the backups are happening?? If so, where do we look??
I must leave this command running in a putty window during the night while the backups run?? Unless you say otherwise I'm assuming the answer is yes, since the display is presently all zeroes. Thank you, Tom
