FMSCacheSizingTool Instructions v1 2

FMS Cache Sizing Tool Version 1.
2 User Guide

2013 Siemens Product Lifecycle Management Software, Inc.
ALL RIGHTS RESERVED.

FMS Cache Sizing Tool
User Guide
Version 1.2

FMS Cache Sizing Tool Version 1.2 User Guide

Introduction

The FMS Cache Sizing Tool is a Microsoft Excel spreadsheet designed to assist in the proper sizing of the
FMS Fast Cache of the File Management System (FMS) modules FMS Server Cache (FSC) and FMS Client
Cache (FCC). The FSC is the FMS network server component used to route and distribute Teamcenter
data files to and from the Teamcenter systems volumes and transient volumes. The FCC is the client
component used to cache recently accessed data in user-specific client environments.

The FMS Fast Cache is used by the FSC and FCC to store segment data. This cache is frequently used in
conjunction with a whole file cache, which stores complete files.

Sizing the FMS Fast Cache

The FMS Fast cache is configured with five values that determine the size of its internal tables. The size
of the internal tables in turn determines the caches data capacity, efficiency, and memory
consumption. These values are known as the five magic numbers of an FMS Fast Cache configuration.
A summary of these five values appears in the table below.

Table FCC Name FSC Read Cache Name FSC Write Cache Name
Core data segments FCC_MaximumNumberOfSegments FSC_MaximumReadCacheSegments FSC_MaximumWriteCacheSegments
Extent files FCC_MaxExtentFiles FSC_MaximumReadCacheExtentFIles FSC_MaximumWriteCacheExtentFIles
Extent file size (each) FCC_MaxExtentFileSizeMegabytes FSC_MaximumReadCacheExtentFileSizeMegabytes FSC_MaximumWriteCacheExtentFileSizeMegabytes
File headers FCC_MaximumNumberOfFilePages FSC_MaximumReadCacheFilePages FSC_MaximumWriteCacheFilePages
GUID hash table size FCC_HashBlockPages FSC_ReadCacheHashBlockPages FSC_WriteCacheHashBlockPages

The key to sizing an FMS Fast Cache is finding a set of five values which:
1. Provides the desired cache capacity.
2. Consumes no more than the available or allowable amount of shared memory.
3. Allows efficient operation.
4. Is internally consistent.
The FMS Cache Sizing Tool provides a mechanism for sizing FMS Fast Caches for FSC and FCC
installations by calculating the five magic numbers, checking them against the criteria listed above,
and assembling them into XML that can be copied from the form and pasted into real FMS configuration
files.

History

The FMS Cache Sizing Tool was preceded by a similar tool called FMSCalc. The FMSCalc tool was initially
created to analyze FMS segment cache configurations for consistency. However, it did not compute
cache sizes directly. The user needed to input the five magic numbers, or use a separate calculation
mechanism (e.g., one of three methods described in the Teamcenter System Admin Guide), and then
use the tool to adjust the cache configuration to suit the particular needs of the context for which the
cache was being configured.

The FMSCalc tool also had several generations and versions, not all of which were equally accurate in
their internal memory computations, configuration limits, and warning thresholds. None of the FMSCalc
tools were placed in source control until May 2012, and none of them were ever officially maintained by
the FMS team (which maintains the FMS segment cache code) but unfortunately, many of the versions
remain in use by customers and/or members of the customer support team (including GTAC).

The new FMS Cache Sizing Tool has the following goals and purposes:
1. To provide an easy-to-use forward computation, starting with the platform context and the
desired cache size, for initializing, customizing, and tuning the five magic numbers.
2. To provide a consistent and accurate mechanism for cache size calculations, that reduces /
eliminates guesswork and configuration errors on the part of Teamcenter customers and our
own support staff.
3. To take both disk and memory consumption into consideration, as they relate to segment cache
sizing on a real machine with real resource limitations.
4. To better match the memory considerations of the (read and write) pair of FSC segment caches
to the available FSC server process memory. That is, to configure the FSC read and write caches
as a pair, rather than individually; these two caches run in the same JRE process, and share
common process memory space.
The FMS Cache Sizing Tool also provides accurate analysis pages, which resemble the functionality of the
existing FMSCalc tool.
The FMS Cache Sizing Tool is versioned, and will continue to be maintained by the FMS development
team, and included as part of the FMS deliverable kit.

Prerequisites
The FMS Cache Sizing Tool is a Microsoft Excel 2010 spreadsheet intended to run on Microsoft
Windows platforms. You will need Microsoft Excel (a part of the Microsoft Office suite of
products) to use this tool.

Layout Overview

Input Areas
Input areas are generally on the left side of each FMS Cache Sizing Tool page, and are identifiable by
GREEN highlighting:

The platform selector control has a bold green border.


Output Area
At the bottom of each form is an output area containing the XML cache configuration.

More Subtle Highlights

Some cache size data (not always visible) appear in pale blue text.

Errors, Warnings, and Notices
Some cells contain text that is only displayed when the cache configuration contains errors (inconsistent
values), warnings (inefficiencies), or notices (positive features). These cells also have triangular
markers pointing to the input or intermediate calculation to which they are related.
Errors are displayed in RED TEXT. If you see errors on your form, you have at least one bad
input or inconsistent value, which should be corrected before attempting to use the XML output
(which may disappear). We will discuss below how to respond to cache configuration errors.

