Cache SIze limit

Quote from the Teamsite 6.5 Admin Guide.

" The initial cache size setting should be approximately three times the number of files and directories on the largest branch. For example, if the largest branch contains 15,000 files and directories, you should set cache size to 45000 as follows:

[iwserver]
cachesize=45000

Minimum cache size is 1000; maximum is 400,000 entries. Each cache line takes a
maximum of 1KB of physical memory. Recommended physical memory is cache size times
1KB plus an additional 25% as a safety margin. In the example shown below, physical
memory would be (45,000 * 1KB) + 11MB = 56MB."

Does anyone have experience with a branch size that exceeds the maximum 400,000 cache value. Does anyone know the effect on teamsite if you push the cache value above the MAX.? We could have multiple branches that exceed this MAX cache value of three times the number of file on largest branch.

Thanks..

Find more posts tagged with

Comments

jed

Hmm. Ours is actually set to 500,000. Oops. Oh well, it seems to have done no harm, yet.

As for our branch size, our largest branch is 167,293 files/dirs. Assuming iwserver does set a internal max cache size of 400,000, we have exceeded the 3x number. This has not presented any recent issues*, but we do have monster hardware. (48 gigs of ram and 12 CPU's). Most of our other branches are probably under 100,000 files, but I have not checked recently to confirm that.

* Back in our TeamSite 5.x days, we had issues deleting editions and performing other weird operations. Day-to-day work was never impacted due to the large branch size. YMMV.

What platform are you running? Anecdotal evidence has shown me that Solaris scales a bit better in the TeamSite world than windows.**

**Yes. I work for Sun. I am bias since I drink the company kool-aid. However, in my consulting days, Solaris customers seemed to have less scalability issues.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

Burtonr

Jed..

Thanks for the reply. Our hardware is the smaller brother of yours (24Gigs Memory and 6 cpus) on enterprise class sun hardware. But this does lead me to another question. Is your monster machine dedicated to Teamsite. Or are you running it in a consolidated environment where Teamsite has to compete for resources with other services? In essence does teamsite play nice with others or should it be isolated on a machine of its own. I was unable to find a suggested architecture in the Teamsite documentation so far.

Rob Burton
CRA

JonathonG

Traditionally, the answer to this question has been to keep TeamSite on its own server because it is extremely I/O intensive and you don't want competition at that level.

Jonathon
Interwoven Developer
Allstate, Inc.

jed

That happens to be one of those "it depends" answers. Besides some custom java apps to provide misc. authoring services, TeamSite is the main application on the machine. As workflows spin up, the CPU's can get real busy with all the perl processing going one. When we have people working in the GUI/filesystem without starting workflows, the box is not all that busy. If you do not have a lot of workflows/templates, you might be able to get away with it.

If you must run multiple services on one server and guarantee resources for all the various apps, you could use processor affinity. This can bind specific apps to various processors. For example, you could bind TeamSite to 4 CPU's, and another app to 2 CPU's. If you are using separate disk arrays for the different applications, IO should not be much of an issue. I did some POC work around this, but never had to use it in production.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

Migrateduser

The cachesize should be increased if:

1) The cache is fully populated (i.e. iwstat -c shows ~90% of total cache slots in use), AND...
2) The system has sufficient physical memory to accommodate a larger iwserver process, AND...
3) There is significant cache turnover.

To determine cache turnover rate, run iwstat -c in a 3 second loop and monitor the total available cache slots. Available cache is typically in the range of (90% - 2000) and 90% of cachesize. When available cache reaches 90% of total cachesize, 2000 cache slots are released back into the available pool. If this happens frequently (e.g. one or more times each minute) then you have significant cache turnover.

Two primary reasons to decrease cachesize:

1) iwserver process approaching or exceeding 2Gb.
2) iwserver process getting pushed out to swap.

Max cachesize prior to TS5.5 was 200000.
Max cachesize with TS5.5.x and later is 400000.