Performance Tuning for Content Manager

Chapter 14. Maintenance 403

14.3 Monitoring LBOSDATA directory size

The LBOSDATA directory, an area of local disk that a Resource Manager

controls, is used to store objects.

When using fixed disk attached to the Resource Manager for object storage, be

sure that there is enough free space remaining for Content Manager to write

objects to. If Content Manager runs out of space to write objects to, any new

requests to store objects will fail.

Even when Tivoli Storage Manager (TSM) is used for the long-term storage of

objects, Content Manager may be configured to keep objects locally, and only

migrate to TSM after a period of time (for example, 30 days). The migration of

objects to TSM is triggered by the length of time the objects have resided in the

first storage class, assuming that there are only two storage classes and TSM is

the second one.

In this instance. it is possible that the local fixed volume that the LBOSDATA

directory resides on might become completely full if new objects are being added

to it faster than they are being migrated to TSM by the Content Manager migrator

process. This might occur during peak periods of object loading into Content

Manager, such as around the end of a financial year for an accounting company

that scans documents into Content Manager for reference purposes. In a

worst-case scenario, the process of migrating from the LBOSDATA directory to

TSM might not even be running.

During peak activity times, it is even more important to monitor the amount of

free space remaining in the local fixed disk that the LBOSDATA directory resides

on. Of course, these peak periods of activity should have been taken into

account when designing and sizing the system; nevertheless, monitoring the

directories is good practice. Operating system tools should be used to monitor

the current space occupied by the local objects and the amount of space

remaining on a physical or logical volume.

Important: Remember to have the Content Manager migrator process

running at all times, even if you do not migrate objects between storage

classes, because it is used to physically delete objects from where the

Resource Manager has stored them. When a user deletes an object from the

standard client, only the row from the Library Server database is deleted

immediately (for performance reasons), and the entry in the Resource

Manager database and the object itself remain. The

migrator must be run to

reclaim the physical storage space.

404 Performance Tuning for Content Manager

It is possible to see how many megabytes of storage remain on a particular file

system volume through the Content Manager system administration client, but

this value is not updated dynamically. If space is being used on a file system

volume while you are logged onto the system administration client, the number of

megabytes free on the file system volume will not change. To see the change in

volume free space, log off and log back onto the system administration client;

however, this is not an entirely accurate way to monitor free space.

When you create a file system volume for Content Manager to use, such as the

e: drive on a Windows machine, Content Manager takes the remaining free

space on this physical or logical volume as the amount of free space currently

available for objects. In other words, when you create a file system volume within

Content Manager, you cannot assign only a certain percentage of it to be used.

In the same way, Content Manager does not reserve space for its objects on a

file system volume. It is very important to make sure that no other applications

use the same volume to store dynamic data. If this occurs, the amount of free

space available to Content Manager to write objects can change unexpectedly.