Warnings are displayed in ORANGE TEXT. If you see warnings on your form, there should be
considered before using the XML configuration. The cache is usually functional, but warnings
typically tell you about cache inefficiencies that may occur with this configuration; others just
inform you that certain limits have been reached.

Notices are displayed in GREEN TEXT. These cells point out positive, desirable features of the
cache configuration. You want to see as many green notices as possible, within the constraints
of available memory and disk space.

Memory and Disk Consumption Calculations
Every FMS Cache Sizing Tool page calculates the amount of memory and disk consumed by each of the
data files in the current cache configuration, in both MB (megabyte) and GB (gigabyte) units. In general,
the gigabyte values are more useful for large caches, and the megabyte values are more useful for
smaller caches. For convenience, the FMS Cache Sizing Tool displays both.
All other input fields have a green tinted background with a bold green border.
The XML output fields have a yellow tinted background and bold yellow border.
Memory allocation and consumption values have a peach background.
Cache data size calculations and considerations have a pale blue background.
On the calculation pages, the five magic numbers have a pale yellow background.


Cache data is stored in two places: the segment file (fms.seg) and the extent files (fms*.ext).
The core segment file contains fast, fully memory-resident segment data. The shared
memory footprint and the size of this file grow and shrink with the number of core data
segments.
The extent files also contain segment data. The number of extent files and the size of
each extent file are configurable. As these files are not fully memory-resident, access to
the data in these files is not as fast as access to the core segment file. The other half of
that tradeoff is that the shared memory footprint is much less affected by the size and
number of extent files.
The sum of the size of the segment file and all extent files is the total data capacity of
the segment cache, and is subtotaled in a value called All Data (Ext+Seg).
The metafile (fms.mf) is where the file headers are stored. It grows and shrinks with the
number of file pages. There is one file header per file page. Like the segment file, the metafile
is fully memory resident at all times, and contributes directly to the shared memory footprint.
The metafile size is often the single most limiting factor when it comes to memory constraints.
The hash file (fms.hsh) is where the GUID hash table is stored. It grows and shrinks with the
number of hash pages. There are 128 hash entries per hash page. Like the segment file and the
metafile, the hash file is fully memory resident at all times, and contributes directly to the
shared memory footprint. Fortunately, the memory footprint of the hash table is much smaller
than that of the metafile.
The sum of the data space (segment and extent files), metafile, and hash file constitute the total
memory or disk consumption of a segment cache.
Memory consumption is a critical sizing parameter, particularly in 32-bit and FCC client environments,
which have a 2GB total process memory limit. Memory can also be a limitation on 64-bit systems,
especially if there is a limited amount of RAM available.


How to use the FMS Cache Sizing Tool

For sizing FCC or FSC caches:
1. SELECT THE RIGHT PAGE
Select the page that calculates the type of cache you want to size.
The \FSCServerCalc/ page is the page which configures the FSC read and write caches (as a
pair), from scratch.
The \FCCClientCalc/ page is the page which configures the FCC segment cache, from scratch.
Use the \OldHP_FSC/ and \OldHP_FCC/ pages only for cache configuration on Hewlett-
Packard (HP-UX) systems prior to Teamcenter 8.1. For Teamcenter 8.1 and later, you can
use the regular \FSCServerCalc/ and \FCCClientCalc/ pages.
2. SELECT THE PLATFORM AND BITWIDTH
Select the appropriate platform and bit width value. (Use Unix for MacOS as well as Unix
platforms.)
NOTE: In order to be functional as a 64-bit process, the following requirements must all be met:
a. The process must be running on a machine with 64-bit hardware.
b. The process must be running on a 64-bit operating system.
c. The software running in the process must have been compiled with a 64-bit instruction set.
Java programs, in particular, need to be running in a Java Runtime Environment (JRE) that
was compiled in 64-bit mode.
All other processes are 32-bit processes.
3. SET THE STARTING VALUES
NEW in version 1.2: If you are using the version of the FMS Cache Sizing Tool with macros enabled, all the
recommended input values, except for the cache sizes, will be updated for you whenever the platform / bitwidth
selection changes. So change the platform / bitwidth first; then all you need to enter is the cache sizes.

The left-hand column contains recommended starting values for all of the inputs except the
platform and the target cache size. These values may need to be tuned later, but please start
with the recommended values when configuring a cache from scratch. Just type the green value
in the input box to its right. For example,where you see this:

You would type 768 in the Memory (MB) this cache input field (which currently displays the
value 1122).
Please observe that the target values given as input are subject to change, due to rounding and
internal cache limits, when the cache is initially sized. If you want to force a particular
configuration change (for example, a hash ratio less than 1:1), you can use the analysis pages
rather than the size calculation pages. but its probably best not to do this, as the resulting
cache will be inefficient at best, and possibly non-functional in the end.

NOTE: Updating starting values from a prior configuration may place the form in some awkward transitional states.
The advice here is to not worry about errors or warnings on the form until after all input values have been entered.


