14.1 Resources

Resource Requirements Overview

Significant amounts of resources such as RAM, filestore, sockets and file handles can be consumed on the server(s) on which ServiceOptimizer is running. ServicePower Consultants can offer advice on predicted loads so that the system can be suitably configured. However, it is the responsibility of the system administrator to ensure that sufficient resources are allocated. Mechanisms for allocating resources are OS-specific, so in general this guide does not cover them in detail.

The following gives a high level view of the major types of resources impacting on the various parts of the system:

Component	FileStore	Memory	Ports/Sockets	Timeouts	File Handles	Comment
System Monitor						14.1 System Monitor 1 has a smallish footprint. Its main requirement is connectivity to both the database server and all other components (across the various, possibly distributed, system).
API Agent						14.1 API Agent has a number of threads within the application, dealing with the multiple connections from the client applications and passing them through to the FRUs, It is an important central part of the instance and the logfiles are invaluable as part of any investigation into a failure, so they need to be quite large.
Gantt Router						14.1 Gantt Router has a number of threads within the application, dealing with the multiple connections from the client applications and passing them through to the FRUs, It is an important central part of the instance and the logfiles are invaluable as part of any investigation into a failure, so they need to be quite large.
FRU process						14.1 FRU Process use many threads, and a large amount of memory. Their logfiles can generally be kept small, but at times logging needs to be increased for investigation purposes.
Database Server						Whilst the ServicePower database is not generally large in the scheme of database in general, it does have alot of 'real time' accesses to various tables. Performance is paramount, so it is important that resources are configured to ensure this.
ServiceOptimizer Clients

Some of the more regular pitfalls are described in detail below.

TIME_WAIT

A problem can arise when client applications attempt to establish a large number of short-lived ServiceOptimizer connections.  In this instance, even though there may be no current connections, the server may fail to supply a new socket.  The underlying cause of this is a mechanism of TCP/IP known as TIME-WAIT.  The symptoms for a ServiceOptimizer client encountering this problem could be a connection refusal or a failure to get a response from the API resulting in a timeout.

The purpose of TIME-WAIT is to prevent delayed packets from one connection being accepted by a later connection (if the socket endpoint is recycled).  The OS does this by postponing closing a socket for a number of seconds to ensure that any outstanding packets are consumed. This means that the socket can still be in use for some time after ServiceOptimizer has closed it.  If there are a large number of short-lived connections then the number of sockets in the TIME-WAIT state can grow to such an extent that all available socket resources are in use.

There is often an OS-specific mechanism for configuring the TIME-WAIT delay: please consult your OS documentation.  It is however preferable to structure a ServiceOptimizer client application such that it does not need to establish a large number of short-lived connections in the first place: please contact ServicePower for advice.