Guideline
TM1 Server Administration
Product(s): TM1 v.9.1 and prior
Copyright
Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC is an IBM Company. While every attempt has been made to ensure that the information in this document is accurate and complete, some typographical errors or technical inaccuracies may exist. Cognos does not accept
responsibility for any kind of loss resulting from the use of information contained in this document. This document shows the publication date. The information contained in this document is subject to change without notice. Any improvements or changes to the information contained in this document will be documented in subsequent editions. This document contains
proprietary information of Cognos. All rights are reserved. No part of this document may be copied, photocopied, reproduced, stored in a retrieval system, transmitted in any form or by any means, or translated into another language without the prior written consent of Cognos. Cognos and the Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated) in the United States and/or other countries. IBM and the IBM logo are trademarks of International Business Machines Corporation in the United States, or other countries, or both. All other names are trademarks or registered trademarks of their respective companies. Information about Cognos products can be found at www.cognos.com
This document is maintained by the Best Practices, Product and Technology team. You can send comments, suggestions, and additions to
Contents
1 INTRODUCTION ... 4
1.1 PURPOSE...4
1.2 APPLICABILITY...4
1.3 EXCLUSIONS AND EXCEPTIONS...4
2 SERVER SIZING GUIDELINES – TM1 9.X ... 4
2.1 USING THE TM1SIZING GRID TO DETERMINE AN OPTIMUM TM1CONFIGURATION...4
2.2 USING SIZING METRICS TO DETERMINE AN OPTIMUM TM1CONFIGURATION...6
2.2.1 Defining Users...6
2.2.2 Estimating Model Size ...7
2.2.3 Defining Topology ...9
2.2.4 General Server Hard Drive Guidelines...9
3 TM1 SERVER CAPACITY PLANNING GUIDELINES ... 10
4 TM1 SERVER UPTIME/RESTARTING GUIDELINES ... 10
4.1 RECYCLING THE TM1SERVER... 10
4.2 SAVING THE DATABASE... 10
5 MONITORING MEMORY USAGE ... 11
5.1 SERVER LEVEL MEMORY STATISTICS... 11
5.2 CUBE MEMORY STATISTICS... 11
5.3 MEMORY CONSUMPTION FOR OTHER OBJECTS... 12
6 STARTING AND STOPPING THE TM1 SERVICE USING NETSVC... 12
6.1 PREREQUISITE... 12
6.2 CREATING THE BATCH FILES... 12
6.2.1 Creating stop_tm1.bat... 12
6.2.2 Creating start_tm1.bat ... 12
1
Introduction
1.1 Purpose
This collection of articles focuses on the administration, planning, and sizing of the TM1 server hardware.
1.2 Applicability
IBM Cognos TM1 version 9.1 and prior releases
1.3 Exclusions and Exceptions
No exclusions have been identified at this time.
2
Server Sizing Guidelines – TM1 9.x
The purpose of this section is to provide a sizing guide for TM1 installations. Due to the inherent differences between one TM1 installation and the next, this guide is really just that – a guide.
You can use the TM1 Sizing Grid to determine a typical minimum configuration solution. Alternatively, you can review known TM1 and system metrics to more accurately determine an optimum configuration.
2.1 Using the TM1 Sizing Grid to Determine an Optimum TM1 Configuration
Admin = Admin/Power User, RW = Read/Write user, RO=Read Only or Reporting user, often Web-based. To use the grid, locate the recommended configuration at the intersection of the user community and model size that most closely correspond to your implementation.
For example; if you have roughly 100 users, and the vast majority of those users are
read-only users, your implementation most closely resembles the Heavy Reporting user
community. If your TM1 model is smaller than 3 GB, but larger than 1 GB, your
implementation most closely resembles the Model < 3GB model size. You will find your
recommended configuration at the intersection of the Heavy Reporting user community
The recommended configuration suggests that you should use a twin CPU 64-bit TM1 server with 6GB RAM for the Read/Write users (5), and a twin CPU Reporting Server with 8GB RAM for Read-Only users (95).If you require a TM1 Web server, it should have a single processor and 2 GB RAM to support 100 users.
2.2 Using Sizing Metrics to Determine an Optimum TM1 Configuration
The size of a TM1 model can be estimated from known data (a POC using a subset of real data, known dimensionality, or known data to be loaded) but there will always be unknown factors such as the space required for view storage, feeders, hierarchies and rule calculations. The basic process is as follows:
Each step in the process is described in the sections that follow. 2.2.1 Defining Users
Sizing recommendations are based on the assumption of peak concurrent user counts as defined below. Define the planned number of concurrent users based on the definitions below.
Each concurrent user will require 20 MB RAM on the TM1 server when connected so knowing the total concurrent user community is important.
2.2.1.1
Power Users (Admin)
Power users are logged into TM1 for the majority of the day. They load data, update models and objects, and create complex reports and views.
Calculate concurrency as 100% of total Power Users (or 1:1).
2.2.1.2
Read/Write users (RW)
Read/Write users update data in the model on a regular basis. They also create/view complex reports and views.
Calculate concurrency as 33% of total Read/Write users (or 3:1).
2.2.1.3
Read Only/Reporting users (RO)
Read Only users do not generally enter any data. They use pre-defined reports in Excel or TM1 Web and require fast access to data.
Calculate concurrency as 10% of total Read Only users (or 10:1)
2.2.1.4
Estimating RAM Requirements Based on User Types
The following table illustrates how defining users helps you determine the amount of RAM required for your TM1 implementation.
User Type Total Number Concurrency Factor Concurrent Users Power User 2 100% or 1:1 2
Read-Only User 100 10% or 10:1 10
Total Concurrent Users = 16 RAM Required= 16 * 20MB =320MB
2.2.1.5
Further User Considerations
There are a number of questions to consider after defining a user community based on the definitions above. The answers to these questions should be used to alter the server specification as necessary.
• Will the majority of users be primarily TM1 Web users? If so, consider a separate
TM1 Web Server.
• Will the Read-Only/Reporting users require fast access to static reports while data is
still being uploaded/changed? If so, consider a Reporting Server topology.
• Will the Read-Only users request reports simultaneously, and is reporting
performance important? If so, consider a Reporting Server and/or multiple processors.
2.2.1.6
Multiple CPU Guidelines as Related to Number of Users
As a rule of thumb, a TM1 server can handle 25 Read/Write users per CPU and up to 100 Read-Only users per CPU.
In general, adding CPUs to a TM1 server will benefit Readers more than it will benefit TurboIntegrator users or Writers (as these two will lock the whole server for periods). Each Read request will occupy 100% of a CPU, so more CPUs will allow more concurrent Read requests.
In situations where the Writers might lock the server to the detriment of the Readers, a Reporting Server is recommended.
For more information, see the Principles of TM1 Multi-Process and Multi-Threaded Usage
chapter in Optimizing TM1 Performance.
2.2.1.7
Provisioning RAM in the Absence of Application Metrics
In the absence of any information about the application, provision a minimum of 2GB of RAM. As TM1 is sensitive to the server reaching its physical RAM limit (e.g. virtual memory paging severely degrades server performance), it is good practice to fully populate Win32 servers with 4GB, as it typically only adds a small percentage to the overall purchase price, and makes the hardware platform future-proof until a migration to 64-bit is necessitated. If there is a requirement for large amounts of data (over 3GB), a 64-bit solution is
mandatory. In a green-field situation, IBM preference is Windows64 over UNIX, given its high degree of compatibility with Win32, support for all Microsoft interface technologies (ODBC, ODBO), and ease of maintenance and administration. However, both the HP-UX and Solaris platforms are supported.
2.2.2 Estimating Model Size
An accurate estimate of TM1 model size can only be calculated from a real-world model built on actual data (such as a POC model using a proportion of the actual model’s data).
If a real-world model is not available then use either an estimate based on data to be loaded into the model or choose one of the reference systems given in the Sizing Grid above.
Estimation using known data volumes is a fairly simple process and is useful for getting a feel for the order of magnitude of the data.
• Each data item loaded into TM1 will occupy, on average, 14 bytes of RAM.
• Each calculated member will proportionally increase the data.
Data 1,000,000 rows with 12 data items in each row=
12,000,000 * 14 bytes = 160MB
Model for 5 years of data = 801MB
Calculations Calculated Forecast is one year of extra
calculations = 160MB
Users 10 Users =10 * 12 MB = 120MB
Total Model Size 801+160+120 = 1.1GB
2.2.2.1
The Effects on RAM of 64-bit Technology
64-bit technology expands the RAM available in Windows and UNIX to levels now limited only by the hardware available.
As noted in the 64-bit Considerations chapter of Optimizing TM1 Performance, a 64-bit
TM1 installation on a 64-bit operating system requires between 30% and 100% more RAM due to the larger memory pointers required.
Operating System TM1 Version Max RAM in OS
Max RAM for TM1 Windows 2000 or 2003 32-bit TM1 32-bit 4 GB 3 GB TM1 32-bit Unlimited* 4 GB Windows 2003 64-bit
TM1 9 64-bit Unlimited* Unlimited*
UNIX (Sun, HP) TM1 9 64-bit Unlimited* Unlimited*
*limited only by hardware
2.2.2.2
General CPU Guidelines
TM1 performs better on Xeon chips than Pentium 4s, as Xeons have fewer consumer-oriented features (e.g. 3D gaming extensions).
EM64T-capable processors (64-bit - Intel Xeon 64, AMD 64), allow for RAM growth beyond the 32-bit 3 GB limit to theoretically limitless quantities. They support both Windows 32-bit and Windows 64-bit. It is recommended now to buy EM64T processors if possible for future growth potential.
Also available are ‘dual core’ processors that provide Symmetrical Multi-Processing (SMP) capability in a single chip package (Intel Core Duo, etc). Treat these as two processors for sizing purposes.
For all but the simplest applications the host machine should be SMP capable. This is a binary procurement decision – a given server is or is not SMP-capable, and cannot be upgraded at a later date.
Procure the fastest processor speed, largest processor cache size and fastest Front Side Bus speed your budget will allow. After SMP processor count, these three factors have the biggest impact on TM1 performance.
2.2.3 Defining Topology
TM1 Topology is fairly simple; in most cases the TM1 server stands alone with perhaps a TM1 Web server providing Web access to the applications.
There is a case, however, to sometimes introduce a Reporting Server into the topology to increase the performance of reporting users.
2.2.3.1
Reporting Servers
A Reporting Server is generally a Read-Only replicated and synchronized TM1 server that is refreshed at a set frequency from the ‘live’ server (once per day is typical). The Reporting Server is used to service all the reporting users so that their requests to not affect, and are not affected by, Read/Write activity on the main server.
As a rule of thumb, a Reporting Server is recommended when the Read-Only community outweighs the Read/Write community by a factor of five and there is constant Read/Write activity on the main server.
2.2.3.2
TM1 Web Servers
A separate TM1 Web server is always recommended, but a 10-user system with sufficient free resources on the server could get away with running both the TM1 and Web servers on a single server.
2.2.3.3
TM1 Web Servers
In general, TM1 Web should always run on a separate server if possible. The general rule of thumb for sizing a TM1 Web server is up to 250 concurrent users per CPU, as detailed in the following table. Number of TM1 Web Users Number of Processors Recommended on TM1 Web Server 1-100 1 Processor 101-500 2 Processors 501-1000 4 Processors 1001-2000 8 Processors
It is also possible to use multiple TM1 Web servers if you have a significant number of TM1 Web users.
2.2.4 General Server Hard Drive Guidelines
The host machine’s disk subsystem can be almost ignored – procure the smallest local disk available (anything over 72 GB should be sufficient).
Unfortunately, most server-class machines come with fault-tolerant disk subsystem (e.g. hot-pluggable SATA RAID), which is expensive yet all but wasted on TM1’s RAM-resident database. Two exceptions to this rule:
• If you plan on staging/storing very large ASCII files for ETL purposes on the local
disk of the TM1 Server host machine, plan accordingly.
• Similarly, if you plan on storing many large Binary Large Objects (BLOBs ) in TM1
Applications, you will require a sufficient amount of disk storage, as BLOBs are stored directly on disk.
3
TM1 Server Capacity Planning Guidelines
Use the following guidelines to plan a TM1 server implementation:
• For the TM1 Server, allot one CPU per 25 read/write users or 100 read-only users
• For TM1 Web, allot one CPU per 100 users (any mode)
• Assume a requirement of 16 bytes per non-null cell to estimate total server RAM
requirements
• Keep 25% of physical RAM in reserve (e.g. 3 GB of physical RAM yields 2.25 GB of
usable RAM)
• TM1 server operating in 32-bit mode on X64 can expand to 4GB of usable RAM
• PAE/AWE does not extend the usable RAM of a TM1 server instance (but, mutiple
instances can run on a single host machine)
• Allot 20 MB of server RAM for each active client session
4
TM1 Server Uptime/Restarting Guidelines
This article describes recommended practices for recycling the TM1 server and saving the TM1 database.
4.1 Recycling the TM1 Server
Even though TM1’s memory management is very stable and some users run the TM1 server uninterruptedly for weeks or months, IBM recommends recycling the server on a weekly basis or after loading a large amount of new data. Such periodic recycling ensures a more compact and efficient storage scheme.
If the TM1 server is running as an application, the server may be stopped automatically by
setting the Tm1s.cfg parameter Downtime. Alternatively, the TM1 server can be stopped and
restarted using an external scheduler.
4.2 Saving the Database
A database save writes all changed cubes to disk storage and restarts the transaction log. The TM1 database should be saved nightly; this prevents log files from getting unmanageably long and reduces the recovery time in case of hardware or software failure.
• Setting the Tm1s.cfg parameter SaveTime
• Scheduling a TurboIntegrator process to execute the SaveDataAll function
If you process data through TurboIntegrator or processing worksheets with cube logging turned off, a database save should be performed immediately after the data load is complete. When processing data through TurboIntegrator, this can be accomplished by calling the SaveDataAll function in the Epilog of the TurboIntegrator process.
5
Monitoring Memory Usage
There are three sources of information on memory consumption by a TM1 server:
• The operating system performance monitor or task manager.
• The TM1 Performance Monitor.
• The TM1 client.
TM1 allocates memory as it needs it from the operating system. However, when it frees memory, it does not return it to the operating system, but puts it in a garbage list which it then reuses as needed. Accordingly, the operating system performance monitor will not give you an accurate measure of the current consumption of memory of the TM1 server. Instead, IBM recommends using the TM1 Performance Monitor, as described in the TM1 Administrator's Guide.
5.1 Server Level Memory Statistics
The TM1 Performance Monitor keeps the following memory statistics for the server as a whole:
• Memory Used • Memory In Garbage
The sum of the two quantities should correspond to the memory consumption reported by the operating system performance monitor.
5.2 Cube Memory Statistics
The TM1 Performance Monitor keeps the following memory-related statistics for each cube in the server:
• Total Memory Used
• Memory Used for Input Data • Memory Used for Feeders • Memory Used for Calculations • Number of Fed Cells
• Number of Populated Numeric Cells • Number of Populated String Cells • Number of Stored Calculated Cells • Number of Stored Views
Full details of all performance monitoring cubes and dimensions can be found in the TM1 Administrator's Guide.
5.3 Memory Consumption for Other Objects
The memory consumed by dimensions, subsets and other objects appears in the properties window of the TM1 Server Explorer.
Note that the memory displayed for views is only the memory required to store the definition of the view. The memory used to store the values associated with the view will appear in the “Memory Used for Views” item produced by the performance monitor associated with the cube to which the view belongs.
6
Starting and Stopping the TM1 Service Using netsvc
The following procedure describes how to use the netsvc command in batch files to start and stop a TM1 server installed as a service on Windows 2000. (The netsvc command is not available on Windows XP.) The batch files can be scheduled for execution through the Windows Task Scheduler, allowing you to automatically recycle your TM1 server at regular intervals as recommended by IBM.
6.1 Prerequisite
The netsvc command is part of the Windows 200 Resource Kit, which must be installed before you can successfully complete the procedure described below.
6.2 Creating the Batch Files
You must create two batch files, one to stop the TM1 server and one to start the TM1 server. Before you create these files, make sure you know the name of the computer on which the TM1 server is installed (computer_name) and the name of the service assigned to the TM1 server (service_name).
6.2.1 Creating stop_tm1.bat
The stop_tm1.bat file contains a single command to stop the TM1 server.
1. Start Notepad or your preferred text editor.
2. Enter the following line in the text file: netsvc /stop \\computer_name "service_name"
For example, if your TM1 server is running as a service named "TM1 Server - SData" on a computer named CorpData, you would enter the line
netsvc /stop \\CorpData "TM1 Server - SData".
3. Save the text file as stop_tm1.bat.
6.2.2 Creating start_tm1.bat
The start_tm1.bat file contains a single command to start the TM1 server.
1. Start Notepad or your preferred text editor.
2. Enter the following line in the text file: netsvc /start \\computer_name "service_name"
For example, if your TM1 server is running as a service named "TM1 Server - SData" on a computer named CorpData, you would enter the line
netsvc /start \\CorpData "TM1 Server - SData".
3. Save the text file as start_tm1.bat.
6.3 Scheduling Batch File Execution in Task Scheduler
To schedule a time to stop and start the TM1 server, complete the following steps for both tm1_stop.bat and tm1_start.bat.
You should set up your schedule so that tm1_stop.bat is executed first, followed by tm1_start.bat. When creating the schedule, allow sufficient time for the TM1 server to completely shut down. For example, if you schedule tm1_stop.bat to run at 11:00 PM, schedule tm1_start.bat to run at 11:10 PM.
1. From the Windows taskbar, click Start Control Panel Scheduled Tasks.
2. Double-click Add Scheduled Task.
