OpenLM Application Manager optimal configuration

This document refers to OpenLM Applications Manager 1.9 as well as OpenLM Applications Manager 2.*.

Our recommendations

– VM network controller should be available for each network card.

– For compilers that perform multiple checkout/checkin in a second, we recommend a hardware. specification 25%-50% higher than that specified in the table at the end of this document.

For instance:-

– VM Administrators should make sure that the hosting server is capable of accommodating the required resources.

– When seeing low performance in DB queries, please check disk queue.

– We strongly recommend placing the DB in the same Data Center as OpenLM Server.

– See recommendations for MS SQL Server below.

– For MySQL we provide a sample configuration file for Windows (my.ini) & Linux (my.cnf) that should be revised by your DBA.

– In case of big databases (from 25GB and up) and big loads each DB should have 3 files and 3 VM disk controllers for: db file, log file and tmp file.

Best practices for using MySQL

1. Use the latest 5.7/8 MySQL release.

2. In order to utilize the system’s resources MySQL requires its configuration file (my.cnf/my.ini) to be set with the correct values. Otherwise MySQL will not take advantage of its hosting machine’s resources. We recommend some settings – please see our suggestions for configuration files archived in .zip format according to your system size:

4GB_2Cores_Windows

8GB_4Cores_Windows

16GB_8Cores_Linux

16GB_8Cores_Windows

24GB_8Cores_Windows

Best practices for using MS SQL Server

1. Customers need to apply a maintenance plan consisting of:

a) Periodic Statistics Update

b) Periodic Rebuild or Reorganization of Indexes

DBAs need to apply company maintenance policy also for OpenLM DB. In the case where such does not exist, a public package can be applied (Here is one).

2. Recommended memory allocation to MSSQL Server running (almost) exclusively on a windows machine should not exceed 80% of total machine memory.

3. OpenLM database should have is_read_committed_snapshot_on parameter set.

To check if it is set:

SELECT is_read_committed_snapshot_on FROM sys.databases

WHERE name= ‘YourDatabase’

To set:

DECLARE @sqlCommand varchar(1000)

DECLARE @db_name varchar(50)

SET @db_name = ‘YourDatabase’

SET @sqlCommand = ‘ALTER DATABASE ‘ + @db_name + ‘ SET ALLOW_SNAPSHOT_ISOLATION ON ‘

EXEC (@sqlCommand)

SET @sqlCommand = ‘ALTER DATABASE ‘ + @db_name + ‘ SET SINGLE_USER WITH ROLLBACK IMMEDIATE ‘

EXEC (@sqlCommand)

SET @sqlCommand = ‘ALTER DATABASE ‘ + @db_name + ‘ SET READ_COMMITTED_SNAPSHOT ON ‘

EXEC (@sqlCommand)

SET @sqlCommand = ‘ALTER DATABASE ‘ + @db_name + ‘ SET MULTI_USER ‘

EXEC (@sqlCommand)

4. For better performance we recommend installing tempdb, databases and log files on separate logical (and in some cases – even physical) disks.

A solid installation would have:

a) 1- disk for tempdb Data (ssd configuration is recommended)

b) 1- disk for system DBs (msdb, model, master)

c) 1- disk for all logs (including tempdb logs)

d) 1- disk for all DBs Data

5. tempdb has a critical role, having all parameters, temporary tables and executing sorts and aggregations. Number of tempdb data files is recommended to be the same as number of processors – up to 8 (more will have no effect or a negative effect  on performance).

6. Autogrowth units of database files is set by default to a percentage, which is dangerous. A good practice would be to use MB units, based on a predicted growth multiplied by record size. In any case, setting alerts on disk size is recommended.

7. It is recommended to set the log size upfront.

8. A regular backup program is recommended in order to be able to resume after crashes and to control the growth of  log files. Shrinking a database is a bad practice and is not recommended.