4. FIX ANY ERRORS
Once all the starting values are set, you look for the red ERRORs on the form first, and deal with
those. A list of errors, and advice on how to handle them, appears here:
INPUT ERROR
This indicates that the form could not make sense of one or more of the inputs. One of
them is incorrect out of range, negative, not a number, not a multiple of 16MB, or
otherwise not acceptable. There should be another error displayed, typically in the left
column, identifying which input is unacceptable. For example:
MEM 256-1536
This maximum amount of memory available to each process depends on the
platform bitwidth, and the amount of RAM installed on the machine. This tool
reserves some memory for typical FCC and FSC processes. The minimum
allowable amount of memory allocated for each segment cache (e.g., on an FSC
ser ver) is 256MB.
CACHE SIZE > 0
For the purposes of this tool, the cache size (in megabytes) must be an integer
value greater than zero. The maximum size of an FMS segment cache depends
on the platform context and the amount of performance inefficiency that the
user is willing to accept.
SEG SIZE 1-2032
For the purposes of this tool, segment file size must be at least one megabyte.
The maximum size of the segment file depends on the platform context and the
amount of memory available for segment data.
EXT SIZE 16-2032
The extent file size must be a multiple of 16 megabytes, between 16MB and a
maximum value determined by the platform context.
FILE RATIO 1-36
This is the target ratio of the number of 16KB data segments in the cache to the
number of file headers in the metafile. The minimum value is 1, and the
maximum value is either 35 or 36, depending on the platform.
HASH RATIO 1-10240
This is the ratio of the number of file pages to the number of hash entries.
(There are 128 hash entries per hash page.)
OUT OF FILE PAGES. REDUCE CACHE SIZE.
A cache of the requested size requires more file pages than the cache can support. The
cache size must be reduced to bring the number of file pages down to a reasonable
value.
!! ERROR: OUT OF MEMORY !! THIS CACHE CONFIGURATION IS NOT USABLE.
OUT OF MEMORY. REDUCE TARGET SEGMENT FILE SIZES, INCREASE TARGET FILE
HEADER RATIOS, REDUCE TARGET HASH RATIOS, INCREASE CACHE MEMORY
ALLOCATION.

Either or both of these errors mean that there is not enough memory available to
support this cache configuration. Memory can be conserved by a number of methods.
We recommend considering memory conservation adjustments in this order:
a. Reduce the target segment file size(s). This moves some of the segments into
extent files, which use less memory.
b. Increase the target file header ratio(s). This will have efficiency implications if most
of the files in the cache store only a few 16KB segments of data in the cache. If the
cache becomes starved for file headers, it will free the least recently accessed file,
and its data segments, to make room for fresh data. This effectively reduces the
size of the cache.
c. FSC only: Make the read and write caches asymmetrical. (Typically, customers will
make the write cache smaller than the read cache.) This can buy you additional
memory for the more important read cache.
d. Reduce the target hash ratio(s). This will decrease the efficiency of the cache
because there will be a higher probability of hash collisions, and the collision chains
will increase in size.
e. Reduce the total cache size. If this becomes necessary, you are probably facing the
reality that a cache of the intended size, if you did actually manage to shoehorn it
into memory, would be so inefficient that it would be less useful or effective than a
smaller cache, anyway.
OUT OF HASH PAGES. REDUCE TARGET HASH RATIO.
The cache cannot support the calculated or configured number of hash pages. Reducing
the target hash ratio could free up some hash pages.
If ERRORs are displayed on the page, the XML output may disappear and be replaced with a
statement that there are errors on the page, that need to be corrected. This is intentional, (a
deterrent to ignoring cache configuration errors, and creating support calls when the cache
configuration does not work).
5. TAKE NOTE OF ANY WARNINGS AND NOTICES
Once all of the red ERRORs have been addressed on the form, you should examine the orange
WARNINGs. These cells make you aware of cache inefficiencies or potential problems that
might be associated with the cache configuration as it stands.
You can also note the notices, which indicate features configured to maximum performance. It
is sometimes worthwhile to configure away a notice, if it also gets rid of a problematic or
potentially problematic warning or error elsewhere on the form.
A list of warnings, and advice on how to handle them, appears here:
MAX EXT FILES (OK)
(FSC only) This is just a notification that this cache uses the maximum number of extent
files. The cache file size may have been increased to allow enough data in the cache.
FILE HEADER RATIO INCREASED.
NOTE: CACHE SIZE REDUCED WITH FILES <45 KB

These two warnings kind of go together. The first one tells you that the file header ratio
of this cache is larger than the requested target, either because of memory limitations,
or because the maximum number of file pages has been reached. That means that this
cache will be less effective if only a small number of 16KB segments of each file are
stored in the cache. The second warning gives you some more details; If the average
amount of data per file stored in this cache is less than the value indicated in the second
warning, then the cache will operate at a much smaller size (indicated in blue).
MEMORY AVAILABLE. TRY INCREASING TARGET SEGMENT FILE SIZE.
Try Target Segment Size
These warnings indicate that the cache actually weighs in below than the allocated
amount of memory. Some efficiency can be gained by making more of the cache data
memory-resident in the core segment file. You can try entering the recommended value
in the Target Segment File Size cell to see if it improves the situation.
LARGE EXT SIZE (DELAYS)
(FCC only) Unlike an FSC server, the FCC creates each segment file, in its entirety, at one
time. If the extent file size is large, then it takes the FCC a while to write the empty
extent file to disk. This results in a noticeable delay in cache processing. To avoid this
delay, you should reduce the target extent file size, if possible. On an FCC, it is generally
better to use more small extent files, than fewer large ones.
THE WRITE CACHE USES MORE THAN ITS SHARE OF MEMORY
THE READ CACHE USES MORE THAN ITS SHARE OF MEMORY
(FSC only) If you see only one of these warnings, then it simply alerts you to the fact that
the memory allocation is unbalanced between the two caches. Looking at the TOTAL
MEMORY value in the bottom right corner of each caches Disk and Memory
Consumption area tells you how much memory each cache uses, and the MB Mem
Alloc block tells you the amount of memory allocated to this cache. The
\FSCServerCalc/ page allocates memory among the read and write cache in proportion
to their requested sizes.
If you see both of these warnings, then you should also see one or more of the OUT OF
MEMORY errors listed above. And since errors are more important than warnings, you
should definitely take the steps listed above to deal with the errors at which point one
or both of the warnings may go away.
NOTE: FCC cache sizes are currently limited to the capabilities of potential
concurrent 32-bit clients.
This may change when Teamcenter support for 32-bit client applications is
discontinued.
(FCC only) This is an informational warning which is not resolvable by customer action.
At the current time, the FCC cache is limited to size constraints that can be shared with
32-bit client applications (e.g., a 32-bit FCCClientProxy). Use of sizes outside of these
constraints would render the client incompatible.
This effectively erases the difference between the 32-bit and 64-bit bitwidth selections.

