-3

Every page we publish increases around 2 MB memory on server. Is it a configuration issue?

FYI it is SDL Tridion 2011 SP1 with old vbscript code. Please sugegst.

vikas kumar
  • 2,444
  • 15
  • 25
  • 2
    It will be very difficult to help you without more information. It could be a memory leak in your template code. Does the same happen regardless of which items you publish? How about if you use the default page Template? – Dave Houlker May 01 '12 at 08:19
  • Are you using 100% VBScript templates, or are you using a combination of modular and legacy templates? – Chris Summers May 01 '12 at 11:17
  • Sorry for not adding more detail here, I believe question is not great but thanks for many useful information in answer.. – vikas kumar Sep 06 '12 at 14:35

4 Answers4

7

No - it is not a configuration issue.

At least, that is, assuming that what you are seeing is a memory leak. Tridion does cache various items during rendering, and some of that cache behaviour is configurable. Are you saying that the memory increases with every page render? And that it doesn't come down again? Which process owns this memory? Is it the publisher service, or the COM+ surrogate (dllhost), or something else?

It is impossible to cause a memory leak simply by configuring Tridion.

Are there any errors showing up in your event logs that might shed some light on this? Don't forget to look in the Application/System logs as well as the Tridion logs.

Dominic Cronin
  • 6,062
  • 2
  • 23
  • 56
6

Does it increase all the way until it stops responding? Or is this memory re-claimed later?

Using VBScript templates is not necessarily an issue, but I would certainly try to ensure that all your objects are released properly in the templates (set them to Nothing) and a code review is always a good idea.

As Dave suggests, testing with the Default Templates is always a good idea.

Nuno Linhares
  • 10,214
  • 1
  • 22
  • 42
4

I think the most important comments have been made. This is most likely a memory leak caused by not releasing objects where you have used Set blah = foo and not using Set blah = Nothing to release it. But if the Publisher does not keep growing to the point of failure, it could just be good caching of your templates by the publisher.

For earlier releases of Tridion, we had a community built PowerTool (available on the BBX of SDLTridionWorld.com) called CodePlumber which looked for such leaks. As you clearly know VBScript (and the tool is written with VbScript based classic ASP) it may be worth reading that code or resurrecting it to test your templates. You may even want to earn some bonus points for migrating it to the new PowerTools for 2011 framework.

My final question is whether or not these templates have been moved from an earlier version of Tridion, and if so whether the same memory growth was observed. If not, you may be seeing a new issue with how legacy templates are handled in the publishing process.

Chris Summers
  • 10,153
  • 1
  • 21
  • 46
2

You don't mention where the memory is increasing, but the most common place is in the COM+ object.

If this is the case, the brute-force method of working around this is to implement COM+ recycling at a memory threshold. The threshold would depend on where you start to see issues, and the available memory on the server, but 1GB is a good point to start tuning from.

This recycling should have no impact on your user's experience.

Note this doesn't actually fix the issue - it simply prevents the issue from bringing down the rest of the system.

As the other posters have mentioned, fixing the issue likely means tracking down memory leaks in your old VBScript code.

JRW
  • 1,311
  • 9
  • 9