Client Restoration (Wintel/Linux) Slowness

Please monitor exactly which process will 'pause' and where - on the client or on the server/storage node.

could you advice me which area could i do more check?

Just look at the appropriate numbers with an OS process monitoring tool.

Pay attention to the "nsr..." processes and the "recover" process.

bingo,

could i check with you. During the restoration, between networker and datadomain and the client.

client communicate to the networker, and networker will inform the datadomain to restore the data to the client, this is how the data path goes right?

in another words, does networker required alot of bandwidth to perform any task? What will be the minimum?

thank you.

bingo, 

1.) it has ddboost enabled, but how could i ensure that the restoration itself is using ddboost rather than is direct restoration?

2.) if the nsr process increase alot what will it happen? / if the recover process increase alot what will it happen? - both points would there be any remediation and suggestion i can fix.

the nw now sit on window, if i could use nic teaming and also on the switch using lacp would it perform better?

You are right about the path if you have ddboost backups/restores.

With respect to the speed - you cannot really predict. In general, it is possible that NW can restore as fast as it can backup the data. Only many of very small files will decrease the throughput. However, you have to consider that a DD usually does not only serve one process at a time. You must take this into account.

My intention is to find out whether a certain process uses to much memory or CPU or whether it seems to pause while it should transfer data.

In general, NW uses the same transfer path for backup and restore. It even uses the same program (uasm) - you just control the direction be either using 'save' or 'recover'.

Do not argue about solving the issue right now - find the troublemaker first. Preventing the problem is a later step - it only makes sense if you know the reason for your problem. Worst case, you must even contact Dell/EMC support. However this makes only sense if you can provide good input.

Hi Bingo,

1) To verify that the backup and restore stream uses the ddboost, you can analyze the daemon.raw, rendered in daemon.log . If the flow is correct you will find the indications type : 1) BACKUP: "is using direct file save with Data Domain device" 2) RESTORE " established the direct file retrieval session for save". This does not guarantee a higher speed, but only the correct use of the ddboost, often the two concepts can be associated. if you do not find this feedback in networker logs it means that the backup client does not communicate correctly with the datadomain so you should investigate the active network and/or firewall reachability that can block communication ports

@Ratman_mi 

thank you for your advice. Of course I know about the facts how to determine which way the data transfer will use. But I do not think that this is the issue here. It seems as if the whole transfer will either slow down extremely or even pause for a while. And this is pretty hard to figure out. ASo far, I do not have a real clue except permanently monitoring the system.

Hi Bingo.1,

but, if you use tcpdump do you see that the backup flow use the correct ethX ?

Yours seems more like a network problem and not a networker problem.

I also encountered a similar problem, but the cause was due to incorrect hostname resolution between nsrclient nsrserver and datadomain.

This may well be. Especially on network related issues NW is often not causing the trouble but will indicate such issue indirectly because it relys on a fully functional network and name resolution.