This design decision was applied to all platforms, including those that do not support 32-
bit clients (Linux, MacOS, HP-Itanium) and those for which the FCC segment cache is
never shared (AIX).
At some time in the future, if and when Siemens PLM terminates support for all 32-bit
client applications, this constraint may be lifted. At that time, an update to the FMS
Cache Sizing Tool will be issues to support 64-bit configurations.

Here is a list of the NOTICEs:
SUPER FAST !!
This tells you that 30% or more of the cache data is resident in the segment file. This
will result in maximum data access speed. This is only possible on reasonably small
caches (about 3GB or less in 32-bit environments, or about 20GB or less in 64-bit
environments).
BEST DATA CAPACITY
This tells you that the cache has a file header available for every segment in the cache.
This means that the cache will always be able to use all of the configured segments
before it needs to purge the least recently accessed data to make space for fresh data.
FAST LOOKUPS
This tells you that the actual hash ratio is 10 or greater; the probability of hash table
collision is therefore relatively small, and the hash lookup should therefore be very fast.

6. COPY THE XML OUTPUT
Once you are satisfied with the adjustments you have made to get rid of all the ERRORs and
WARNINGs reasonably possible, you can select the leftmost column of cells in the yellow XML
output area at the bottom of the form, and copy the output.
In the case of FSC configuration, this XML output can be pasted into the <fscdefaults>
section of the target FSC servers fsc.xml (for an individual FSC) file(s).
In the case of FCC configuration, this XML output should be pasted into the
<fccdefaults> section of the clients fcc.xml configuration file.


CACHE SIZING WALKTHROUGH
Example 1 (Typical cache sizing)
Consider a customer who wants an FSC read cache size of 512GB (512 x 1024 = 524288 MB), and an FSC
write cache size of 2 GB (2 x 1024 = 2048 MB). The FSC is running on a 64-bit machine, running a
Windows 7 64-bit operating system, with 8GB of RAM, and Teamcenter 8.3. The FSC cache would be
configured as follows:
1. Since this is an FSC configuration, starting with the cache size and working forward, select the
\FSCServerCalc/ tab at the bottom left corner of the FMS Cache Sizing Tool spreadsheet.
2. Since this customer is running Teamcenter 8.3, select as the platform. This is not a
typo. Even though this is a 64-bit machine running a 64-bit operating system, Teamcenter 8.3
provides and runs in a 32-bit Java runtime environment (JRE). The least common denominator
is the 32-bit JRE, which will limit the FSC to 2GB of total process memory.
3. If you are not using the macro-enabled version of the FMS Cache Sizing Tool, or if you disabled
the macros, enter the memory allocation value of 1536 into the Memory (MB) both fast caches
input cell (E4). Enter the other initial values from the leftmost column into the green input
fields, as well. Your form should now look something like this:

4. There are some new text messages displayed, but there are no ERRORs on the form. The XML
output is displayed, but is not yet optimized. You could just grab the output verbatim, but lets
look a little closer at the form to see if we can optimize the configuration a little bit.

5. Looking at WARNINGs and NOTICEs. I will start with the upper left and work clockwise around
the form.
a. The cell next to the read cache File Pages reads: FILE HEADER RATIO INCREASED.
Because it is so large, this read cache is configured to use the maximum number of file
pages allowable for a 32-bit cache. The read caches file header ratio (target value 1:1
from green input cell B13) has been increased to 16.06:1 (displayed in intermediate
calculation cell O13) to allow the requested number of segments to be defined in the
cache. This is not necessarily a cache capacity problem, as long as the cache is used to
store enough data from each file (GUID).

Heres a diagram of what this cache looks like when it is full of small pieces of files:

File Pages Segments
In use Page1 Segment1 In use
In use In use 32 GB
(End of table) Segment2097152 Free 514 GB

Free

482 GB

??? Segment33683456 Free

