nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Running Out of Heap

bmf

I have been troubleshooting different issues related the stability of our production environment and we are currently running into HEAP issues where our VM runs out of memory. We have already done the following.

1. Looked into all custom code and fixed any memory related issues (e.g. leaks, large caching etc.)
2. Run load tests and gathered heap dumps when the LiveSite service crashes.

Currently we are seeing the product crash several times a week and not all of them are related to memory. However, a few times a month we are seeing the LiveSite service crash due to heap and looking into the HEAP I am seeing the following culprits.

1. com.interwoven.livesite.runtime.model.page.RuntimeStylesheet : #1
2. com.interwoven.livesite.common.concurrent.StringLock : #2

The first uses about 240 MB and the second uses about 144 MB. These two together obviously use almost half of the HEAP causing issue with the smaller memory users. Our site have 1800+ micro-sites and each with 15 pages etc. I have the following questions related to this and would appreciate any help.

1. Exactly what are these two classes and how does LiveSite use them?
2. I am thinking this is related to component and page caching in LiveSite and is there a file or setting to throttle this?
3. I also believe there is a URL to see the current cache (e.g. the max allowed, current cache and a link etc. to flush all of the components from cache for example)?

Find more posts tagged with

Comments

santosh013

I have been troubleshooting different issues related the stability of our production environment and we are currently running into HEAP issues where our VM runs out of memory. We have already done the following.

1. Looked into all custom code and fixed any memory related issues (e.g. leaks, large caching etc.)
2. Run load tests and gathered heap dumps when the LiveSite service crashes.

Currently we are seeing the product crash several times a week and not all of them are related to memory. However, a few times a month we are seeing the LiveSite service crash due to heap and looking into the HEAP I am seeing the following culprits.

1. com.interwoven.livesite.runtime.model.page.RuntimeStylesheet : #1
2. com.interwoven.livesite.common.concurrent.StringLock : #2

The first uses about 240 MB and the second uses about 144 MB. These two together obviously use almost half of the HEAP causing issue with the smaller memory users. Our site have 1800+ micro-sites and each with 15 pages etc. I have the following questions related to this and would appreciate any help.

1. Exactly what are these two classes and how does LiveSite use them?
2. I am thinking this is related to component and page caching in LiveSite and is there a file or setting to throttle this?
3. I also believe there is a URL to see the current cache (e.g. the max allowed, current cache and a link etc. to flush all of the components from cache for example)?

There can be number of reasons for this.you need to nail it down by seeing the logs and applying your logic. Few pointers from my side.
1. Check if restarting the server once in 2-3 days during off hours help.
2. Check leakages in your codes, e.g, too many connections to DB or something like that.
3. Try to increase the heap size in your App Server.

HTH.

Rick Poulin

1. Exactly what are these two classes and how does LiveSite use them?
2. I am thinking this is related to component and page caching in LiveSite and is there a file or setting to throttle this?
3. I also believe there is a URL to see the current cache (e.g. the max allowed, current cache and a link etc. to flush all of the components from cache for example)?

1. RuntimeStylesheet is the Java wrapper around an XSL file. If I'm not mistaken, you'll have at least one of these for every xsl file in your implementation (both page types, and component includes). The bigger the implementation, the more space these take. In earlier versions, these were cached by the classloader. I don't know if it's part of the cache system in later versions. StringLock is an abstraction around a string, to give it thread-safety. It's a common-use utility class, so it's not typically large in size but large in numbers, so it makes sense that you're near the top.

2. JCS (Java caching system) is what iwov uses. The SitePub dev guide contains some guidelines about tweaking its values (under the 'best practices' section). It's also an open-source framework, so there's general use docs out there as well.

3.

http://livesiteort/iw/admin/JCS.jsp

bmf

I believe Java caching system is caching more then we want as it is consuming a lot of memory. When I clear the cache we free up about 400 MB. Most of it appears to be on the component side. Where can I limit the number of components cached? Currently the max is 500 and I would like to take this down to 250 or so.