8

We are facing constant server issues with Tridion 2011 SP1 HR1. We are getting an issue which is similar to this. Also, we are getting an error that says:

The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
Component: Tridion.ContentManager.Publishing.Transporting
Errorcode: 0
User: *******
StackTrace Information Details:
at Tridion.ContentManager.IdentifiableObject.GetListUsedItems(UsedItemsFilter filter)
at Tridion.ContentManager.ContentManagement.RepositoryLocalObject.GetListUsedKeywords(UsedItemsFilter filter)
at Tridion.ContentManager.ContentManagement.RepositoryLocalObject.GetListUsedKeywords()
at Tridion.ContentManager.Publishing.Transporting.TransportPackage.AddKeywordsMetadata(RepositoryLocalObject item, XmlElement parentElement)

We are having a separate publisher and deployer. The RAM of the server is 4 GB. The server runs out of resources very often and almost everyday the CPU usage is 100%. Happens especially when huge publishing is happening. What can be done to resolve these running out of memory issues? Thanks for your answers in advance!

Note: The memory issue gets resolved on restarting the COM+ and Tridion services.

Regards,

Keirthana

Improve this question
2
  • I've heard of memiry leak issues when using a certain version of the Oracle DB. What DB are you using, and what version/driver version?
    – Nickoli Roussakov
    Commented Apr 23, 2013 at 13:38
  • We are using SQL DB and sqljdbc-4.0 driver.
    – Keirthana
    Commented Apr 24, 2013 at 8:03

4 Answers 4

Reset to default
8

This looks very much like a memory leak. A correctly running server should have no problems with 4GB of RAM. (That's not to say that more memory might not be useful, but it should be stable in any case.)

You've probably got a tough job ahead of you to track this down, but you can start with some straightforward approaches:

  1. When the system becomes unstable, check which processes are using more memory than you'd expect. I would usually set up some perfmon traces to help to get a picture of what's going on in the run up to an out of memory incident. (Once it's occurred, your system is probably not in a good state for diagnostic work either.)

1a) As you have observed that restarting COM+ and the services helps, see if you can get more detail by stopping each in turn and examining your counters again.

  1. Review your template code, and if appropriate your mediator, function source, resolver and events code. Check that resource-owning objects run inside using blocks or have a finally block. Check for thread-safety when appropriate.

  2. The biggest suspect is your templating code, so try to isolate a specific template. Instead of doing your normal publishing run, publish only one specific page type, but do it a lot. Check your counters and go round. Don't forget dynamic component templates. Once you have a bit of a clue, analyse deeper, perhaps by creating specific test templates/pages.

  3. You can sometimes get a result by instrumenting your code with logging calls that dump out the memory at crucial places in your code. The important counter here is the private bytes of the relevant process. A lightweight approach to this is to call OutputDebugString, and pick up the results by using Sysinternals DebugView. Usually a spreadsheet helps too.

  4. If these basic techniques fail, you could consider some of the advanced techniques that are available if you are prepared to work with low-level debuggers. This is not for the faint-hearted, but you can do much worse than to start with Tess Ferrandez blog and other published material.

  5. Almost forgot... don't forget to check with support whether there are any known issues with your particular version and configuration.

  6. Almost forgot again... consider buying some memory profiling software. Typically, you can create an instrumented build and then get an analysis of a test run that points to problematic routines.

Improve this answer
2
  • Thanks a lot for the detailed answer Dominic! Yes, we have checked for memory leaks and fixed it but that does not solve the issue. On the suggestion of SDL support we have set up a perfmon to capture the picture. I will update once we corner the issue.
    – Keirthana
    Commented Apr 24, 2013 at 6:08
  • May I add the following to this excellent answer: check your CM optimization, as I see that for a publish action a Keyword chain is added, which also does a GetListUsing items. It may very well be that the content base in terms of components and linked keyword (chains) is huge. So, I would definitely start with profiling templates and publishing components / pages which have a large amount of keywords or associated keywords attached.
    – Raimond
    Commented Apr 24, 2013 at 15:40
5

I am not sure that you can resolve it only by fixing the memory issue. Though memory issue also should be fixed. First of all you should check windows application log to get the detailed error. Sometimes it happens due to concurrency issue. You are also recommended to check your publishing queue, if there are few items in “In Progress” state,they are probably victim of this concurrency issue.

This error looks like a COM error as something stops responding or gets crashed while executing the template code of these items(if any "In Progress" state in publishing queue)

If you have any error logged in application log ,you can take help of Tridion Customer Support they can better guide you on same.

Improve this answer
5

Do following:

  1. Contact the customer support and verify if your hardware specification is capable of handling your requirements - As far as I know, there is a white paper on hardware pre-requisite for varied factors - In my personal opinion, if you are choosing to publish a lot of data, 4 GB RAM looks low to me (anyway confirm with Customer Support)
  2. What is the size of your publishing queue? is it so big? - If it is big purge the publishing queue by Purge Queue tool and re-try?
  3. Check health of you CM and Broker DB - you may use DBCC command if it is SQL Server and take corrective actions per your DBA suggestion or you may want to follow the SDL Tridion Maintenance Guide

UPDATE: Are you using any custom code like eventing system, storage/deployer extension etc.? If yes, review your code and ensure there are absolutely no memory leaks (or resource consuming code)

Improve this answer
2
  • We have event system but we have already reviewed the code and checked memory leaks. But still issue is there. And yes, 4 GB RAM being on the lower side is the popular opinion. We are checking with the customer support of SDL if we need to increase the memory. I will update the answer here once I get a reply from SDL. Thanks
    – Keirthana
    Commented Apr 24, 2013 at 6:05
  • May be another thing that you can try and observer is replicating the scenario with a default template (which does not have any of your code and all the default Tridion templates ) and disabling all your codes like event system, any other.
    – Pankaj Gaur
    Commented Apr 24, 2013 at 6:55
3

Maybe you could try to configure COM+ Application recycling ("restarting the COM+ resolve the problem"). This will not solve the problem you have seen and I highly recommend you to follow the greats comments in this thread, but in this way you could gain some time to find out the right solution if you are in a critical environment. Some links:

Do a brief analysis to find out which values are corrects for you.

Improve this answer

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.