When the 2,097,152
nd
small file goes to get stored, there are no more file headers, so
the cache has to free the data from the 32GB of used segments when it frees the file
header that points to it. This gives the cache a maximum effective size of 32GB (about
1
/
16
th
, or 6%, of its configured size) for small files. The last data segment is never used
unless all the files in the cache consume an average of more than 16 (say, 17) 16KB data
segments (about 272KB) per file.
b. The cell next to the read cache File Ratio reads: NOTE: CACHE SIZE REDUCED WITH
FILES <272 KB
This is fallout from the increased file ratio. If the read cache stores less than an average
of 272KB of each file, then the cache will run out of file headers before it runs out of
segment space. Lets look at the blue cells that are now displayed in the Small File
Data Size section. If the read cache stores only 16KB of each file, then it will run out of
file headers after storing 32767 MB (32 GB) of data (cells O12 and Q12), effectively
making the cache only 6% of its configured size (cell R12).
Since this is occurring because a hard limit (number of file pages) has been reached,
there is not much a customer can do about this (except possibly install a 64-bit JRE).
c. The cell next to the read cache Hash Ratio reads: FAST LOOKUPS
This is displayed in green text, so it is a notice. The hash ratio of the read cache is
10:1, which means that the probability of experiencing a hash collision on any given

lookup is low. This means that the segment cache will be able to look up file GUIDs
quickly in the hash table.
d. The cell below and to the right of the write cache TOTAL MEMORY reads MEMORY
AVAILABLE. TRY INCREASING TARGET SEGMENT FILE SIZE. . The cells above read
Try Target Segment Size, and indicate a value of 185 MB.
The total FSC memory in a 32-bit process is limited to 2GB (2048 MB). We reserved
512MB of that for the FSC code and data, leaving 1536 MB (cell H4) for the read and
write caches. We allocated most of that, or 1280 MB (cell E17) for the read cache, and
the remainder (256 MB, cell E31) for the write cache.
The write cache in this configuration will consume about 87 MB of shared memory (cell
L31). This includes 2MB of extent files, 16 MB of segment file (totaling about 18MB of
data in memory at any given time), 64 MB of metafile, and 5 MB of hash file. This leaves
(256 87 =) 169 MB of memory allocated, but unused. Using that 169 MB of memory as
segment space could increase the caches data residency, and make the write cache
faster.
Enter the suggested value of (169 + 16 =) 185 MB from cell R31 in the write caches
Target Segment File Size input (cell B23).


Your form should now look something like this:

a. The cell next to the write cache File Pages now reads: FILE HEADER RATIO INCREASED.

This just showed up when you typed in the 185 MB segment cache size it was not
there before. But if you look at the write cache File Ratio (cell O27), it reads 1.00, and
the blue text in the Small File Data Size region says that small files still result in a
100% cache capacity (cell R25).
What has happened here is a little bit of a false alarm due to rounding error. This cache
configuration is so close that you can effectively ignore the warning. Perfectionists and
purists can make the error go away by subtracting 2 MB from the Target Segment File
Size (use 183 instead of 185).


b. The purists that enter a write cache segment size of 183 will also be rewarded with a
NOTICE next to the write cache file ratio (1.00:1) reading BEST DATA CAPACITY. This
means that a file header ratio of 1:1 is in use for the write cache, which means that the
cache will never run out of file headers. The situation described above with the file
header increased and cache size reduced warnings, will not occur with the write
cache.
c. The cell next to the write cache Hash Ratio reads: FAST LOOKUPS
This is the same notice that we saw above for the read cache. The hash ratio of the
write cache is 10:1, which means that the probability of experiencing a hash collision on
any given lookup is low. This means that the segment cache will be able to look up file
GUIDs quickly in the hash table.

The only complaint remaining is that the file ratio of the read cache is 16.06:1.
This is probably within a reasonable range for an FSC server.
and there are three notices displayed!

d. The XML output of this cache appears as follows. This can be pasted into the
<fscdefaults> section of the customers fsc.xml configuration file.

Example 2 (Out of memory on FSC)
Consider a customer who wants an FSC read cache size of 1000 GB (1000 x 1024 = 1024000 MB), and an
FSC write cache size of 500 GB (500 x 1024 = 512000 MB). The FSC is running on a 64-bit machine,
running a Windows 7 64-bit operating system, with 8GB of RAM, and Teamcenter 8.3. The FSC cache
would be configured as follows:
2. Since this customer is running Teamcenter 8.3, select as the platform. This is not a
typo. Even though this is a 64-bit machine running a 64-bit operating system, Teamcenter 8.3
provides and runs in a 32-bit Java runtime environment (JRE). The least common denominator
is the 32-bit JRE, which will limit the FSC to 2GB of total process memory.
the macros, enter the memory allocation value of 1536 into the Memory (MB) both fast caches
input cell. Enter the other initial values from the leftmost column into the green input fields.
Your form should now look like this:


<property name="FSC_MaximumReadCacheSegments" value="1024" overridable="true"/> 
<property name="FSC_MaximumReadCacheExtentFiles" value="259" overridable="true"/>
<property name="FSC_MaximumReadCacheExtentFileSizeMegabytes" value="2032" overridable="true"/> 
<property name="FSC_MaximumReadCacheFilePages" value="2097151" overridable="true"/> 
<property name="FSC_ReadCacheHashBlockPages" value="163840" overridable="true"/> 

<property name="FSC_MaximumWriteCacheSegments" value="11712" overridable="true"/> 
<property name="FSC_MaximumWriteCacheExtentFiles" value="1" overridable="true"/>
<property name="FSC_MaximumWriteCacheExtentFileSizeMegabytes" value="1872" overridable="true"/> 
<property name="FSC_MaximumWriteCacheFilePages" value="131520" overridable="true"/> 
<property name="FSC_WriteCacheHashBlockPages" value="10275" overridable="true"/> 


