FMS is likely experiencing bottlenecking in handling both a remote content and application directory when under load and translating that load into memory work items that leads to your memory growth so rapidly.  While I'm not going to be able to join you in an investigation directly without a support case, I can indicate what we would recommend in that case to get to the bottom of this and you can do it yourself.

Really you want to find the critical bottleneck.  I would start with running the same scenario with a local application folder - typically FMS does NOT expect its application folder to be remote as there tends to be little content contained therein and threads and locking are designed around quick access to that folder.

Following that, it's worth determining the expected throughput from the remote drive servicing your content and making sure it can keep up with the requests.  If it can't you'll actually begin to buffer threads and requests FMS side and this will appear as a memory growth while they're waiting for the disk queue to respond.  Checking disk queue length can confirm this kind of problem for you.

Good luck with the investigation and feel free to contact us at adobe if your company needs to open a support incident to work on the case.

Asa

awhilloc@adobe.com

Perhaps then it's the content being on the remote disk - can you test by putting some portion of the content onto local disk - perhaps with a carefully chosen virtual directory mapping to see if that makes the difference?

Understood on the FMS only - can't resolve that data point currently, but looking at the obvious points of integration here for likely causes.

Asa