5

Has anyone ever faced issues with an ECL Connector spiking Tridion.ContentManager.ServiceHost.WindowsServiceHost CPU/Memory?

We have an ecl connection, connecting to a DAM system and it is causing the TcmServiceHost.exe to spike, and not release resources..

We started with a baseline of 400MB with TcmServiceHost and slowly just browsing through the mountpoint, opening and closing components, we noticed in 15 mins with only a few users grew to >1.5GB and does not stop/re- release resources after the testing was completed, a hour later. Even the CPU does not normalize back to 5-7% from where we started, with no activity at all within the instance.

I can't find much in the logs ecl.log - even when they are set to Debug.

Is this a known issue with External Content Library connector or the implementation of it?

Here are the steps to reproduce:

Testing with only 2 concurrent users:

  1. Open Media Repository mountpoint
  2. Browse (drill down) in the media directories
  3. Open Multimedia Components
  4. Close MM Components
  5. Repeat - Iterate same process for ~10-15 minutes
  6. Observe server usage
Improve this question
4
  • You are mentioning Media Manager in your tags, is this a custom ECL provider or the Media Manager ECL provider you are using?
    – Bart Koopman
    Commented Jun 23, 2017 at 7:14
  • I removed MM tag.. I just thought I needed that kind of audience. But it's a custom ECL provider..
    – Andy Ross
    Commented Jun 23, 2017 at 11:45
  • We have an open task to investigate potential memory leakage on our environment (Tridion 2013SP1), but haven't gotten around to it yet. We also have a similar behavior in a sense that the TcmServiceHost.exe 's memory usage is increasing over time. As mentioned earlier, I haven't gotten around to it, so I can't confirm or disregard your suspicions about ECL being the culprit. We are using SDL MediaManager, but also have lots of other customization like Event Systems etc.
    – Atila Sos
    Commented Jun 23, 2017 at 11:46
  • Having taken a look with Andrew on this, we're also seeing that stopping IIS as well as services on the Content Manager (batch processor, publishing/transport, and search, which probably isn't related) does not free up CPU or memory. Interestingly, running a trace file also won't generate an actual file (meaning nothing is outputing trace details?). Officially we'll continue on this with Support and the creator of the ECL connector, but we can add details and hopefully a resolution soon.
    – Alvin Reyes
    Commented Jun 26, 2017 at 8:38

1 Answer 1

Reset to default
7

There is nothing in ECL that will attempt to stop a provider from leaking memory.

So all the usual suspects apply: Missing calls to Dispose, event subscriptions, and static variables. I am sure there are more, but these are the three top contenders to memory leak I have encountered.

If the memory leak is observed in an SDL provider (for example Media Manager connector) then contact support.

I am not sure the .NET GC really cares an hour has passed if the server has enough memory - but a steady increase in memory usage is certainly suspicious.

Improve this answer
2
  • 2
    Indeed. In recent case with MediaBeacon provider. It was provider mistake that created infinite loop.
    – Yuri Bondarchuk
    Commented Jul 5, 2017 at 8:21
  • 1
    This was related to logic ECL has to "reconstruct" the location of an external item in the tree/navigation view. Starting with an item from the external system, ECL will ask for the path and recursively get parent items until you get to the mount point. The provider gave the same item rather than its parent (thus the infinite loop). For anyone using the MediaBeacon Connector, do reach out to their Support for the latest version.
    – Alvin Reyes
    Commented Jul 5, 2017 at 15:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.