4. There is an ERROR on the form. Where the XML output would normally be displayed, the text
reads Error(s) on form.
There is an error by the write cache File Pages setting, reading OUT OF FILE PAGES.
REDUCE CACHE SIZE.
You will notice that the File Ratio (cell O27) is 36.04:1. This is greater than the
maximum file ratio on Windows (36:1). The number of file pages, however, is less than
the maximum (which for 32-bit Windows is 2097151). This is because the FMS Cache
Sizing Tool calculations were told to force-fit this cache into 512MB of memory. So the
next question becomes: Where can I conserve a little more memory? Lets look at the
recommendations associates with this error message above (page 6), in that order.
a. Reduce the target segment file size(s). Reducing this (cell B23) to 15 MB (just
1MB less) solves the problem. The amount of data in memory will be minimal,
but the percent residency of this size of a cache is already miniscule, so this will
make no measurable difference in performance.
b. Increase the target file header ratio(s). If you experiment, you will find that
increasing the target file header ratio, even raising it to the maximum of 36:1,
has no effect on the cache sizing calculations. The problem is that the memory
cramp has already forced the file ratio to be too large. So theres nothing to be
gained there.
c. FSC only: Make the read and write caches asymmetrical. The customer has
already done this. The read cache is twice the size of the write cache.

d. Reduce the target hash ratio(s). Setting this (cell B29) to about 9.77:1 or less
solves the problem, too. You lose a notice doing this, but a hash ratio of 9.77:1
is pretty close to the recommended 10:1 ratio, and once again no measurable
performance difference.
e. Reduce the total cache size. If you follow this course of action, a little trial-and-
error will tell you that reducing the write cache size (cell B21) to about 510048
MB (498 GB) or less will do the trick and the customer may be willing to live
with that.
The process of arriving at a decision of how (and whether) to reduce the cache size, the
segment file size, or the hash ratio is somewhat discretionary at this point. In this
particular case, I would probably choose to reduce the segment file size. If I had to
squeeze too much more cache into memory, I would be tempted to consider a
combination of all of the above methods.

5. Now lets look at the WARNINGs.
a. Both caches displays the warnings: FILE HEADER RATIO INCREASED.
and NOTE: CACHE SIZE REDUCED WITH FILES < 576 KB. We know that the file ratios
are maxed out; we know that this is a memory thing, and we know that were already
stretched to the limit.

b. The XML output of this cache appears as follows. This can be pasted into the

Example 3 (FCC cache)
Consider a customer who wants an FCC segment cache size of 256GB (256 x 1024 = 262144 MB). The
FSC is running on a 32-bit machine, running a Solaris 32-bit operating system, with 4GB of RAM, and
Teamcenter 8.1. The FCC cache would be configured as follows:
1. Since this is an FCC configuration, starting with the cache size and working forward, select the
\FCCClientCalc/ tab in the bottom tab row of the FMS Cache Sizing Tool spreadsheet.
2. Select Unix32 as the platform.
the macros, enter the memory allocation value of 1792 MB into the Memory (MB) fast cache
input cell. Enter the other initial values from the leftmost column into the green input fields.
Your form should now look like this:

output is displayed, but is not yet optimized.

5. Looking at WARNINGs and NOTICEs. I will start with the upper left and work clockwise around
the form.
a. The cell above the Ext File Size reads LARGE EXT SIZE (DELAYS)
This is not a desirable situation. In order to make an FCC segment cache this large, the
extent files need to be bigger than 64MB. That means cache operation (and therefore
FCC operation) may occasionally pause for however long it takes to create an empty
272 MB extent file. The customer needs to know that this will happen. If this is not
acceptable, then the segment cache size must be reduced.
b. The cell next to the File Pages reads: FILE HEADER RATIO INCREASED.
Because it is so large, this segment cache is configured to use the maximum number of
file pages allowable for a 32-bit cache. The segment caches file header ratio (target
value 1:1 from green input cell B13) has been increased to 8.01:1 (displayed in
intermediate calculation cell O13) to allow the requested number of segments to be
defined in the cache. This is not necessarily a cache capacity problem, as long as the
cache is used to store enough data from each file (GUID).
c. The cell next to the File Ratio reads: NOTE: CACHE SIZE REDUCED WITH FILES <144
KB
This is fallout from the increased file ratio. If the segment cache stores less than an
average of 144KB of each file, then the cache will run out of file headers before it runs
out of segment space. If the segment cache stores only 16KB of each file, then it will run
out of file headers after storing 32767 MB (32 GB) of data (cells O12 and Q12),
effectively making the cache only 12% of its configured size (cell R12).
Since this is occurring because a hard limit (number of file pages) has been reached,
there is not much a customer can do about this (except possibly buy a 64-bit machine).
d. The cell next to the Hash Ratio reads: FAST LOOKUPS
This is displayed in green text, so it is a notice. The h ratio of the segment cache is
10:1, which means that the probability of experiencing a hash collision on any given
lookup is low. This means that the segment cache will be able to look up file GUIDs
quickly in the hash table.
e. The cell on the bottom row reads MEMORY AVAILABLE. TRY INCREASING TARGET
SEGMENT FILE SIZE. . Above, another warning reads Try Target Segment Size, and
points to a cell that suggests a segment size of 686 MB. This is an efficiency
improvement that could be beneficial to the speed and operation of the cache. Enter
the value 686 as the Target Segment File Size for this cache (cell B9).

