bottleneck network though using shared-mem / feature request

[mdiver]

We see bottleneck "network" on a customer site though using SAN-mode on the proxy and having the repository on the very same machine.
We already checked through support that shared-memory mode is used properly (#01100148).

Code: Select all

[03.11.2015 23:12:08] <  9392> cli|   Creating shared memory device with name: [SharedMemDev_{8c492f15-3142-4f50-8049-5551b2b4d3d4}].
[03.11.2015 23:12:08] <  9392> cli|     Opening process handle for PID: [18608].
[03.11.2015 23:12:08] <  9392> cli|     Creating ring buffer: [SharedMemDev_{8c492f15-3142-4f50-8049-5551b2b4d3d4}_ForwardBuf_SharedMem].
[03.11.2015 23:12:08] <  9392> cli|     Creating ring buffer: [SharedMemDev_{8c492f15-3142-4f50-8049-5551b2b4d3d4}_BackwardBuf_SharedMem].
[03.11.2015 23:12:08] <  9392> cli|   Creating shared memory device with name: [SharedMemDev_{8c492f15-3142-4f50-8049-5551b2b4d3d4}]. ok.
[03.11.2015 23:12:08] <  9392> cli| Shared memory connection has been successfully accepted.

Our proxy/repository combination is a Windows server with 74GB of Memory. Another one even has 144GB of Memory. Also there we see "network" as bottleneck or at least with a high percentage.

Question: Is it really possible to have a 2 x 8 Core Xeon with 144GB of RAM beeing bottlenecked by memory transfer speed over disk reads/writes or even tape writes?
We see bottleneck "network" even in tape jobs running from repo to tape server on the same machine.
I have to admit that we have quite large backup jobs with VBKs around 6TB.

Feature request: I would find it helpful to indicate correct usage of shared-mem instead of on-host TCP/IP by replacing the caption "Network" by "Shared-Mem" in the bottleneck section of the backup log or even the GUI.

Thanks,
Mike

[foggy]

Mike, I've asked devs to look closer into your logs and it turned out that in case of shared memory usage bottleneck stats could be reported incorrectly. Particularly in your case, bottleneck is target. This issue will be addressed in v9, thanks the heads up!