Note that the excess memory warning disappears when you do this.



f. The XML output of this cache appears as follows. This can be pasted into the
<fccdefaults> section of the customers fcc.xml configuration file.



<property name="FCC_MaximumNumberOfSegments" value="43904" overridable="true"/> 
<property name="FCC_MaxExtentFiles" value="962" overridable="true"/>
<property name="FCC_MaxExtentFileSizeMegabytes" value="272" overridable="true"/> 
<property name="FCC_MaximumNumberOfFilePages" value="2097151" overridable="true"/> 
<property name="FCC_HashBlockPages" value="163840" overridable="true"/> 

Example 4 (64-bit FSC server)
Consider a customer who wants an FSC read cache size of 1000 GB (1000 x 1024 = 1024000 MB), and an
FSC write cache size of 500 GB (500 x 1024 = 512000 MB). The FSC is running on a 64-bit machine,
running a SUSE Linux 10.0 64-bit operating system, with 8GB of RAM, and Teamcenter 8.3. The FSC
cache would be configured as follows:
2. Since this customer is running Teamcenter 8.3 on a SUSE Linux, select Unix64 as the platform.
the macros, enter the initial values from the leftmost column into the green input fields, and
enter 7680 as the maximum memory for both fast caches. Your form should now look like
this:

output is displayed, but is not yet optimized.
7. Looking at WARNINGs and NOTICEs.
a. The cell next to each caches File Pages reads: FILE HEADER RATIO INCREASED.
The file ratio of both caches is approximately 6.8:1. The FMS Cache Sizing Tool has
calculated the number of File Pages and Hash Pages that will fit in the allocated
memory, and raised the file header ratio to fit in an 8GB process memory area. No
problem here.

b. The cell next to each caches File Ratio reads: NOTE: CACHE SIZE REDUCED WITH
FILES <112KB
This is fallout from the file header ratio change, but most Teamcenter files are larger
than this, so this ratio should not be problematic.
c. The cell next to each caches Hash Ratio reads: FAST LOOKUPS
This is a notice. The hash ratio of the read cache is 10:1, which means that the
probability of experiencing a hash collision on any given lookup is low. This means that
the segment cache will be able to look up file GUIDs quickly in the hash table.
d. The XML output of this cache appears as follows. This can be pasted into the

Example 5 (Analysis, resizing a cache)
A customer used the FMSCalc tool to size their 100MB FCC cache two years ago, and now they want to
expand their client cache. They added extent files to the old configuration, but the cache still does not
seem to grow beyond the original 100MB size, and it never creates extent files. Whats wrong?

Here are the settings they used two years ago:
<property name="FCC_MaximumNumberOfSegments" value="6400" overridable="true"/>
<property name="FCC_MaxExtentFileSizeMegabytes" value="16" overridable="true"/>
<property name="FCC_MaximumNumberOfFilePages" value="178" overridable="true"/>
<property name="FCC_HashBlockPages" value="14" overridable="true"/>

The new settings are:
<property name="FCC_MaximumNumberOfSegments" value="6400" overridable="true"/>
<property name="FCC_MaxExtentFileSizeMegabytes" value="16" overridable="true"/>
<property name="FCC_MaximumNumberOfFilePages" value="178" overridable="true"/>
<property name="FCC_HashBlockPages" value="14" overridable="true"/>

They are expecting a cache size of 1600MB + 100MB = 1700 MB.


Plugging these values into the \FCCClientAnalyzer/ page of the FMS Cache Sizing Tool, we see what has
happened:
BEFORE:

AFTER:

What has happened here is that the old FMSCalc utility operated at the max file ratio (36:1), meaning
that there are zero excess file pages. When the customer added segments, thinking that they were
increasing the size of the cache, they added no additional file pages to reference those new segments.
So the maximum amount of data that this cache can reference is all in the segment file. When the cache
needs to add more data, it has to free a file page, which in turn frees 36 segments in the segment file,
which it then uses for the new data. The cache never needs to create an extent file. Thus the NOT
ENOUGH FILE PAGES error displayed on the form. There are not enough file pages to reference the
segments in the extent files. The file ratio is a whopping 611:1!


To properly resize this cache, lets use the \FCCClientCalc/ page of the FMS Cache Sizing tool. Entering
the proper input parameters, then copying the recommended segment file size of 1023MB into Target
Segment File Size field, the output is as follows:

and all three NOTICEs are retained.
(You might note that the actual cache size is 1711 MB. If you change the segment file size to 1012MB,
you will get a very similar cache configuration thats exactly 1700 MB in size.)
The customer can get a 1700 MB segment cache, with only 43 small extent files, and 700MB of free
memory space to boot!

Example 5 Whats the biggest segment cache possible, and what cache size is optimum for me?
That depends on a lot of qualifying parameters. Does the cache need to be efficient? How much
memory can this cache consume? Is this running on Windows or Unix? Is it running on a 64-bit
machine?
Lets assume an FSC server on a 64-bit machine with 1000GB (1024000 MB) of RAM available (well
leave the other 24 GB of its 1TB memory for the OS and a RAC client). Go to the \FSCServerCalc/ page of
the FMS Cache Sizing tool, and start entering parameters
Select 64-bit Windows, and give it 1024000 MB of memory. Even if you are using the macros, override
the recommended values by entering a target segment file size of 1MB, target 33554416MB per extent
file, a target file header ratio of 36:1, and a nominal target hash ratio of 1:1. For the write cache, enter a
nominal value of 1MB for the cache size, 1MB for the segment file size, a target file header ratio of 36:1,
and a nominal target hash ratio of 1:1. Then keep cranking up the size until the first time it errors. The
largest cache I can make out of this is 1170494128 MB (1143060 GB thats 1116 TB of segment cache).

Is this ridiculous? Yes, probably. This cache consumes 1000 GB of shared memory, almost all of which is
in huge extent files. It has the worst possible file ratio, the worst possible hash ratio, a very big extent
file size, and it will probably perform very poorly under duress.
Will it work? I have no idea. I dont have a machine with a TB of RAM to test it with. But if I did, I would
think it would probably take more than 3MB of RAM for the OS to manage the other 1000GB of shared
memory.

A little more realistic is the maximum recommended cache size
Lets assume an FSC on a 64-bit Windows machine with 8GB of RAM available per FSC process, and a
nominal 128MB write cache. Go to the \FSCServerCalc/ page of the FMS Cache Sizing tool, and start
entering parameters


<property name="FCC_MaximumNumberOfSegments" value="65472" overridable="true"/> 
<property name="FCC_MaxExtentFileSizeMegabytes" value="16" overridable="true"/> 
<property name="FCC_MaximumNumberOfFilePages" value="109504" overridable="true"/> 
<property name="FCC_HashBlockPages" value="8555" overridable="true"/> 

64-bit Windows, give it 7680 MB of memory (leaving 512 MB for the rest of the FSC process), a target
segment file size of 16MB, target 33554416MB per extent file, a target file header ratio of 1:1, and a
nominal target hash ratio of 1:1. Then keep cranking up the size until the first time it shows a FILE
RATIO INCREASED warning for the read cache. The largest cache I can generate is 207360 MB (about
202 GB).

Will this cache work? I havent personally tested it, but it has an acceptable file ratio, hash ratio, and
extent file size, and it will probably perform quite well.

At this point, the tool will keep upping the file ratio until it maxes out at 36.00. So keep cranking up the
size until the first time it errors. The largest cache I can make out of this is 7913088 MB (about 7728 GB
or 7.5 TB). After that, I run OUT OF MEMORY. Depending on the customers actual file sizes, whether
they are using this segment cache in conjunction with a whole file cache, and how much of each file is
requested in random access mode, the optimum file ratio will vary, but the optimum cache size for most
customers will probably lie somewhere between 200 GB and 5 TB.

Example 6 Whats the biggest segment cache possible on a legacy HP system?
This gets much more constrained. Legacy HP systems did not support extent files, so all of the cache
data had to be in the segment file. This means the segment cache had to have 100% data residency. In
fact, this is such a special case that we were asked to add special \OldHP_FSC/ and \OldHP_FCC/ pages
to the FMS Cache Sizing Tool to deal with these special cases. These function very much like the other
pages, but differ from the normal Unix use cases in that:
The number of extent files is always zero (0).
The extent file size is always 16MB.
The target segment file size is always the same as the target cache size.
As a result, there are only three inputs per cache: The cache size, the file ratio, and the hash ratio.

Selecting the \OldHP_FSC/ and \OldHP_FCC/ pages, setting the target file header ratio to 1:1 and the
target hash ratio to 10:1, a little experimentation gives us almost immediate results. (There is not much
to tweak.)

32-bit (RISC):
In a 32-bit environment, assuming a file header ratio of 1:1 and a hash ratio of 10:1, the largest possible
cache is 1023 MB (almost 1GB). The limitation here is that this is the largest segment file that the
segment cache allows.
On an FSC, a 1023MB write cache also leaves room for a 500MB write cache with the same file header
ratio and hash ratio.



64-bit (HP-Itanium):
In a 64-bit environment, we recommend a maximum memory consumption of 8GB per FSC.
FSC: Select the \OldHP_FSC/ page
8192 MB memory, less 512 MB for the FSC, leaves 7680 MB available for the segment cache. Enter
7680 as the target memory (MB) for both caches.
Lets assume that we can live with a write cache that is 10% of the size of the read cache. This
number could be 50%, or whatever the customer chooses as a suitable ratio. We will set the write
cache size as proportional to the read cache size, and then only manipulate the read cache size. The
write cache size is cell B21, and the read cache size is cell B7. In cell B21, enter the following
formula in the spreadsheet:
=ROUNDDOWN(B7*0.1,0)
Notice that as soon as this formula is entered, the value in cell B21 becomes 10% (or 50%, or one-
third, etc.) of the read cache size (cell B7), rounded down to the nearest whole number. For
example, I had a value of 1023 in cell B7, and cell B21 now contains the value 102.
If you enter a constant number here, the formula will cease to function.
Now increase the value in cell B7 until you see warnings or errors. I can get cache sizes of about
6744/674 MB before the file pages start to cramp, and 6970/697 MB before the caches run out of
memory altogether.

FMSCacheSizingTool Instructions v1 2

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

FMSCacheSizingTool Instructions v1 2

Transféré par

Droits d'auteur :

Formats disponibles

FMS Cache Sizing Tool Version 1.

Vous aimerez peut-être aussi