Environment Optimization Guide

Environment Optimization Guide
Environment Optimization Guide
Version 8.2 | April 17, 2015
For the most recent version of this document, visit our documentation website.
Table of Contents
1 Overview
7
1.1 Release updates
7
1.2 Training and support
7
1.3 Environment optimization checklist
7
2 Configuring Windows server
11
2.1 Microsoft Windows server service packs
11
2.2 Windows power plans and CPU performance
11
2.3 Windows visual effects
12
2.4 Windows processor scheduling
13
2.5 Windows NTFS fragmentation
13
2.6 Configuring virtual memory
14
2.7 Antivirus directory exclusion list
15
2.8 Management server
16
3 Configuring SQL Server
16
3.1 Optimize for ad hoc workloads option
16
3.2 Max degree of parallelism option
17
3.3 Cost threshold for parallelism
18
3.4 Optimize the tempdb database
19
3.5 SQL max server memory
20
3.6 Instant file initialization
21
3.6.1 Comparison of zero and instant initialization
22
3.7 File allocation unit size
22
3.8 Microsoft SQL server service packs
23
3.8.1 Determining the version of SQL server
3.9 Autogrowth settings
Relativity | Environment Optimization Guide - 2
23
24
3.10 SQL Server 2012 best practices analyzer
24
3.11 RAID levels and SQL server
25
3.11.1 Level 0
25
3.11.2 Level 1
26
3.11.3 Level 5
26
3.11.4 Level 10 (1+0)
26
4 Configuring the Analytics server
28
4.1 Memory requirements
28
4.1.1 Analytics indexing
28
4.1.2 Structured analytics
29
4.1.3 Enabled analytics indexes
29
4.2 Java heap size (JVM)
30
4.3 Page file size
30
4.4 Index directory requirements
31
4.5 Scaling
31
4.5.1 Tier 1 Example
31
4.5.2 Tier 2 Example
32
4.5.3 Tier 3 Example
32
5 Moving Analytics indexes and structured analytics sets
5.1 Moving the location of Analytics indexes and structured analytics sets
32
32
5.1.1 Moving the indexes and sets
33
5.1.2 Verify the new share
33
5.2 Migrating the Analytics server
34
5.2.1 Copying over the installation and indexes
34
5.2.2 Installing Analytics on the new server
34
5.2.3 Adding the Analytics server to Relativity
35
5.2.4 Verifying the migration
35
Relativity | Environment Optimization Guide - 3
5.2.5 Uninstalling the old Analytics installation
6 Setting up your workspace
35
36
6.1 Fixed-length vs. long text field types
36
6.2 Fixed-length text field considerations
36
6.3 Unicode support
37
6.4 Data imports
37
6.5 Analytics
38
6.6 Views and searching
38
6.7 Tally/Sum/Average mass operation
39
6.8 Group by for Pivot
39
6.9 User notifications
39
6.9.1 Message of the Day (MotD)
39
6.9.2 User status
39
6.9.3 Default workspace tabs
39
7 Monitoring environment performance
40
7.1 Windows and SQL server log analysis
40
7.2 Resource utilization
40
7.2.1 Monitoring disk usage
41
7.3 Analytics performance considerations
42
7.4 Server requirements for index builds
42
7.5 Memory requirements for querying
43
7.6 Server requirements for structured analytics
43
7.7 Native imaging and processing performance considerations
43
7.7.1 Native imaging and processing worker threads
44
7.7.2 Native imaging and Processing Queue
44
7.7.3 Relativity imaging working agents
44
7.7.4 Relativity Processing
44
Relativity | Environment Optimization Guide - 4
7.8 Performance Dashboard
45
7.9 SQL server table index fragmentation
46
7.9.1 SQL table indexes overview
46
7.9.2 Index fragmentation
46
7.9.3 Effects of fragmentation
47
7.9.4 Identifying fragmentation
47
7.9.5 Removing fragmentation
47
8 Managing your Relativity environment
8.1 Workspace management and maintenance
47
47
8.1.1 Analysis of long running queries
48
8.1.2 Full-text index management
49
8.1.3 Audit record table
50
8.2 SQL backups
51
8.2.1 Full backups
51
8.2.2 Differential backups
52
8.2.3 Transaction log backups
52
8.3 SQL recovery models
52
8.4 Relativity data backups
53
8.5 Check database integrity task
53
8.6 SQL table index management
53
8.6.1 Updating statistics
8.7 Database log management
54
54
8.7.1 Size management
54
8.7.2 Virtual log file (VLF) management
55
8.8 Shrink database task
55
8.8.1 Best practices
56
8.9 Job email notification alerts
Relativity | Environment Optimization Guide - 5
56
8.10 Relativity applications
9 Expanding your Relativity environment
56
56
9.1 Agents
57
9.2 Analytics servers
57
9.3 Dedicated web servers
58
9.3.1 Desktop Client import/exports
58
9.3.2 dtSearch performance
58
9.3.3 Physical memory on the SQL Server(s)
59
9.4 SQL Server failover clustering
60
9.5 Distributed Relativity SQL Servers
60
9.6 Web load balancing
61
9.6.1 Microsoft network load balancing
61
9.6.2 Relativity user load balancing
61
9.7 Terminal Services
62
9.8 Bandwidth tester
62
9.9 User notifications
62
9.9.1 Message of the day (MotD)
63
9.9.2 User status
63
9.9.3 Default workspace tabs
63
Relativity | Environment Optimization Guide - 6
1 Overview
This guide outlines the best practices for maintaining and optimizing a Relativity environment.
Follow these recommendations to ensure stability and optimal performance of all workspaces.
1.1 Release updates
Note the changes and additions to this guide for each service release:
n
n
n
There is a one-month pre-release of each Relativity version, allowing you to perform internal testing of
your integrations, processes, workflows, and extensions.
Patches are released once a month. You can view the Relativity release notes on the 8.2 Documentation site.
Verify that you're using the latest version of this guide. kCura updates this guide as new information is
obtained from field deployments.
1.2 Training and support
This guide is often provided to system admins who may not have any exposure to the Relativity
interface. For more information, you can access the following resources:
n
n
n
User tutorials - Our Relativity tutorials are designed to help users become familiar with Relativity
quickly. Using interactive tutorials that cover specific Relativity features, you can experience hands-on
learning at your own pace. To view these tutorials, visit the Tutorial page on kcura.com.
Documentation - We constantly strive to ensure that all users of Relativity are educated on the full functionality of the platform. To help you and your team stay well informed, we post all documentation on
this website. To access documentation from previous versions of Relativity, see the documentation
archives page.
Customer portal - You can access the Customer Portal from the kCura.com Support page. If you need a
portal account, please contact [email protected]
1.3 Environment optimization checklist
Use the following checklist to help manage and plan for your Relativity environment.
Reference
Release updates above
Training and support above
Training and support above
Training and support above
Configuring Windows server
on page 11
Microsoft Windows server
service packs on page 11
Task
Done
Review patch releases once a month.
Review user tutorials.
Review Relativity documentation.
Explore the Customer Portal.
Configure the Windows server for optimum performance.
Verify that the latest Microsoft server service pack is
installed.
Relativity | Environment Optimization Guide - 7
Reference
Windows power plans and
CPU performance on page 11
Windows visual effects on
page 12
Windows processor scheduling on page 13
Windows NTFS fragmentation on page 13
Configuring virtual memory
on page 14
Antivirus directory exclusion
list on page 15
Management server on
page 16
Configuring SQL Server on
page 16
Optimize for ad hoc workloads option on page 16
Max degree of parallelism
option on page 17
Optimize the tempdb database on page 19
SQL max server memory on
page 20
Instant file initialization on
page 21
File allocation unit size on
page 22
Microsoft SQL server service
packs on page 23
Autogrowth settings on
page 24
SQL Server 2012 best practices analyzer on page 24
RAID levels and SQL server
on page 25
Task
Configure Windows power plans for high performance.
Configure Windows visual effects for high performance.
Configure Windows processor scheduling.
Install an automatic disk defragmentation tool.
Manually set the size of the paging file to 4095 MB or
higher.
Exclude the SQL server, agent server, web server, Analytics
indices, dtSearch indices, and the file repository from the
antivirus software.
Create a management server with SSMS and the RDC.
Configure SQL server for optimum performance.
Optimize SQL server for ad hoc workloads.
Set max degrees of parallelism.
Optimize the tempdb databases.
Set SQL server max memory.
Enable instant file initialization.
Set the file allocation unit size.
Verify that the latest SQL server service pack is installed.
Set auto growth settings for SQL server files.
Install and run SQL server 2008 R2 Best Practices Analyzer.
Review RAID Levels and SQL Server storage options:
n
n
Verify that the tempdb data files reside on the fastest disks.
Verify that each SQL file resides on its own separate
disk.
Relativity | Environment Optimization Guide - 8
Done
Reference
Java heap size (JVM) on
page 30
Configuring the Analytics
server on page 28
Configuring the Analytics
server on page 28
Setting up your workspace
on page 36
Fixed-length vs. long text
field types on page 36
Fixed-length text field considerations on page 36
Unicode support on page 37
Data imports on page 37
Analytics on page 38
Task
Set the Java heap size to one-third of total RAM.
Configure the Analytics temporary directory.
If possible, store the Analytics index locally.
Set up you workspace following best practices.
Use fixed-length fields when possible.
Don't allow the size of a fixed-length field to exceed 8,060
characters, if possible.
Define the Unicode Enabled field property prior to import.
Don't run the Relativity Desktop Client on a Relativity production server.
Disable the integrated dtSearch index when creating a new
Analytics index, if possible.
Follow best practices for views and searching.
Views and searching on
page 38
Tally/Sum/Average mass
Create indexes on groups that you Tally on.
operation on page 39
Group by for Pivot on
Create a non-clustered index on fields that are being
page 39
grouped on for Pivot.
User notifications on page 39 Learn how to use various user notification methods.
Analytics performance con- Review Analytics performance considerations.
siderations on page 42
Monitoring environment per- Ensure you have the right amount of memory when creformance on page 40
ating indexes.
Native imaging and proReview native imaging performance considerations.
cessing performance considerations on page 43
Managing your Relativity
Review maintenance plan recommendations.
environment on page 47
SQL backups on page 51
Create backups for:
Relativity system databases
Relativity system database logs
n System databases and logs
Ensure Verify backup integrity is selected for full backups.
Set the SQL recovery models.
n
n
Full backups on page 51
SQL recovery models on
page 52
Relativity | Environment Optimization Guide - 9
Done
Reference
Relativity data backups on
page 53
Task
Create backups for:
dtSearch and Analytics index shares
Relativity web server install directories
n Native and image file shares
Schedule a weekly check database integrity test.
n
n
Check database integrity
task on page 53
SQL table index management on page 53
Updating statistics on
page 54
Database log management
on page 54
Shrink database task on
page 55
Job email notification alerts
on page 56
Set up and schedule the IndexOptimize smart script.
Update statistics to improve query performance.
Review database log management recommendations.
Ensure AUTO_SHRINK is not enabled.
Set SQL Database Mail on all Relativity SQL Servers and
add these notification alerts to all scheduled Relativity
maintenance tasks.
Monitoring environment per- Review environment monitoring guidelines.
formance on page 40
Windows and SQL server log Set up these alerts for SQL and Windows server logs:
analysis on page 40
n Low disk space on the servers
n Server becomes unresponsive
n Website becomes unavailable
Resource utilization on
Gather benchmarks for Relativity servers' resources.
page 40
Monitoring disk usage on
Measure disk latency.
page 41
Performance Dashboard on Install Performance Dashboard.
page 45
Workspace management
Create needed indexes on workspaces with 500,000+
and maintenance on page 47 records.
Analysis of long running
Analyze and try to optimize long-running queries.
queries on page 48
Full-text index management Manage full-text index.
on page 49
Audit record table on
If needed, manage the Audit Record Table.
page 50
SQL server table index frag- Understand, identify, and remove fragmentation.
mentation on page 46
Expanding your Relativity
Review Expanding your Relativity environment.
environment on page 56
Relativity | Environment Optimization Guide - 10
Done
Reference
Agents on page 57
Desktop Client import/exports on page 58
dtSearch performance on
page 58
Physical memory on the
SQL Server(s) on page 59
SQL Server failover clustering
on page 60
Distributed Relativity
SQL Servers on page 60
Web load balancing on
page 61
Terminal Services on page 62
Bandwidth tester on page 62
Task
Scale agents as needed.
Create a dedicated web server for the RDC and dtSearch
Done
Create a dedicated web server for the dtSearchWebAPI
Increase RAM on the SQL server if needed.
Create a SQL server failover cluster if needed.
Create a distributed SQL server if needed.
Use a web load balancer if needed.
Create terminal servers if needed.
Test the capacity of a network connection with the Relativity bandwidth tester.
2 Configuring Windows server
Use the following guidelines to configure your Windows Server for optimum performance with
Relativity. Some of these configuration options are one-time settings, while others require
intermittent updating as your hardware or database sizes change.
The recommendations are applicable to all Relativity roles.
2.1 Microsoft Windows server service packs
Ensure that you have the latest Microsoft Windows Server and .NET Service Pack installed on all
Relativity servers.
Install any smaller security patches, Windows updates, etc. at your own discretion. kCura only tests
major service packs, and not every Microsoft update that is released. Deploy any patches to your
test instance of Relativity first and ensure that a rollback plan is in place if any issues are discovered
during deployment.
Ensure the option to "Install updates automatically" on all Relativity servers has been disabled. Apply
any required updates during a planned maintenance window.
2.2 Windows power plans and CPU performance
In Windows Server 2012, 2012 R2, and 2008 R2, you can access the Power Options screen by typing
powercfg.cpl in a Run prompt. Three default power plans are available: Balanced, Power saver, and
Relativity | Environment Optimization Guide - 11
High performance. Balanced is set by default, which is what Microsoft recommends for general use.
Unfortunately, the default Balanced power plan may not be the best choice for production server
performance.
We recommend ensuring all Relativity SQL servers are configured to use the High performance
windows power plan. This may also require changes to BIOS settings. You will need to decide what is
best to accommodate all Relativity server roles.
Note: For more information, go to http://www.mssqltips.com/tip.asp?tip=2225.
2.3 Windows visual effects
Windows includes standard visual effects to make the user experience more enjoyable. These
effects are not required and consume CPU resources. kCura recommends disabling these effects on
all Relativity servers.
1. Access the Advanced tab in the System Properties dialog, and then select the Performance Options dialog by clicking Settings in the Performance panel.
2. In the Performance Options dialog, select the Visual Effects tab.
3. Select the Adjust for best performance option and click OK.
Relativity | Environment Optimization Guide - 12
2.4 Windows processor scheduling
Application performance is related to processor scheduling caching options that you set for
Windows Server. Processor scheduling determines the responsiveness of applications you are
running interactively (as opposed to background applications that may be running on the system as
services). kCura recommends that you select background services on all Relativity servers.
1. Access the Advanced tab in the System Properties dialog, and then display the Performance Options
dialog by selecting Settings in the Performance panel.
2. In the Performance Options dialog, select the Advanced tab.
3. In the Processor Scheduling panel, you have the following options:Programs: Use this option to give
the active application the best response time and the greatest share of available resources. Generally,
you will want to use this option only on development servers. You should also select this option when
you are using Windows Server 2008 R2 as your desktop operating system.
Background Services: Use this option to give background applications a better response time than the
active application. Generally, you will want to use this option for production servers.
4. Select the Background Services option and click OK.
2.5 Windows NTFS fragmentation
Install an automatic disk defragmentation tool on all Relativity Web, SQL, Search, and File servers.
There are a number of tools available to defragment your hard drives and optimize performance.
Some of the latest products are pro-active and prevent much of the fragmentation from ever
occurring. Research the available tools to decide which is best for you. Unlike the available Windows
task to defragment your physical disks, these tools work automatically in the background, using only
idle resources to ensure nothing is negatively impacted.
Relativity | Environment Optimization Guide - 13
Most current SAN and NAS devices include technologies to avoid or limit fragmentation on the block
level. Windows sees the data logically from the software level, outside of the storage realm. If
Windows detects a file in hundreds of pieces, SAN performance may be affected.
Please work with your storage vendor to see if they recommend installing a defragmenting tool.
If the Relativity roles are not virtualized, there will likely be a mirrored array housing the OS and
required Relativity components (unless you’re also booting from the storage device). If these disks
are heavily fragmented, roles including the web servers (IIS) may experience poor performance that
could impact Relativity review.
2.6 Configuring virtual memory
RAM is a limited resource, whereas virtual memory is, for most practical purposes, unlimited. There
can be many processes, each one having its own 2 GB of private virtual address space. When the
memory that is in use by all the existing processes exceeds the amount of available RAM, the
operating system moves pages (4 KB pieces) of one or more virtual address spaces to the hard disk,
freeing that RAM frame for other uses. In Windows systems, these "paged out" pages are stored in
one or more files that are named pagefile.sys in the root of a partition. There can be one such file in
each disk partition. The location and size of the page file is configured in Control Panel. To set these
values, click System, select Advanced system settings, and then click Settings under Performance.
By default, Windows Server puts the paging file on the boot partition where the operating system is
installed and creates a default size of the paging file that is 1.5 times the physical RAM, up to a
maximum of 4095 MB.
n
n
For all Relativity Web, Agent, File, and Search servers, manually set the size of the paging file to 4095
MB or higher. This is recommended as the OS array will typically only have enough room for what is
required and will not be able to support a page file size of 1.5 times the amount of physical RAM.
For systems with a large amount of RAM installed, set the page file to a size no greater than 50 GB.
Microsoft has no specific recommendations about performance gains for page files larger than 50 GB.
Manually setting the size of the paging file typically provides better performance than allowing the
server to size it automatically or having no paging file at all. Best-practice tuning is to set the initial
minimum and maximum size settings for the paging file to the same value. This ensures that no
processing resources are lost to the dynamic resizing of the paging file, which can be intensive. This
is especially true given that this resizing activity typically occurs when the memory resources on the
system are already constrained. Setting the same minimum and maximum page file size values also
ensure the paging area on a disk is one single, contiguous area, which improves disk seek time.
For all Relativity SQL servers set the default page file created by Windows on the C drive to 4 GB.
This is to allow for the creation of a troubleshooting dump file during a server crash. SQL server
shouldn’t use the page file for memory on correctly configured servers. There should be no need to
create a second page file on the SQL server like other Relativity server roles. SQL server memory
configurations are detailed in the SQL server setup section of this guide.
Relativity | Environment Optimization Guide - 14
Microsoft recommends isolating the paging file onto one or more dedicated physical drives that are
configured as either RAID-0 (striping) or RAID-1 (mirroring) arrays, or on single disks without RAID.
By using a dedicated disk or drive array where PAGEFILE.SYS is the only file on the entire volume,
the paging file will not become fragmented, which improves performance. As with most disk-arrays,
performance of the array improves as the number of physical disks in the array is increased. If a
paging file is distributed between multiple volumes on multiple physical drives in a disk array, the
paging file size should be the same size on each drive in the array. When configuring a disk array,
use physical drives that have the same capacity and speed. Note that redundancy is not normally
required for the paging file.
Do not configure the paging file on a RAID 5 array. Configuration of the paging file on a RAID 5
array is not recommended because paging file activity is write intensive and RAID 5 arrays are
better suited for read performance than write performance.
2.7 Antivirus directory exclusion list
All antivirus software installed on any of the Relativity servers should be configured to exclude
several areas:
n
SQL servers - All directory values are located in the EDDS database | Configuration table (excluding the
Relativity Program Files and the BCPPath). Relativity is installed in the following location: C:\Program
Files\kCura Corporation\Relativity. Please adjust the drive location if necessary.
Directory where the Database files are located.
Directory where the Log files are located.
o The location of the BCPPath on the SQL server.
o Directory where the Full Text Indexes are located
Agent servers
o
o
n
o
o
o
o
Default: C:\Program Files\kCura Corporation\Relativity
C:\Windows\Temp
C:\Users\Rel_SVC\AppData\Local\Temp
Account running the agent service = Rel_SVC
Note: Keep in mind your environment may differ slightly.
n
n
Web servers - Default: C:\Program Files\kCura Corporation\Relativity. Please keep in mind your environment may differ slightly.
Worker servers
C:\Program Files\kCura Corporation
C:\Windows\Temp
o C:\Windows\System32 (\Invariant.hook.dll)
o C:\Windows\SysWOW64 (\Invariant.hook.dll)
o C:\Users\Rel_SVC\AppData\Local\Temp
Analytics indexes - Locate a folder named Content Analyst or CAAT; this is the installation directory.
The index directory, if different, should also be excluded from Anti-Virus.
dtSearch indexes - The default location is stored in the EDDS.eddsdbo.Configuration table.
File repositories - Any file directory that Relativity uses as a file share.
o
o
n
n
n
Relativity | Environment Optimization Guide - 15
2.8 Management server
Whenever possible, avoid logging into a production server using remote desktop. Instead, use a
management or utility server. This server or virtual machine should have SQL Server Management
Studio (SSMS) and the Relativity Desktop Client installed. Use this server to connect to the SQL
instances to adjust maintenance plans and query tables, etc. If you have an external hard drive
containing data that needs to be imported into Relativity, connect it to this server and launch the
Desktop Client on it to perform the data imports or export.
When administrators log directly into a production server, navigate and open applications, memory
is consumed and processes are wasting CPU cycles. There is also a Windows Server 2008 and R2
issue related to file caches having no cap. System admins should avoid dragging and dropping files
via RDP from the console as this action is cached and may result in no free memory being available
to the operating system. There are additional reasons to avoid RDPing directly into production
servers on a regular basis.
3 Configuring SQL Server
Use the following guidelines to configure the SQL Server(s) for optimum performance with
Relativity. Some of these configuration options are one-time settings, while others require
intermittent updating as your hardware or database sizes change.
Note: These guidelines are applicable to all SQL Servers in the environment, including the Invariant
SQL Server.
3.1 Optimize for ad hoc workloads option
On the SQL Server, the optimize for ad hoc workloads option is used to improve the efficiency of the
plan cache for workloads that contain many single use ad hoc batches. When this option is set to
one, the Database Engine stores a small compiled plan stub in the plan cache when a batch is
compiled for the first time. (This step is performed instead of the full compiled plan.) It helps to
relieve memory pressure by not allowing the plan cache to be filled with compiled plans that are
not reused.
The compiled plan stub allows the Database Engine to recognize that this ad hoc batch has been
previously compiled, but has only stored a compiled plan stub. When this batch is invoked (compiled
or executed) again, the Database Engine compiles the batch, removes the compiled plan stub from
the plan cache, and adds the full compiled plan to the plan cache.
Note: This information was obtained from the following Microsoft article: http://msdn.microsoft.com/enus/library/cc645587.aspx.
Relativity | Environment Optimization Guide - 16
We recommend enabling the optimize for ad hoc workloads option on each SQL instance. Execute
the following statement to enable this option:
SP_CONFIGURE 'show advanced options',1
RECONFIGURE
GO
SP_CONFIGURE 'optimize for ad hoc workloads',1
RECONFIGURE
GO
3.2 Max degree of parallelism option
SQL Server detects the best degree of parallelism, which is the number of processor cores employed
to run a single statement for each parallel plan execution. You can use the max degree of
parallelism option to limit the number of processor cores to use in parallel plan execution. To
enable the server to determine the maximum degree of parallelism, set this option to 0 (this is the
default value). Setting maximum degree of parallelism to 0 allows SQL Server to use all the
available processors (up to 64 processors).
Note: This information was obtained from the following Microsoft article: http://msdn.microsoft.com/enus/library/ms181007.aspx.
We recommend the following MaxDOP settings:
n
n
If the total number of logical processor cores is greater than or equal to 16, set the MaxDOP to a value
of 8.
If the total number of logical processor cores is less than 16, set the MaxDOP to a value equal to half
the number of available cores.
Another way to determine the optimal setting is to understand the amount of simultaneous long
running queries that will be executed at any given time. For instance, in an 16-core system that has
100 simultaneous users logged in executing queries, it might make sense to set MaxDop to a value
of 4 instead of 8 to more efficiently support many simultaneous long running queries. Analysis of the
SQL Server Dynamic Management Views can assist in making this determination.
This setting takes effect immediately, without restarting the MSSQLSERVER service. Execute the
following statement to set this value.
sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
sp_configure 'max degree of parallelism', 8;
GO
RECONFIGURE WITH OVERRIDE;
GO
Relativity | Environment Optimization Guide - 17
The Optimize for Ad hoc Workloads and Max Degree of Parallelism options can also be viewed and
adjusted in the properties of the SQL Server instance within SQL Server Management Studio.
To view and adjust these options:
1.
2.
3.
4.
Launch SQL MGMT Studio.
Right-click on the Relativity SQL instance.
Select Properties.
Select Advanced.
3.3 Cost threshold for parallelism
Use the cost of threshold for parallelism option to specify the threshold at which Microsoft
SQL Server creates and runs parallel plans for queries. SQL Server creates and runs a parallel plan
for a query only when the estimated cost to run a serial plan for the same query is higher than the
value set in cost threshold for parallelism. The cost refers to an estimated elapsed time required to
run the serial plan on a specific hardware configuration. The default value is 5.
Note: This information was obtained from the following Microsoft article: http://msdn.microsoft.com/enus/library/ms188603%28v=sql.105%29.aspx.
We recommend increasing this option to a value of 50 on each SQL instance. Execute the following
statement to set this option:
Relativity | Environment Optimization Guide - 18
sp_configure 'show advanced options', 1;
GO
reconfigure;
GO
sp_configure 'cost threshold for parallelism', 50;
GO
reconfigure;
GO
3.4 Optimize the tempdb database
The tempdb is a database used for temporary user and internal objects created by SQL Server. For
optimal system performance and stability, ensure the tempdb database has been configured
correctly.
Use the following guidelines to configure the tempdb database:
n
n
n
n
n
Create one temporary database file per each processor core. Multiple files will provide better I/O performance and less contention on the global allocation structures. For higher end systems with more
than 16 cores, Microsoft suggests beginning with 8 database files, and adding more if there is still contention. There are scripts available to measure contention; most Relativity environments work well
with 8 data files.
Refer to the following article on Tempdb contention: http://sqlblog.com/blogs/adam_machanic/archive/2011/04/21/analyzing-tempdb-contention-a-month-of-activity-monitoring-part-21-of30.aspx.
Set the initial size of each file to 10 GB or higher (to limit any autogrowth) and either set autogrowth to
10 percent or disable it. To set file sizes, right-click on the tempdb system database, select Files, and
make additions. Set all files to the same initial size. It is important that all data files are set to the same
initial size and autogrowth settings. As the environment grows, in an optimized setup, the Tempdb system database should be larger than your biggest, active Relativity workspace eddsdbo.Document
table.
Store these files on a fast RAID array and not the OS partition. RAID 10 is ideal. Some partners have
recently started to store these data files on PCIe-flash or SSDs. Please read the vendor specific instructions for these newer technologies, as they might require free memory for drivers or free disk space for
performance.
Store the log file (.ldf) for this database on the same array as the other database log files. Set the initial
size of the log file to 25% of the total of all tempdb data files. For example, if there are 8 tempdb data
files set to an initial size of 10 GB each, set the initial size of the tempdb log file to 20 GB. Do not create
additional log files – only one is necessary.
Additions can be made while the system is live but you will need to restart the SQL instance for
changes to take effect. This change should be made on all Relativity SQL servers.
Note: For more information about the tempdb, see http://msdn.microsoft.com/enus/library/ms190768.aspx.
Relativity | Environment Optimization Guide - 19
Do not install the default tempdb data and log files on the C (OS) partition. Moving the default
tempdev and templog files to another partition is important, even though it may not be easy to
change their location using SQL Server Management Studio (SSMS). In order to move these files to a
different location, you will have to execute some SQL statements in SSMS.
For more information, see http://msdn.microsoft.com/en-us/library/ms345408.aspx.
3.5 SQL max server memory
Use max server memory to prevent the SQL Server buffer pool from using more than the specified
amount of memory. The remaining memory is available to the operating system and other installed
applications.
The suggested configuration involves leaving at least 10% of the total amount of RAM available to
the OS and other applications. For example, set the SQL Server Max Memory to a value of 58GB if
there is 64GB RAM available. This assumes that the server is dedicated to SQL and there are no
other applications installed that will require a significant amount of memory.
To set the max server memory option, adjust the max server memory value below and execute in
SSMS.
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'max server memory', 1024;
GO
RECONFIGURE;
GO
The Maximum server memory option can also be viewed and adjusted in the properties of the SQL
Server instance within SQL Server Management Studio.
To view and adjust the Maximum server memory option:
1.
2.
3.
4.
Launch SQL MGMT Studio.
Right-click on the Relativity SQL instance.
Select Properties.
Select Memory.
Relativity | Environment Optimization Guide - 20
In the event of a failover in an active/active SQL cluster, reduce the Max Server Memory value for
each instance to half so they are not competing for resources (which can severely slow down or
crash the server). For example, with 32 GB installed on each node, set the max server memory on
each instance to 14 GB (so together they total 28 GB). This will leave 4 GB of memory available for
the OS and other installed applications on the active node.
Note: For more information on max server memory, see http://msdn.microsoft.com/enus/library/ms178067.aspx.
3.6 Instant file initialization
Data and log files are initialized to overwrite any existing data left on the disk from previously
deleted files. Data and log files are first initialized by populating the files with zeros when you
perform one of the following operations:
n
n
n
n
Create a database
Add log or data file to an existing database
Increase the size of an existing file (including autogrow operations)
Restore a database or filegroup
File initialization causes these operations to take longer. However, when data is written to the files
for the first time, the operating system will not have to populate the files with zeros.
In the SQL Server, data files can be initialized instantaneously. This process allows for fast execution
of file operations listed above. Instant file initialization reclaims used disk space without populating
that space with zeros. Instead, disk content is overwritten as new data is written to the files. Log files
cannot be initialized instantaneously.
Note: This information was obtained from the following Microsoft article:
http://technet.microsoft.com/en-us/library/ms175935.aspx.
To enable instant file initialization:
Relativity | Environment Optimization Guide - 21
1.
2.
3.
4.
5.
6.
7.
On the Start menu, click Run. In the Open box, enter secpol.msc.
Expand Local Policies.
Select the User Rights Assignment folder. The policies will be displayed in the details pane.
In the pane, double-click Perform Volume Maintenance Tasks.
In the Local Security Policy Setting dialog, click Add.
In the Select Users or Groups dialog, add your SQL Server service account (or a domain group).
Restart the SQL service or server.
3.6.1 Comparison of zero and instant initialization
The following sample performance tests compare zero initialization and instant initialization
(source: http://www.sqlskills.com/BLOGS/KIMBERLY/post/Instant-Initialization-What-Why-andHow.aspx#ixzz0sMB4W7PI).
Performance
test
Hardware
Zero initialization
Instant initialization
Dell Precision 670 Dual Proc (x64) with Dual
Core, 4 GB Memory, RAID 1+0 array w/4-142
GB, 15000rpm disks.
14:02 minutes
Dell Precision 670 Dual Proc (x64) with Dual
Core, 4 GB Memory, RAID 1+0 array w/4-142
GB, 15000rpm disks.
1.3 seconds
CREATE
DATABASE with
20 GB Data file
ALTER DATABASE 7:01 minutes
BY 10 GB
RESTORE 30 GB 21:07 minutes
DATABASE
(EMPTY Backup)
RESTORE 30 GB 38:28 minutes
DATABASE (11GB
Backup)
4 seconds
5 seconds
19:42 minutes
3.7 File allocation unit size
File Allocation unit size is also called the Cluster size. Windows NTFS formatted drives support sizes
of 512, 1024, 2048, 4096, 8192, 16K, 32K and 64K. The allocation unit is the smallest amount of
space that a file can consume. Windows will use a default allocation unit size of 4096 bytes if this is
not set during the format. Unfortunately, this is usually not ideal for SQL server performance. In
most scenarios, the Data, Log, and Tempdb drives should be formatted with a 64K Allocation Unit
Size. Configure this early in the SQL server setup process as the allocation unit size is set during a
drive format operation.
Run the following command for each drive to see the file allocation unit size reported in bytes per
cluster. The Bytes Per Cluster value, which contains the file allocation unit size, is highlighted here.
For example, to run the command for E: drive:
Relativity | Environment Optimization Guide - 22
fsutil fsinfo ntfsinfo e:
To run the command for F: drive:
fsutil fsinfo ntfsinfo f:
An appropriate value for most installations is 65,536 bytes (that is, 64 KB) for partitions on which
SQL Server data or log files reside. If necessary, consult your storage vendor for their
recommendation or assistance with this configuration. This significantly impacts SQL Server
performance.
Always use the storage vendor's recommended setting. If your storage vendor doesn't have a
recommended setting, use 64 KB.
Note: This information was obtained from the following article: http://msdn.microsoft.com/enus/library/dd758814.aspx.
3.8 Microsoft SQL server service packs
Ensure that you have the latest Microsoft SQL Server Service Pack installed on all Relativity SQL
Servers. Microsoft uses service packs to distribute hotfixes and software updates for the SQL Server.
In addition, these service packs may include system administration tools, drivers, and additional
components. These updates and components are conveniently bundled for easy downloading.
Since service packs are cumulative, each new one contains any recent fixes as well as any previous
updates already released. You do not have to install a previous service pack before you install the
latest one.
3.8.1 Determining the version of SQL server
To determine which version of Microsoft SQL Server is running in your environment:
1. Connect to the SQL Server with SQL Server Management Studio.
2. Run either of the following Transact-SQL statements:
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY
('edition')
SELECT @@VERSION
You'll see the following information displayed:
RTM
SP1
SP2
SP3
SQL Server 2012
11.00.2100.60 11.00.3000
SQL Server 2008 R2 10.50.1600.1 10.50.2500 10.50.4000
Relativity | Environment Optimization Guide - 23
SQL Server 2008
RTM
SP1
SP2
SP3
10.00.1600.22 10.00.2531 10.00.4000 10.00.5500
3.9 Autogrowth settings
SQL Server will automatically increase the size of database (.mdf) and transaction log (.ldf) files
throughout the life of a workspace. It is important to set these auto growth variables appropriately.
If a transaction log is set to auto grow by the default 10% on a very large file, it will take time for
the grow operation to complete. Other transactions that require a write to the transaction log will
have to wait until the grow operation finishes. Conversely, if these files are set to expand by too
small increments, higher disk fragmentation will occur in addition to the server being continuously
taxed by having to expand these files.
Relativity data files are by default set to autogrow by 10 percent and their logs by 512 MB as
specified in the Instant File Initialization setting. Do not set the transaction logs (.ldf) to auto grow by
more than 1024 MB, because log files cannot be initialized instantaneously. Note that databases
enabled for Transparent Data Encryption (TDE) cannot take advantage of Instant File Initialization.
Therefore, you should set databases enabled for TDE to autogrow by 4096MB instead of the default
10%. This is because if a database is large and needs to autogrow by 10% without being able to take
advantage of Instant File Initialization, it can result in application timeouts during each autogrow.
If possible, try to anticipate how large a database will become and set the "Initial Size" of the MDF
file within the properties of that database to avoid or limit automatic growth.
Note: When a new workspace is created in Relativity, the template workspace database is backed up and
restored as the new workspace database. The autogrowth and initial size settings from the backed up
database will carry over to the new workspace, which you may need to adjust if you are setting the initial
size.
3.10 SQL Server 2012 best practices analyzer
The Microsoft SQL Server 2012 BPA is a diagnostic tool that performs the following functions:
n
n
n
n
n
Gathers information about a Server and a Microsoft SQL Server instance installed on that Server.
Determines if the configurations are set according to the recommended best practices.
Reports on all configurations, indicating settings that differ from recommendations.
Indicates potential problems in the installed instance of SQL Server.
Recommends solutions to potential problems.
To download the Microsoft Diagnostic tool, go to http://www.microsoft.com/enus/download/details.aspx?id=29302.
We recommend installing this on each Relativity SQL Server. Perform a diagnostic check and review
the report prior to introducing a SQL server to the environment. Perform another analysis
periodically.
Relativity | Environment Optimization Guide - 24
3.11 RAID levels and SQL server
There are many iSCSI and Fibre channel SAN, DAS and NAS solutions available. These devices often
utilize RAID levels not discussed in this guide and include other unique technologies to provide the
fastest I/O possible. Work with your storage unit provider to ensure the device is configured for
optimal performance. Work with your storage unit provider or follow Microsoft best practices to
determine where different SQL data should live.
The tempdb data files should reside on the fastest disks available, separate from that of all other
user databases. The tempdb database must be configured correctly for SQL server performance.
Many clients have recently started to store these data files on PCIe-flash or SSDs as the data is
temporary and doesn’t require shared storage in SQL Server Failover Cluster setups. Regardless of
the type of SAN or DAS and any caching mechanisms or auto-tiering, storing these on local PCIeflash or SSD RAID will result in reduced latency and take some of the load off of the primary storage
device(s).
Database log files should usually reside on their own disks. Isolating the database log files on their
own spindles helps to ensure that nothing will interfere with the sequential writes for each database
log file.
Solid state storage is an exception to the conventional wisdom. Hard drives perform very differently
depending on whether you are doing random or sequential operations. Random operations will be
slower because of the moving parts included in typical hard drives. This is why you may want to
avoid placing the log and data files on the same disks. Solid state disks, however, typically perform
the same whether random or sequential operations are being performed.
As mentioned above, many storage solutions include unique technologies to provide the fastest I/O
possible that may go against the conventional wisdom. Many newer SAN devices are intelligent
enough to automatically shift data across different types of available storage depending on activity
levels of the stored data. These devices can help you maximize performance with minimal manual
intervention, reducing IT related costs and getting as much possible out of the available storage.
Regardless, there are many different storage options available and kCura encourages you to
research and decide which solution is best for your organization.
Below are some high level suggestions for our smaller 25-50 user licensed instances that may not
include a SAN and are looking for some guidance in configuring local SQL storage.
RAID (Redundant Array of Independent Disks) levels 0, 1, 5 and 1+0 are typically implemented with
SQL Server. Each RAID level below outlines the SQL data pieces they typically support.
3.11.1 Level 0
Use for: PageFile, TempDB
Relativity | Environment Optimization Guide - 25
This level is also known as disk striping because it uses a disk file system called a stripe set. Data is
divided into blocks and spread in a fixed order among all disks in an array. RAID 0 improves read
and write performance by spreading operations across multiple disks. Operations can then be
performed independently and at the same time.
kCura would never suggest RAID 0 for anything as it can introduce system or application specific
outages.
3.11.2 Level 1
Use for: OS, Logs (.ldf)
This level is also known as disk mirroring because it uses a disk file system called a mirror set. Disk
mirroring provides a redundant, identical copy of a selected disk. All data written to the primary
disk is written to the mirror disk. RAID 1 provides fault tolerance and generally improves read
performance but may degrade write performance.
3.11.3 Level 5
Use for: Databases (.mdf), Full Text Indexes (.ndf)
Also known as striping with parity, this level is the most popular strategy for new designs. RAID 5 is
similar to RAID 4, because this level stripes the data in large blocks across the disks in an array.
However, RAID 5 differs because it writes the parity across all the disks. Data redundancy is
provided by the parity information.
The data and parity information are arranged on the disk array so that the two types of information
are always on different disks. Striping with parity offers better performance than disk mirroring
(RAID 1). However, when a stripe member is missing, read performance is decreased, for example,
when a disk fails.
3.11.4 Level 10 (1+0)
Use for: Databases (.mdf), Full Text Indexes (.ndf), TempDB, Logs (.ldf)
This level is also known as mirroring with striping. RAID 10 uses a striped array of disks that are then
mirrored to another identical set of striped disks. For example, a striped array can be created by
using five disks. The striped array of disks is then mirrored using another set of five striped disks.
RAID 10 provides the performance benefits of disk striping with the disk redundancy of mirroring.
RAID 10 provides the highest read-and-write performance of any one of the other RAID levels but at
the expense of using two times as many disks.
RAID levels higher than 10 (1 + 0) may offer additional fault tolerance or performance
enhancements. These levels generally are proprietary systems. For more information about these
types of RAID systems, contact the hardware vendor.
The following table breaks down the various RAID levels (source: http://technet.microsoft.com/enus/library/cc966414.aspx#_RAID).
Relativity | Environment Optimization Guide - 26
RAID Levels
Reliability
RAID 0
RAID 1
Lowest - Lack of Very good - Even
fault tolerance res- better with
ults in data loss. duplexing.
Storage Efficiency
100 percent
50 percent
Random Read
Excellent
Random Write
Excellent
Fair - Worst of
the RAID levels
but better than a
single drive.
Fair - Worse than
a single drive but
better than some
RAID levels.
Sequential Read
Sequential Write
Cost
Recommended use
RAID 5
Good Can tolerate
single
machine
fault.
>50 percent,
<100 percent
(#drives1/#drives)
Excellent
RAID 10
Excellent
50 percent
Excellent
Fair - Gen- Very good
erally better with
larger
stripe
sizes.
Excellent
Fair - Comparable Very
Very good
to a single drive. good.
Generally,
better
with smaller stripe
sizes.
Excellent
Good - Better
Fair
Very good
than other RAID
levels.
Lowest
Moderate - Rel- Moderate High
atively high cost
due to redundant
drives; however,
no expensive controller required.
Good for non-crit- Good for data
Very
Data requirical data or stag- that requires high good for ing high pernantly updated
fault tolerance at Read only formance for
data that is
relatively low
data.
both read
backed up reghardware cost
and write
Relativity | Environment Optimization Guide - 27
RAID Levels
RAID 0
ularly or any data
requiring fast
write performance at very
low cost. Great
for testing.
RAID 1
(redundancy
using parity
requires more
expensive hardware). Best for
log files.
RAID 5
RAID 10
and excellent reliability while
trading off
storage efficiency and
cost.
The following table provides a summary of an example twelve disk RAID configuration.
Disk
0
1
2
3
4
Qty
2
2
2
4
2
RAID
1
1
1
5
1
Example RAID-12 disk setup
Windows
System Databases (tempdb)
Transaction Logs (ldf)
Relativity Databases (mdf), Full Text Catalogs (ndf)
Backups
4 Configuring the Analytics server
Use the following guidelines to configure your analytics server(s) for optimum performance with
Relativity.
4.1 Memory requirements
4.1.1 Analytics indexing
Server memory is the most important component in building an analytics index. The more memory
your server has, the larger the datasets that can be indexed without significant memory paging.
Insufficient memory will slow down index build performance. The analytics index creation process
also depends on CPU and I/O resources at various stages of the build. Ensuring that your server has
multiple processors and fast I/O also increases efficiency during the build process.
The following factors affect RAM consumption during indexing:
n
n
n
n
Number of documents in the training set
Number of documents in the searchable set
Number of unique words across all the documents in the data set being indexed
Total mean document size (as measured in unique words)
Use the following equation to estimate how much free RAM is needed to complete an index build:
(Number of Training Documents) * 6000 = Amount of RAM needed in bytes
An easy way to remember this equation is that every 1 Million training documents in the index
require 6 GB of free RAM. The equation is based upon the average document set in Relativity. If
Relativity | Environment Optimization Guide - 28
your dataset has more unique terms than an average dataset, more RAM will be required to build.
We recommend accounting for slightly more RAM than the equation estimates.
4.1.2 Structured analytics
To run structured analytics, the analytics server can require substantial server resources. The
structured analytics features are run by the Java process, as well as PostgreSQL. One of the most
important components of ensuring a successful structured analytics operation is ensuring that Java
has access to a sufficient amount of RAM. The following equation may be used to estimate how
much RAM will be required for a given structured analytics set:
(Number of Documents) * 6000 = Amount of JVM needed in bytes
An easy way to remember this equation is that every 1 Million documents in the set require about 6
GB of RAM for the Java process. If your dataset is comprised of very long documents, it may require
more JVM. If it is comprised of very small documents, then you may not need as much JVM. If Java
does not have sufficient memory to complete a structured analytics operation, it is not often that
you will receive an OOM error. More often Java will heap dump and garbage collect endlessly
without ever successfully completing the operation. This equation is a good starting point so that
these types of problems do not occur. See the section Java heap size (JVM) on the next page for
information on how to configure JVM.
4.1.3 Enabled analytics indexes
An analytics index is stored on disk and is loaded into memory when the index has “Queries
Enabled.” An index with Queries Enabled may be used for all analytics functionality such as
clustering, categorization, etc. as well as querying. When you select “Enable Queries” on an
analytics index, Relativity loads the vectors associated with all searchable documents and words in
the conceptual space into RAM in an lsiapp.exe process. For indexes with millions of documents and
words, this RAM requirement may be thousands of MB. The number of words per document can
range widely, from about 0.80 to 10, depending on the type of data in the index. These ranges
indicate the amount RAM needed for an index to be enabled:
#SearchableDocuments * 5,000 = High end of #bytes required
# SearchableDocuments * 400 = Low end of #bytes required
Select “Disable Queries” on any analytics indexes that aren’t in use to free up RAM on the analytics
server. The Configuration value MaxAnalyticsIndexIdleDays helps with this issue. This value is the
number of days that an analytics index can remain inactive before the Case Manager agent disables
queries on it. Inactivity on the analytics index is defined as not having any categorization, clustering,
or any type of searches using the index. This feature ensures that indexes that are not being used
are not using up RAM on the analytics server. If the index needs to be used again, simply navigate to
the index in Relativity and click "Enable Queries." It will be available for searching again within
seconds.
Relativity | Environment Optimization Guide - 29
4.2 Java heap size (JVM)
Depending on the amount of RAM on your analytics server, as well as its role, you will need to
modify the Java Heap Size setting. This setting controls how much RAM the Java process may
consume. Java is used for index populations, as well as structured analytics operations, clustering,
and categorization.
Here are some general guidelines:
n
n
n
If the analytics server is used for both indexing and structured analytics, set this value to about 50% of
the server's total RAM. You need to leave RAM available for the LSIApp.exe process, which is used for
building conceptual indexes.
If the analytics server is used solely for structured analytics, set this value to about 75% of the server's
total RAM. Be sure to leave about a quarter of the RAM available for the underlying database processes.
If the analytics server is used solely for indexing, set this value to about one-third of the server's total
RAM. You need to leave RAM available for the LSIApp.exe process, which is used for building conceptual indexes.
Due to a limitation in the Java application, do not configure JVM with a value between 32 GB and 47
GB (inclusive). When JVM is set between 32 GB and 47 GB, the application only has access to 20-22
GB heap space. For example, if the server has 64 GB RAM, set JVM to either 31 GB or 48 GB. This
allows the Java application to access all RAM allocated.
To modify the Java Heap Size setting, perform the following steps:
1.
2.
3.
4.
Navigate to <CAAT install drive>\CAAT\bin.
Edit the env.cmd file.
Locate the line similar to the following: set HEAP_OPTS=-Xms4096m -Xmx16383m.
The configuration starting with –Xmx refers to the maximum amount of RAM available to Java, in megabytes. Modify this value as needed. Both megabyte and gigabyte values are supported for these settings. The change won't take effect until you stop and start the Content Analyst CAAT Windows Service.
Note: Never set the Java maximum (-Xmx) to be less than the Java minimum (-Xms). Don't modify the Java
minimum setting unless instructed by kCura.
4.3 Page file size
We recommend the following settings regarding the page file size for the Analytics server:
n
n
n
Set the size of the paging file to 4095 MB or higher. This is because the OS array generally only has
enough room for what’s required and is not able to support a page file size of 1.5 times the amount of
physical RAM.
Set the initial minimum and maximum size of settings for the page to the same value to ensure no processing resources are lost to the dynamic resizing of the paging file.
Ensure that the paging area on a disk is one single, contiguous area, which improves disk seek time.
Relativity | Environment Optimization Guide - 30
n
For servers with a large amount of RAM installed, set the page file to a size no greater than 50 GB.
Microsoft has no specific recommendations about performance gains for page files larger than 50 GB.
4.4 Index directory requirements
The index directory stores both the analytics indexes and the structured analytics sets. Using default
settings, the average amount of disk space for the analytics index or structured analytics set is equal
to about 20% of the size of the MDF file of the workspace database. This metric indicates an
average amount of disk space usage, but actual indexes may vary considerably in size. The amount
of space required depends on the size of the extracted text being indexed, as well as the number of
documents, unique words, and settings used to build the index. An analytics server may not have
multiple index locations; it may only reference one disk location for the server’s analytics indexes
and structured analytics sets.
Due to the size requirements, it is recommended that the index directory not be kept on the C:
drive. Upon installation or upgrade, the Relativity Analytics Server installer will prompt for the index
directory location. If you would like to move the index directory location after upgrade, see Moving
Analytics indexes.
CAAT® uses the database software called PostgreSQL which requires guaranteed writes to the index
directory. The analytics indexes and structured analytics sets should be treated just as any other
database would. It's recommended to store the indexes and structured analytics sets on the same
type of disk as the Relativity SQL databases. The connection to the directory should be one that can
guarantee writes, such as iSCSI, rather than SMB.
4.5 Scaling
It is often beneficial to add multiple analytics servers to the Relativity environment. This allows jobs
to run concurrently without adversely affecting each other. It also allows servers to be dedicated to
a feature set (structured or indexing) which makes RAM management easier. The following table
shows some example environment configurations as well as the typical upper limitation that will be
encountered. The upper limitation assumes no other concurrent activity on the server. The upper
limit is intended to server as an estimate and is not a guarantee. Datasets vary widely, and some
may require more RAM than usual. See Memory requirements on page 28 for more details.
4.5.1 Tier 1 Example
For an entry level environment, usually one analytic server is enough. Here is an example of the
server you may have:
Server Name Role
ANA-01
RAM JVM Upper limit - Structured Upper limit - Indexing
Both Structured and Indexing 32 GB 16 GB 3 MM documents
Relativity | Environment Optimization Guide - 31
3.5 MM documents
4.5.2 Tier 2 Example
For a mid-level environment, you may need to scale up the server as well as adding an additional
server. Splitting the server roles will allow the servers to work on more data, due to the allocation of
Java Heap. Here is an example environment configuration:
Server Name Role
RAM JVM Upper limit - Structured Upper limit - Indexing
ANA-01
Structured 64 GB 48 GB 8 MM documents
N/A
ANA-02
Indexing
7 MM documents
64 GB 22 GB N/A
4.5.3 Tier 3 Example
For a large scale environment, adding even more analytics servers will allow more jobs to run
concurrently. However, adding a large amount of RAM to one server will allow a very large job to
complete successfully. The balance will need to be determined based upon the client needs. Here is
an example environment configuration if you were to add additional RAM to each server:
Server Name Role
RAM
JVM Upper limit - Structured Upper limit - Indexing
ANA-01
Structured 128 GB 96 GB 16 MM documents
N/A
ANA-02
Indexing
14 MM documents
128 GB 48 GB N/A
5 Moving Analytics indexes and structured analytics
sets
This page outlines the options available for managing the location of Analytics indexes and
structured analytics sets. The first section covers the process of moving the indexes and sets to a
new location. The second section covers the process of moving the Relativity Analytics server.
5.1 Moving the location of Analytics indexes and structured analytics sets
The steps below assist with Analytics index and structured analytics set moves, where the Analytics
installation remains on its original server. Please note that there can only be one index and
structured analytics set location per Relativity Analytics server. Indexes and structured analytics sets
must use the same location.
This requires downtime of all Analytics functionality in Relativity. This doesn't impact any
functionality in Relativity other than Analytics functions such as clustering, categorization, index
creation, etc. For this reason, it is recommended to perform the move during off-hours.
Relativity | Environment Optimization Guide - 32
You can find the files required to modify the Relativity Analytics server installation on the Customer
Portal. Be sure to use the correct Relativity Analytics server Installer for the Relativity environment.
5.1.1 Moving the indexes and sets
1. Stop the Content Analyst CAAT service on the Relativity Analytics server.
2. Copy the indexes and sets from the original location to the new location. You must copy all subfolders,
even if they are empty. The CAAT® software needs this folder structure in order to access the index or
set. Be sure to copy all indexes and structured analytics sets to the same folder location:
a. Move the contents of the C:\CAAT\data-default folder to the new location. This folder will contain a .ufx folder and a @README text file.
b. Move the contents of the C:\CAAT\indexes folder to the new location.
c. If applicable, move the contents of the C:\CAAT\staging folder to the new location.
The new location should contain all indexes and structured analytics sets with no separation using
subfolders.
3. Run the Relativity Analytics Server Setup wizard. For more information, see the Relativity Upgrade
Guide.
4. Enter the new directory name into the Analytics Index Share Folder field and let the installer finish.
5.1.2 Verify the new share
To verify that the new share is working properly, perform the following steps:
1.
2.
3.
4.
5.
Log in to Relativity and navigate to the Servers tab.
Activate the Analytics server you just added.
Verify that you're able to query against the current indexes.
Create a small Analytics index in one of the demo workspaces, such as Salt vs. Pepper.
Once complete, confirm the new index resides in the new index location.
Relativity | Environment Optimization Guide - 33
5.2 Migrating the Analytics server
If you need to migrate the Analytics server to a new server, use these instructions. For this
procedure, you need to move the Analytics installation as well as the indexes and structured
analytics sets.
This requires downtime of all Analytics functionality on the original server. This doesn't impact any
functionality in Relativity other than Analytics functions such as clustering, categorization, index
creation, etc. For this reason, it is recommended to perform the move during off-hours.
You can find all the files required to install the Relativity Analytics server on the Customer Portal. Be
sure to use the correct Relativity Analytics server installer for the Relativity environment.
5.2.1 Copying over the installation and indexes
You must copy all files from the old Analytics server to the new Analytics server through Robocopy.
To do this:
1. Stop the service on the original Analytics server.
2. Open the command prompt and run the following commands:
cd C:\CAAT\
dir device-links pgsql\data\pg_tblspc > links.txt
3. Open the C:\CAAT\links.txt file to ensure there were no problems with getting the needed output.
Since this file is in the CAAT installation directory, it's backed up with the CAAT data.
4. Create a new folder for the CAAT backup, using a command similar to the following:
n
n
n mkdir C:\caat-backup
5. Use Robocopy to back up the CAAT installation. The following copies all contents from the first location
to the second:
n
robocopy /xj /mir C:\CAAT C:\caat-backup
6. Copy the backed-up installation directory from the old server to the new server.
7. Copy the indexes and staging folders from the old server to the new server.
n
If your indexes and sets were stored in the installation directory, these were copied along with
the installation directory.
n
If your indexes and sets were stored in another path, you may copy this directory to the desired
location on the new server.
5.2.2 Installing Analytics on the new server
To install Analytics on the new server:
1. Once the backed up installation directory is on the new server, rename the directory to CAAT.
2. Open the C:\CAAT\links.txt file and locate the following:
Directory of c:\CAAT\device-links
05/02/2014 04:23 PM <DIR> .
05/02/2014 04:23 PM <DIR> ..
05/02/2014 04:23 PM <SYMLINKD> caat [C:\CAAT\data-default]
Relativity | Environment Optimization Guide - 34
0 File(s) 0 bytes
Directory of c:\CAAT\pgsql\data\pg_tblspc
05/02/2014 04:23 PM <DIR> .
05/02/2014 04:23 PM <DIR> ..
05/02/2014 04:23 PM <JUNCTION> 16549 [\??\C:\CAAT\device-links\caat\.ufx\db]
3. Recreate each symbolic link listed in this file. The following commands allow you to do this. Remember
to modify these as needed to match the information in your text file:
cd C:\CAAT\device-links
mklink /d caat C:\CAAT\data-default
n cd C:\CAAT\pgsql\data\pg_tblspc
n mklink /j 16549 C:\CAAT\device-links\caat\.ufx\db
4. Navigate to the C:\CAAT\bin directory on the new server.
5. Run the registerWinService.cmd file.
6. Run the Relativity Analytics Server Setup wizard . Be sure that you are logged in as the Relativity Service
Account on the server. . For more information, see the Relativity Upgrade Guide.
n
n
5.2.3 Adding the Analytics server to Relativity
Relativity Analytics is now configured on the new server. You now need to add this server to
Relativity. For the steps to add teh Analytics server to Relativity, see Adding Analytics or processing
server in the Admin Guide.
After adding the new server to Relativity, run the Analytics Move script using the following steps:
1.
2.
3.
4.
Log in to Relativity.
Navigate to the Relativity Script Library tab.
Click New Relativity Script.
Select and copy the contents of the Analytics Move v8.2 script file. Paste the script text into the Script
Body field, overwriting the default script body text.
5. Click Save.
6. Click Run Script.
7. Select the inputs for the old and new Analytics servers.
5.2.4 Verifying the migration
To verify that the new installation is working properly, follow these steps:
1.
2.
3.
4.
Log in to Relativity to verify you are able to query against the current indexes.
Create a small Analytics index in one of the demo workspaces, such as Salt vs. Pepper.
Once complete, confirm the new index resides in the new index location.
Delete the old Analytics server from the Servers tab.
5.2.5 Uninstalling the old Analytics installation
Now that Analytics is installed on the new server, you need to uninstall the Analytics installation
from the old Analytics server. For steps on how to do this, see the Relativity Upgrade Guide.
Finally, you need to delete the Analytics installation files and indexes from the old server.
Relativity | Environment Optimization Guide - 35
6 Setting up your workspace
Use the following best practices for workspace administrators to optimize your Relativity
environment.
6.1 Fixed-length vs. long text field types
Use the appropriate field type and length for text fields within Relativity.
Fixed-length text - A text field with a limited character length.
n
n
Maximum technical limitation of 4,999 characters
Examples: Author, Email From, Email Subject
Long Text - A text field larger than 4,999 characters.
n
n
n
The technical limitation on a long text field is 2 GB.
Relativity is typically configured to stream files smaller than 50 MB. The maximum file size can be set in
the configuration table.
Only the first 20,000 characters are displayed in Layouts and Views.
You can create indexes on particular columns to improve performance for queries against large
databases. See the Admin Guide for more information.
An index cannot be created on a column of type Long Text, a Unicode-enabled fixed-length text field
of more than 450 characters or a non-Unicode-enabled fixed-length text field of more than 900
characters. Consider these SQL limitations when deciding between the two field types.
6.2 Fixed-length text field considerations
If there are more than 8,060 characters in a single database row, SQL may experience performance
issues. As a result, a best practice is to limit the length of fixed-length text fields.
You can get the total field length usage for any workspace by viewing the document objects
properties in the Object Type tab for that workspace. This also applies to any Dynamic Objects.
When you create a fixed-length text field, configure the length of the field to the appropriate size.
The length can be increased as necessary throughout the life of the workspace. If you have a field
that will never exceed a certain length, set the length of the field to that value.
For example, a Document Extension field should have a small field length value. If there is a field
that could eventually grow to a great length — a Unicode-enabled fixed-length text field of more
Relativity | Environment Optimization Guide - 36
than 450 characters or a non-Unicode-enabled fixed-length text field of more than 900 characters
— then set it as a Long Text field initially rather than a Fixed Length Text field.
Note: For more information on limiting the total length of text fields in SQL, see
http://msdn.microsoft.com/en-us/library/ms186981.aspx.
After any major cleanup or length reduction of fixed-length text fields in a workspace, run the DBCC
CleanTable SQL Script afterhours on the database to reclaim free space. For the steps on running
this script, see http://msdn.microsoft.com/en-us/library/ms174418.aspx.
6.3 Unicode support
Define the Unicode Enabled property of a field prior to importing data. A database level operation
to convert a field’s data from Unicode to non-Unicode (or vice versa) can take a long time, lock
tables, and potentially timeout if performed on a large data set in Relativity.
Only the following field types are Unicode-compatible:
n
n
n
n
Fixed Length Text
Long Text
Single Choice List
Multi Choice List
Define the Extracted Text field as Unicode if there is a possibility that foreign text will be loaded into
the workspace.
6.4 Data imports
Use the Relativity Desktop Client to import data into Relativity.
There are two methods of importing native/TIFF files:
1. Copying files from the original location in the selected load file field to the document repository. This
copies the files from the original location in the selected load file field to the selected document repository.
2. Importing files that already reside in a valid, Relativity-accessible location.
Note: Use this option when native files already have been copied to their final location, accessible by Relativity.
This location should be separate from that of the Relativity document repository. The default option can be set
on an environment-wide level. For more information, see the Relativity Configuration Table Guide.
For either method, the selected native file path field should point to the current location of the
native files.
Many clients use the second option to reduce the total time it takes to load files into the Relativity
repositories. You can manually copy files to where they should reside and then providing the
Relativity | Environment Optimization Guide - 37
Relativity Desktop Client with pointers to their locations. This can save significant time when loading
large amounts of natives and/or TIFFs.
Never run the Relativity Desktop Client on a Relativity production server (Web, Agents, SQL, or
Search). Launch the tool on a different server or workstation to prevent resource contention.
6.5 Analytics
Use the following guidelines when setting up an Analytics index in your workspace.
n
n
When populating a Relativity Analytics index, exclude non-conceptual files such as XLS, EXE, or RAR
from the index. Make sure that the Training Set is limited to documents with less than 2 MB of Extracted Text, and make sure that the Searchable Set is limited to documents with less than 30 MB of Extracted Text.
Disable queries on indexes that are no longer being actively used. Queries are automatically disabled
for indexes that haven't been accessed within a pre-set number of days.
Note: This value is configured using the MaxAnalyticsIndexIdleDays value in the EDDS.EDDSDBO.Configuration
table.
n
When queries are enabled on an Analytics index, the index is loaded into RAM. Unused indexes
shouldn't consume resources on the CAAT server.
n
Use the following guidelines when setting up a structured analytics set in your workspace.
n
When creating a structured analytics set, exclude files with more than 30 MB of text, as these may slow
down the performance of the set.
6.6 Views and searching
Follow these best practices for views and searching:
n
Avoid Is Like and Is Not Like statements on un-indexed queries. Full table scans on large databases
using Is Like statements will severely load the server. A full table scan occurs when a query reads every
row in a table in order to locate the required information.
If possible, use a Contains condition instead. In order to use "Contains," you must add the field to the
Full Text Index.
Note: Is Set and Is Not Set criteria will also trigger a full table scan. A full table scan operation can be very IOintensive and take a while to complete on slower storage units.
n
Prevent users from filtering and/or sorting on Long Text fields within the document list in large workspaces. To do this, make sure the field's the Allow Sort/Tally property is set to No.
Relativity | Environment Optimization Guide - 38
6.7 Tally/Sum/Average mass operation
In the Tally/Sum/Average mass operation, the Tally option is audited. For the set of requested
documents, it lists each unique value found in that field along with the frequency of each
occurrence. The process can run on Fixed Length Text, Choice, User, and Number fields.
Tallying on un-indexed columns in large workspaces can take a while to complete and slow down
database/system performance. Be sure to place indexes on columns in SQL that will be regularly
tallied in large workspaces.
You can disable the ability to Tally in a workspace by setting each field's Allow Sort/Tally property to
No.
6.8 Group by for Pivot
When performing Pivot operations in large workspaces, you can improve Pivot performance by
placing a non-clustered index on the field being grouped on. Use SQL Server Management Studio to
place the index.
6.9 User notifications
There are several notifications available to help system admins better manage their Relativity
environments.
6.9.1 Message of the Day (MotD)
The Message of the Day (MotD) is a message displayed to all users when they log into Relativity.
MotD is most commonly used to inform users of planned system maintenance.
To activate or change the message of the day, navigate to the Instance Details tab from Home.
6.9.2 User status
The user status page displays a list of users currently logged into the system. To access the user
status page, navigate to the User Status tab from Home.
You can also send messages to any logged in users. This is helpful if you require emergency
downtime during a review. Relativity system admins can also force log out users from the system on
this page.
6.9.3 Default workspace tabs
When a user enters a workspace within Relativity, they are usually taken to the Documents tab. You
can change this default setting in the Tabs tab of any workspace.
Relativity | Environment Optimization Guide - 39
Set the Is Default property to Yes for the tab that you want to designate the default tab in a
workspace. If a user doesn't have access to the Default tab, he or she will be directed to the
Documents tab.
Modifying the default tab may be helpful in informing users of any upcoming workspace-level
maintenance. Additionally, it allows workspace administrators to direct users to custom pages that
contain links to instructional items, important information about the matter, or an overview of
workspace review progress.
7 Monitoring environment performance
The hardware and software hosting the instance must be healthy to provide an exceptional
Relativity experience. To ensure that your environment is healthy, review the following
performance considerations.
7.1 Windows and SQL server log analysis
Regularly monitor the Windows and SQL event logs. There are many third party tools available to
assist in the analysis of these logs. These tools can automatically email your IT team when warnings
or errors are generated. This type of monitoring is often overlooked by IT administrators. It is
important these logs are actively monitored on a regular basis in the environment.
There are many tools available to monitor and notify system admins of any issues that arise. It's
crucial that all Relativity servers are monitored for the following:
n
n
n
n
Available disk space - Administrators should be alerted of low disk space on any Relativity server.
Server availability - Administrators should be alerted if any server becomes unresponsive. This can be
accomplished with simple internal ping tests.
Website availability - Administrators should be alerted if the website becomes unavailable.
Resource utilization (See Resource utilization below.)
7.2 Resource utilization
Monitoring resource utilization is more involved. Understanding this information will allow you to
identify bottlenecks and anticipate when it might be time to scale or adjust the environment. The
license agreement does not limit the amount of hardware or Relativity roles you can add to an
instance; you can go make adjustments as needed.
Processor and memory utilization should be monitored across all servers. Note that SQL will always
show high memory utilization as it stores as much as it can in memory (SQL Max Memory setting
was discussed earlier). It is also important to identify any SQL Server storage bottlenecks, which
includes the disks or the connection to them.
Best practices for monitoring resource utilization includes gathering benchmarks at different times
of the day to determine what acceptable ranges are for the performance counters you intend to
Relativity | Environment Optimization Guide - 40
monitor. Create this baseline so you can compare it to results as the environment continues to grow.
Third party monitoring tools often simplify the gathering and summarizing of performance related
metrics and can allow your team to more easily identify when it might be time to scale one or more
areas of the system.
It's difficult to provide specific thresholds or recommendations for performance counters as every
environment is different.
We recommend using the following guidelines.
7.2.1 Monitoring disk usage
Disk latency is the fundamental measure of disk performance.
The Avg. Disk/sec Read and Avg. Disk/sec Write counters of the Windows Performance Monitor
“Logical or Physical Disk” Objects can be used to measure disk latency.
SQL Server Avg. Disk/sec Read latency should generally be 20ms or less per Microsoft best practices
for database volumes. However, 100ms or less is more realistic in environments with traditional
storage media. Granted, more recent developments in flash and solid state storage are allowing our
clients to take advantage of these technologies in one form or another to improve the user
experience of their Relativity offering.
SQL Server Avg. Disk/sec Write latency should generally be 3-5ms or less per Microsoft best
practices for transaction log volumes. However, 20ms or less is more realistic in environments with
traditional storage media. It is extremely important to keep the I/O response times on SQL database
log files as low as possible.
Attention should also be paid to the SQL Server tempdb system database in Relativity environments,
as this often becomes a bottleneck for many of our larger clients. It is becoming more common for
clients to store the tempdb database for each SQL instance on flash or solid state storage instead of
traditional, spinning media.
The following table provides additional suggestions for optimal SQL Server disk latency (source:
http://www.quest.com/Quest_Site_Assets/TechnicalBriefs/SQL_post_29x21_2010_
PerfmonFinal.pdf).
Object
Physical
disk
Counter
Avg. Disk Sec/Read
You Want Description
< 8 ms
A key measure of disk latency representing
average time, in milliseconds, of each read
to disk where >20 is poor, <20 is good/fair,
<12 is better, <8 is best
Physical
disk
Avg. Disk Sec/Write
< 8 ms
(noncached)
< 1 ms
(cached)
Relativity | Environment Optimization Guide - 41
A key measure of disk latency representing
the average time, in milliseconds, of each
write to disk where non-cached writes (>20
poor, <20 fair, <12 better, <8 best) differ
significantly from cached writes (>4 poor,
<4 fair, <2 better, <1 best).
Object
Counter
You Want Description
For OLTP databases, the lower this number
the better, especially for disks holding the
transaction log.
For additional information on monitoring for Disk I/O bottlenecks in a system, see
http://msdn.microsoft.com/en-us/library/ms175903.aspx.
The disk queue counters aren't usually helpful since they require that you know how many spindles
are included in an array as well as any available caching or auto-tier mechanisms.
It's also very important to ensure that the link between SQL and the storage is configured for
optimal performance. Please work with your storage unit provider to ensure that the pathing is set
up correctly and will provide optimal performance. This setup becomes more complicated when
virtualizing SQL.
Other performance objects typically monitored for SQL include several memory counters.
Page life expectancy can indicate if SQL has enough memory available to perform optimally. Lower
values during regular operations suggest a need to install more memory. A popular suggested
threshold for this counter is 300 seconds, which is often far too low. A more realistic value can be
determined by performing this equation (DataCacheSizeInGB/4GB *300).
Note: For more information, see http://www.sqlskills.com/blogs/jonathan/finding-what-queries-in-theplan-cache-use-a-specific-index/.
In addition to other available tools, you can log these performance counters using the Windows
Performance Monitor in Windows Server.
7.3 Analytics performance considerations
Use the following guidelines to ensure that the analytics operations perform quickly and efficiently
in your Relativity instance.
7.4 Server requirements for index builds
Server memory is the most important factor in building an analytics index. The more memory the
server has, the larger the datasets that can be indexed without significant memory paging. Use the
following equation to estimate how much free RAM on the analytics server is needed to complete
an Analytics index build:
(Number of training documents) * 6000 = RAM required (bytes)
Please note that this equation is based upon the average document set in Relativity. If the dataset
has more unique terms than an average dataset, more RAM will be required to build.
Relativity | Environment Optimization Guide - 42
The analytics index creation process also depends on CPU and I/O resources at various stages.
Ensuring that the analytics server has multiple processors and fast I/O increases efficiency during
the build process.
7.5 Memory requirements for querying
When an analytics index has queries enabled, the index is loaded into RAM in an lsiapp.exe process.
For indexes with millions of documents, this RAM requirement can be thousands of MB. The RAM
requirement is dependent upon the number of unique terms in the dataset. Therefore, the range of
RAM needed for an index to be enabled is as follows:
(Number of searchable documents) * 5000 = High end of RAM required (bytes)
(Number of searchable documents) * 400 = Low end of RAM required (bytes)
It is best practices to should Disable Queries on any analytics index that is not being used. This will
free up RAM on the analytics server, and they can be re-enabled instantly at any time.
The configuration variable MaxAnalyticsIndexIdleDays assists in disabling unused indexes. This value
controls the number of days that an analytics index can remain idle before it will be automatically
disabled by the Case Manager agent.
7.6 Server requirements for structured analytics
Structured analytics operations are executed using the Java process on the analytics server. Ensuring
that Java has enough RAM will prevent restarts of the service or out of memory exceptions. The
agent server should also be optimized to ensure that the export and import process are as fast as
possible. Ensure that there are multiple Structured Analytics Worker agents. It is recommended to
have 4 worker agents at minimum. Make sure that each worker agent has at least 1 GB RAM and 1
processor core available.
The structured analytics process also depends on CPU and I/O resources at various stages. Ensuring
that the analytics server has multiple processors and fast I/O increases efficiency during structured
analytics tasks.
7.7 Native imaging and processing performance considerations
Relativity native imaging and processing require one or more worker machines as described in the
Relativity system requirements. A separate license must be purchased for each worker server in
order to use Relativity Processing.
Relativity | Environment Optimization Guide - 43
7.7.1 Native imaging and processing worker threads
n
n
By default and if enough memory is available (750mb/thread), native imaging and processing will run
two worker threads per CPU core on each worker server for a total max of 16 worker threads per
worker machine.
The Relativity hard cap per worker machine is 16 threads. You can scale horizontally with multiple
worker machines.
7.7.2 Native imaging and Processing Queue
n
n
The queue manager is installed on the Native Imaging and Processing SQL Server.
The only thing that needs to scale on the queue side is cores and database file IOPS. Higher scalability
environments may want to eventually move the Processing Store Databases off the queue server’s SQL
server and into their own SQL server, leaving the queue server with nothing but the main Invariant
database to manage. Each Relativity workspace that has processing enabled will have its own Processing Store Database with the naming convention of INV#######.
7.7.3 Relativity imaging working agents
The way the queues work across native imaging and processing is a little different. This section is
specific to native imaging and not applicable processing.
n
n
n
n
Native Imaging worker machines use Relativity Agents called Imaging Workers. The primary task of the
Relativity Imaging Worker Agents is to keep the Native Imaging worker queue full, and to take the
images Native Imaging produces and add them to Relativity.
These Relativity Agents will queue up a job to Native Imaging, wait for it to finish, and then move the
data to Relativity, before repeating the process; each agent handles only one document at a time.
If the Native Imaging workers are starved for work (i.e. the agents cannot keep the work queue full
enough for all threads to have useful work), adding more Relativity Worker Agents will provide an immediate performance benefit.
On average, between one and two Relativity Native Imaging Worker agents per two Native Imaging
worker threads (one Native Imaging worker CPU core) will fully utilize the worker CPU without wasting
Relativity agent resources. Increasing any one resource without making an adjustment to the others
will likely have little benefit, as the other resources will become the bottleneck.
7.7.4 Relativity Processing
When scaling Relativity Processing Worker machines horizontally, it's equally important to scale the
storage if you want to continue to see linear improvements in performance. It will do no good to put
20+ worker machines online if your storage system doesn’t have the available IOPS and throughput
to support them.
Relativity Processing allows you to ingest raw data directly into your workspace for eventual search
and review without the need for an external tool. A processing job consists of two parts, file
discovery and file publishing.
Relativity | Environment Optimization Guide - 44
7.7.4.1 Discovery phase
During the discovering phase, the Relativity processing engine begins to ingest the files you
specified in a processing set, then OCR and/or text extraction are performed on those files.
Observations/Recommendations:
n
n
During this phase, the only real shared resource is the file share.
Depending on the storage subsystem, the source directory for the processing engine probably
shouldn't be the same as the file share hosting Relativity review.
Excessive read I/O from the file share hosting Relativity natives and images required for review
may increase Relativity viewer response times.
The same is true of the destination directory.
o
n
Excessive write I/O to the file share hosting Relativity natives and images required for review may
increase Relativity viewer response times.
Recommendation: For workspaces where processing will be used, ensure the default file share is on separate storage from the rest of the files. If this is not possible, thoroughly test the I/O capabilities of the
storage subsystem to ensure that these operations will not negatively impact Relativity review.
o
n
7.7.4.2 Publishing phase
At any point after the completion of file discovery, you can publish the files that have been
discovered in the processing set. During the publishing phase, the processed documents are made
available for review via the workspaces document tab.
Observations/Recommendations:
n
n
n
n
There is almost no contention on the file share as expected during this phase.
There is some SQL contention as data is inserted into the workspace database.
SQL processor utilization will increase during the publishing phase.
The SQL TempDB will also experience increased usage, but no worse than a standard Relativity data
import via the Relativity Desktop Client.
7.8 Performance Dashboard
kCura has developed a lightweight tool called the Performance Dashboard that performs basic
performance monitoring.
The Performance Dashboard (PDB) application is a diagnostic measurement reporting tool
integrated into Relativity. It enables Relativity Administrators to evaluate how the environment
performs over time by reviewing specific metrics for their workspaces. The Dashboard can generate
both a grid and a graphical display within the Relativity environment. Both displays include the
ability to filter on dates, workspaces, and key performance indicators.
Relativity | Environment Optimization Guide - 45
PDB also includes a user friendly report of Long Running Queries for the environment. See the
Performance Dashboard Guide for more information.
7.9 SQL server table index fragmentation
This section outlines the fragmentation of the SQL table column index, and describes how to
eliminate it to ensure optimal system performance.
7.9.1 SQL table indexes overview
SQL table column indexes are intended to improve system performance by reducing the amount of
I/O (disk read and write) operations necessary to retrieve data. Compare it to how the index of a
book helps you find information quickly without having to read every page.
These indexes speed up queries by providing quick access to data without the need for full table
scans. A full table scan occurs when SQL has to read every row in a table to obtain the information it
is querying. Each Relativity database contains many indexes to help ensure optimal performance. It
is important that these indexes be maintained throughout the life of a workspace.
7.9.2 Index fragmentation
Fragmentation occurs through the process of data modifications (INSERT, UPDATE, and DELETE
statements) made against the table and, consequently, to the indexes defined on the table. Because
these modifications are not ordinarily distributed equally among the rows of the table and indexes,
the fullness of each page can vary over time. For queries that scan part or all of the indexes of a
table, this kind of fragmentation can cause additional page reads and slow performance.
Note: This information was provided by the following Microsoft article: http://msdn.microsoft.com/enus/library/ms188917.aspx.
Relativity | Environment Optimization Guide - 46
7.9.3 Effects of fragmentation
If heavy fragmentation exists, performance will be degraded and Relativity will respond slowly,
resulting in timeouts across various parts of the application. This includes searches, views, updates,
deletes, data imports/exports, etc. Often a highly fragmented index can be worse than having no
index at all.
7.9.4 Identifying fragmentation
An administrator can use the GetIndexFragLevels Relativity Script to determine index fragmentation
for a database. It will identify all indexes in a database with an average fragmentation over 10
percent and page count above 50. This is available in the Relativity Script Library of your
environment.
This query places a significant strain on the SQL disks as it gathers current fragmentation levels. Do
not execute this on large workspaces while users are in the workspace. If the report returns nothing,
no indexes are heavily fragmented in that workspace.
7.9.5 Removing fragmentation
kCura has designed a smart script named IndexOptimize that eliminates index fragmentation in all
Relativity workspace databases. IndexOptimize is available for download on the Relativity Customer
Portal. Details are included in the comments section of the script.
Note: For instructions on setting up this SQL job, see SQL table index management on page 53.
Alternatively, you may wish to create a custom job that meets your specific needs.
We recommend scheduling IndexOptimize to run nightly.
8 Managing your Relativity environment
To effectively manage Relativity , follow these recommendations for backing up and maintaining
your environment.
8.1 Workspace management and maintenance
Large workspaces with more than 500,000 records often require that workspace or database
administrators place additional indexes on any necessary fields in the SQL database. This is to
ensure optimal workspace performance for the review team. For more information on SQL indexes,
see SQL table index management on page 53.
For example, if a document list view includes a sort condition on an un-indexed fixed length text
field in a multimillion record workspace, each time a user selects that view, the executed query is
Relativity | Environment Optimization Guide - 47
sorting on millions of rows. This can take an extended time to complete. Each time that a user
selects this view, significant server resources are consumed. Placing an index on this databases
eddsdbo.Document table column can help reduce the query time.
You can use the provided generic SQL script to create indexes. Execute the following to place a nonclustered index on a field:
CREATE NONCLUSTERED INDEX [IX_FieldName] ON [EDDSDBO].[Document] ([FieldName] ASC)
n
n
n
n
Execute within the context of the database you would like to add the index.
Replace the two instance of FieldName with the name of the field you would like to place an index on
(IX_ is just a naming convention). Consider including your initials here for identification purposes.
If any of the fields have spaces or special characters in the name, remove them here in the script.
In general, this should be executed after hours because the table will become locked for writes during
the duration of the index build.
In addition to Fixed Length Text fields, indexes can be applied to Yes/No (Boolean), Decimal, Whole
Number, or Date fields on the document table of a workspace database. Workspace administrators
should identify which fields will be regularly queried, sorted, and filtered on in large databases for
index creation.
Note: Any manually created indexes will carry over during workspace creation, because Relativity performs
a full backup restore operation and does not contain any logic to delete indexes that were not created by
Relativity.
Understanding when and where to create additional non-clustered indexes improves with
experience. Avoid indexing everything because a large number of additional indexes can slow down
insert and update operations. This can also increase the size of the database which will ultimately
increase maintenance, backup, and replication times.
Indexes should ideally be read in from the SQL server more often than they are written to. SQL
Dynamic Management Views collect and store index usage information. There are scripts available
to query this data for reporting purposes. Note that restarting SQL server will purge data stored in
the DMVs, so only analyze this information when the SQL instance has been online for at least a few
days or weeks.
8.1.1 Analysis of long running queries
Long running queries are those that take more than a few seconds to complete. This can include
document list views, advanced searches, and other areas of the platform.
Using the History tab in any workspace, administrators can identify long running queries. Include
the Execution Time field in a History tab view to identify queries that take an extended amount of
time to process.
Relativity | Environment Optimization Guide - 48
The process of identifying workspaces with a large number of long running queries has been
simplified with the introduction of the Performance Dashboard. See the Performance Dashboard
Guide for more information.
The actual SQL executed for every query is also available in the History tab for each workspace. The
information presented in the History tab is stored in the eddsdbo.AuditRecord table for each
workspace.
Determine if these queries can be optimized to run more efficiently in Relativity. For example, avoid
nested or combined searches when possible because they can lead to additional overhead. Avoid Is
Like statements and simplify the criteria wherever possible.
If you're not familiar with SQL Server query optimization, use the SQL Server Database Tuning
Advisor to analyze queries for suggested indexes. Any troublesome queries that can't be made more
efficient through Relativity can be sent to the SQL Server Database Tuning Advisor for suggestions.
Apply any suggested indexes and statistics after hours, if necessary.
If you are experienced with SQL Server query optimization, consider analyzing the estimated and
actual executions plans for a query before submitting it to the tuning advisor. These executions
plans can be obtained from SSMS.
There are other SQL tools available to help identify long running queries, resource usage and
overuse, and database locking issues. These tools are affordable and can assist in SQL Server
performance troubleshooting. Additionally, use the SQL Server 2008 Activity Monitor in addition to
the SQL profiler. Use caution and follow Microsoft best practices if you need to run SQL profiler
because it can be resource intensive.
8.1.2 Full-text index management
One of the more notable enhancements in SQL Server 2008 is Integrated Full-Text Search. In
Relativity, the keyword search function queries the full-text index of a workspace’s database.
You can query the health of a full text index in SQL Server 2008. The following query returns the
number of fragments in a full-text index. Execute it on the database in question.
SELECT OBJECT_NAME(table_id) AS [Table Name], fragment_id, fragment_object_id, [status],
data_size, row_count
FROM sys.fulltext_index_fragments WITH (NOLOCK)
For more information on full-text index fragments, see http://msdn.microsoft.com/enus/library/cc280700.aspx.
If you experience slow keyword search performance, the full-text index may need to be rebuilt for
that database. You can determine this in SQL Server 2008 by querying the amount of FT fragments.
Microsoft states that performance will suffer significantly if an index has more than 100 fragments.
We suggest rebuilding or merging indexes with more than 10 fragments.
Relativity | Environment Optimization Guide - 49
To rebuild the FT Catalog for a workspace:
1.
2.
3.
4.
5.
Navigate to that database in SQL MGMT Studio.
Expand the Storage folder.
Expand Full Text Catalogs.
Right click on the FT Catalog.
Select the option to Rebuild.
During a full-text index rebuild, the workspace will still be accessible but any keyword or "Contains"
searches will return incomplete results as the index populates. Because of this, perform this task
after hours. Select Properties for the index to view build status and progress.
You could optionally take a full backup of a database, restore it to the same server, and rebuild the
full-text index for this restored database. Next, run an identical "Contains" query across each to
measure any performance gain from a rebuild, as well as to gauge how long it will take to rebuild in
the production database and schedule any necessary outage.
This type of maintenance is usually only necessary on larger workspaces containing more than
500,000 records. In general, these workspaces have been active for a long time and have had
columns added and/or removed from the index.
Note: For more information on full-text search internals and enhancements, see
http://msdn.microsoft.com/en-us/library/cc721269.aspx.
8.1.3 Audit record table
All history for a workspace is stored in the AuditRecord table for that database. The data stored in
this table is presented in the history tab for that workspace in Relativity. Relativity audits all activity.
An active workspace with one hundred users can generate over ten million audits per month. This
table could grow in size by hundreds of millions of rows in some scenarios.
If this table is very large, reducing its size can result in faster backup and index rebuild times, and
provide better query performance when users need to fetch audit data.
Unfortunately, clients often require all audit history be readily available to the review team. In some
cases, it may be possible delete some of the existing audit entries to reduce size and reclaim space.
Consider the following options:
1. Backup the database, backup the AuditRecord table, and then truncate the table (delete all existing
audit history).
2. Backup the database, backup the AuditRecord table to a certain date, and then delete everything from
the table with a timestamp before that date.
If it's not possible to delete any audit entries, there are other options available to help assist with
the management of this large table. See the Database Partitioning for Archiving Audit Records in
the Relativity Customer Portal.
Please contact [email protected] for assistance with this operation.
Relativity | Environment Optimization Guide - 50
8.2 SQL backups
All tasks mentioned in this document can be set up via the Maintenance Plan Wizard in Microsoft
SQL Server Management Studio. Other third party backup tools are available that are easier to
manage, have a high compression ratio, and may take less time to complete.
Backup the following to ensure a full recovery of the system, if that becomes necessary:
n
n
n
n
n
n
n
Relativity Workspace Databases (.mdf, .ndf) - All relevant databases are of the format EDDS#######
Relativity Workspace Database Logs (.ldf) - All relevant database logs are of the format EDDS#######
Relativity System Databases (.mdf, .ndf) - EDDS, EDDSResource
Relativity System Database Logs (.ldf) - EDDS, EDDSResource
Relativity Processing and Native Imaging Databases – INV#######, Invariant, RelativityImaging
Relativity Processing and Native Imaging Logs - INV#######, Invariant, RelativityImaging
System Databases and Logs - master, model, msdb (tempdb doesn’t need to be backed up)
The Full-Text Engine in SQL Server 2008 is fully integrated into the database, and full-text indexes
are stored within database files (.ndf) rather than externally in the file system. Back up these files as
well if they're in a separate file group.
8.2.1 Full backups
A Full Backup backs up the entire database. This includes the transaction log so that the full backup
can be recovered.
Creating a full backup is a single operation, usually scheduled to occur at regular intervals. We
recommend running a full backup nightly or weekly, because it's time consuming and may affect
performance. Writing to fast storage, maintaining log file sizes, and including backup file
compression can help reduce full backup execution time.
Although not required, verifying a backup is a useful practice. Verifying a backup checks that the
backup is physically intact, ensures that all the files in the backup are readable and can be restored,
and confirms that you can restore your backup in the event you need to use it.
Relativity | Environment Optimization Guide - 51
8.2.2 Differential backups
A Differential Backup contains all data that has changed since the last full backup, known as the
base. Differential backups are quicker and smaller than full backups because they contain only what
has changed since the previous backup.
Differential backups have some limitations:
n
n
They can only be restored after a full backup is restored.
They provide no point-in-time restore capabilities.
8.2.3 Transaction log backups
Transaction log backups provide point-in-time restores or point-of-failure restores of databases.
Another advantage of transaction log backups is that SQL Server automatically truncates the
inactive portion of the transaction log after it finishes backing up the transaction log. This inactive
portion contains completed transactions and is no longer used during the recovery process. The
active portion of the transaction log contains transactions that are still running and have not yet
completed. SQL Server reuses this truncated, inactive space in the transaction log instead of
allowing the transaction log to continue to grow and use more space.
In kCura’s hosted instance, we take full backups nightly and transaction log backups hourly during
the day. Other partners may only take full backups on the weekends and differentials nightly, along
with transaction log backups during the day. You may have to adjust your backup schedules to
accommodate different review schedules.
For additional best practices on maintaining SQL Database Log (ldf) Files, see the Managing
Relativity SQL Log Files document on the Customer Portal.
8.3 SQL recovery models
Recovery models are designed to control transaction log maintenance. There are three different
types of recovery models. This can be set on the database level.
The default databases deployed with Relativity are set to use the Full recovery model. This setting is
carried over to any new databases since Relativity is performing a full backup and restore operation
during workspace creation. Only the EDDSResource database is set to use the Simple recovery
model. The EDDSResource database is where Relativity stores queue tables and other non-critical
temporary data.
Relativity supports the Simple recovery model for all workspace. This decision would be entirely
dependent on the disaster recovery requirements of your team. The considerations with making this
change are detailed in the following MSDN article: http://msdn.microsoft.com/enus/library/ms189275.aspx.
Relativity | Environment Optimization Guide - 52
8.4 Relativity data backups
In addition to the SQL data, we recommend backing up the following on a regular basis:
n
n
n
dtSearch and Analytics Index Shares - These can be rebuilt but the process may take days depending
on the amount of data.
Relativity Web Server Install Directories - The IIS Relativity virtual directories should be backed up to
ensure any event handlers, custom logos, etc., can be recovered.
Native and Image File Shares - Larger Relativity installations can potentially have millions of these files.
The storage unit housing these files most likely includes several layers of redundancy. You must decide
what backup solution works best for your team.
8.5 Check database integrity task
The Check Database Integrity task checks the allocation and structural integrity of all the objects in
the specified database.
This task executes the DBCC CHECKDB Transact-SQL statement. This ensures that any integrity
problems within the database are reported, which allows them to be addressed by a system admin.
For details, see http://msdn.microsoft.com/en-us/library/ms176064.aspx.
We recommend scheduling this task to run weekly.
Ideally, you should run this task nightly. The earlier you find any database corruption, the quicker
you can address it and reduce the risk of data loss. Unfortunately, this task can be very time
consuming and resource intensive on larger databases. As a result, we suggest scheduling it to run
weekly.
A few Relativity installations have encountered database corruption in the past. This is usually
caused by the underlying storage. It's important to schedule and monitor this task. If the task
completes successfully, then there's no corruption in the analyzed databases.
8.6 SQL table index management
It's important to eliminate table index fragmentation in all Relativity databases. For more
information, see SQL server table index fragmentation on page 46.
kCura developed the IndexOptimize smart script to eliminate index fragmentation and update
statistics in all Relativity workspace databases. You can download IndexOptimize on the Customer
Portal. Details are included in the comments section of the script.
We recommend scheduling this task to run nightly.
Relativity | Environment Optimization Guide - 53
Note: See the SQL Server Maintenance Plan Setup document on the Customer Portal for assistance with
setting up and scheduling Index Optimize along with other SQL maintenance plans. If you require a
Customer Portal account or assistance with maintenance plan setup, please email the request to
[email protected]
8.6.1 Updating statistics
The SQL Query Analyzer uses statistics to choose the best path for obtaining data in order to boost
query performance.
This task updates query optimization statistics on a table or indexed view. The query optimizer
already updates statistics as necessary to improve query plans by default. In some workspaces, you
can improve query performance by using UPDATE STATISTICS or the stored procedure sp_
updatestats to update statistics more frequently than the default updates. For details, see
http://msdn.microsoft.com/en-us/library/ms187348.aspx.
Consider updating statistics after performing maintenance procedures that change the distribution
of data, such as truncating tables or performing bulk inserts of a large percentage of rows, such as
data imports. This can avoid future delays in query processing while queries wait for automatic
statistics updates.
Note: For more information on updating statistics to improve query performance, see
http://msdn.microsoft.com/en-us/library/ms190397.aspx.
8.7 Database log management
The database transaction log file (.ldf) stores details of all modifications performed on the SQL
Server database and the details of the transactions that performed each modification.
8.7.1 Size management
SQL Server automatically marks the inactive portion of the transaction log for reuse after it finishes
backing up the transaction log. This inactive portion contains completed transactions and is no
longer used during the recovery process. The active portion of the transaction log contains
transactions that are still running and have not yet completed. SQL Server reuses this reclaimed,
inactive space in the transaction log instead of allowing the transaction log to continue to grow and
use more space.
We recommend scheduling transaction log backups to occur every hour or less during the day to
keep these file sizes in check.
Although the transaction log may be truncated manually, we strongly advise against doing this
because it breaks the log backup chain. Until a full database backup is created, the database is not
protected from media failure. Use manual log truncation only in very special circumstances, and
Relativity | Environment Optimization Guide - 54
create a full database backup as soon as practical. You can truncate and shrink the transaction log
file for a database with the following SQL script.
--SQL Server 2008 R2
USE EDDS#######
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE EDDS#######
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 GB.
--Specify the correct name of the file
DBCC SHRINKFILE (EDDS#######_Log, 1024)
-- Reset the database recovery model.
ALTER DATABASE EDDS#######
SET RECOVERY FULL;
GO
Transaction logs can present problems because they are often forgotten until an issue occurs. The
log continues to grow as operations are performed within the database. As the log grows, available
disk space decreases. Unless routine action is taken to prevent this, the transaction log will
eventually consume all available space. If the log is configured to grow indefinitely (which is the
default), it'll grow to consume all available physical disk space where it's stored. Either scenario will
cause the database to stop functioning.
Regular backups of the transaction log will help prevent it from consuming all of the disk space.
For additional best practices on maintaining SQL Database Log (ldf) Files, see the Managing
Relativity SQL Log Files document on the Customer Portal.
8.7.2 Virtual log file (VLF) management
Database transaction log files can become internally fragmented when they're not pre-allocated or
there have been many auto growth operations. This is described in many blogs and SQL serverrelated articles.
SQL Server 2012 will actually begin to automatically check for the amount of VLFs in database log
files and write a warning event for database logs with an excessive amount.
8.8 Shrink database task
The Shrink Database task reduces the size of SQL Server database and log files.
If you decide to incorporate this task into your regularly scheduled maintenance to save disk space,
only shrink "Inactive" Relativity workspace databases. The StatusCodeArtifactID column of the
EDDS.eddsdbo.[Case] table contains workspace status information, which is also displayed in the
Workspace Details tab of each Relativity workspace. Please note that a database shrink operation
can be resource intensive.
Relativity | Environment Optimization Guide - 55
8.8.1 Best practices
Consider the following information before shrinking a database:
n
n
n
n
A shrink operation is most effective after an operation that creates lots of unused space, such as a truncate table or a drop table operation.
Most databases require some free space to be available for regular day-to-day operations. If you shrink
a database repeatedly and notice that the database size grows again, this indicates that the space that
was shrunk is required for regular operations. In these workspaces, repeatedly shrinking the database
is not useful.
A shrink operation doesn't preserve the fragmentation state of indexes in the database and generally
increases fragmentation to a degree. This is another reason not to repeatedly shrink the database.
Do not set the AUTO_SHRINK database option to ON. This option is removed in SQL Server 2012.
Note: For more information on shrinking the database, see http://msdn.microsoft.com/enus/library/ms190488.aspx.
8.9 Job email notification alerts
Job email notification alerts are designed to notify system admins when a SQL job has completed
and whether it was successful. It's important to configure these email alerts.
Set up SQL Database Mail on all Relativity SQL Servers and add these notification alerts to all
scheduled Relativity maintenance tasks. Set up the alerts to email system admins when jobs succeed
or fail. Whenever possible, set the operator’s email address to a distribution list rather than an
individual email.
8.10 Relativity applications
You can extend the functionality and features available in Relativity by installing custom applications
to workspaces as well as adding them to the application library. You also have the option to uninstall
these applications when you no longer need them in your environment. To ensure optimum
performance of Relativity, uninstall applications only during off hours when users aren't actively
reviewing documents in any workspaces.
For more information, see Application Deployment System on the Relativity 8.2 Developers site.
9 Expanding your Relativity environment
Use the following additional features and tools to expand your Relativity environment.
Relativity | Environment Optimization Guide - 56
9.1 Agents
Agents are process managers that run in the background of Relativity. The Agents tab allows you to
see which agents are running in your environment and the status of those agents. Adding multiple
instances of certain agents can increase the speed of imaging, productions, OCR jobs, and index
builds.
In general, use one processor core and 1 GB of memory for each additional agent. You can house
these agents on multiple servers in the Relativity environment. For example, you may want to
incorporate another agent server to increase the speed of productions. Allocate eight processor
cores and 8 GB of memory to house eight additional Branding Manager agents.
Starting in Relativity 7.5, administrators can adjust agent configurations through the Relativity
interface. It's important for Relativity administrators to understand agent best practices before
adjusting agent configurations. For more information, see the Agents guide.
Note: For Relativity agent scaling best practices, see the Relativity Performance Specifications document on
the Customer Portal. Contact [email protected] for help configuring agents in Relativity.
9.2 Analytics servers
Relativity supports multiple Analytics servers in order to allow jobs to run concurrently and to
allocate resources among different workspaces. When implementing a multi-server analytics
environment, some considerations should be taken into account:
n
n
n
What is the average dataset for analytics?
What is the largest potential dataset for analytics?
What type of jobs will be running on the server?
While the minimum system requirements for analytics are specified as 32 GB RAM, this server has
limitations. A server of this size could not build an index with more than 5 million training
documents. Depending on the number of indexes enabled on the server, the limitation may be even
smaller than this.
Beginning in Relativity 8.0, there are two main feature sets in Relativity Analytics – structured
analytics and conceptual analytics indexing. These feature sets have differing requirements when
considering the RAM requirements for Java. (For more information, see Java heap size (JVM).) For
this reason, if heavy structured analytics usage is anticipated, it is highly recommended to have an
analytics server dedicated to structured analytics.
Note: Never install any Relativity agents on an Analytics server.
To implement this configuration, install the Analytics component on an additional server. For
instructions on installing Analytics, see Upgrading or installing Analytics. After installing the
Analytics component to the server, add the server to the Servers tab at Home. For instructions on
Relativity | Environment Optimization Guide - 57
adding analytic servers, see Adding an Analytics or processing server. When adding the server in
Relativity, the type of analytics server (i.e. structured analytics or conceptual analytics indexing)
may be selected to control the functions the server will perform.
9.3 Dedicated web servers
You can install additional web servers for specific Relativity roles, such as Relativity Desktop Client
imports/exports and dtSearch.
9.3.1 Desktop Client import/exports
You can improve local data import and export performance by utilizing a web server separate from
the primary review web server. This also reduces the load on the primary review web server.
To do this, install the WebAPI and Distributed web portions of Relativity onto another web server
that meets our web server requirement specifications. Update the WebService URL in the settings of
the Relativity Desktop Client to reflect the new server name,
http://servername/RelativityWebAPI/.
9.3.2 dtSearch performance
As Relativity workspaces get exponentially larger year-over-year, we continue to evaluate areas of
the application that can be improved to handle large data volumes with better performance. One of
the areas we’ve been looking at recently is dtSearch. We are very excited about a dtSearch
improvement we’re calling search grid. Search grid significantly accelerates index build and search
times in two ways.
First, search grid makes index builds faster by eliminating the need to build and maintain one large
consolidated dtSearch index. Instead, a single index is partitioned into multiple smaller indexes,
which multiple workers build simultaneously. We introduced distributed index building in Relativity
7.3, but search grid further increases performance by removing the need to do a final merge of the
index—searches will be performed against the multiple smaller indexes in parallel. Results will then
be federated and returned.
Second, the use of the Relativity agent framework to distribute both the indexing and search
functions improves dtSearch performance. Relativity used the Relativity Web API prior to Relativity
Relativity | Environment Optimization Guide - 58
8 on one or more web servers to handle dtSearch search requests. We implemented the ability to
use the agent framework to host a dtSearch search service across one or more servers—dtSearch
would no longer use IIS for index search requests. Search grid allows administrators to manage the
available search resources more efficiently through the agent management enhancements
introduced in Relativity 7.5. You're able to easily add new search agents and quickly respond to enduser needs.
Search grid makes searching faster by distributing the search request across multiple servers to the
multiple partitions of a logical index. Our labs have shown search grid can significantly increase
search performance on large indexes.
The dtSearch search agent(s) require an additional port be opened on Relativity search agent and
SQL Servers. This port will be used for WCF communication over the TCP protocol.
Ideally, each Relativity dtSearch search agent has its own server, similar to existing dtSearch
WebAPI web servers. Relativity administrators would have the ability to add the search agent to
servers with other Relativity agents. However, this is not advisable as one dtSearch search agent will
be able to utilize all available resources on a server.
9.3.3 Physical memory on the SQL Server(s)
Install additional memory on the Relativity SQL Server(s) for an overall performance gain. The more
memory installed, the less SQL will have to access disks. Disk access is slower.
The majority of SQL Server memory is used for the following processes:
n
n
Each time SQL Server reads from disk, it commits those pages to memory so that future requests for
the same data are cached in the Buffer Pool and readily available.
The Procedure Cache stores the most optimal Execution Plans in memory so that they don't need to be
recompiled each time, which can be processor-intensive.
The more information that can be stored in memory, the better. The following specifies the
maximum memory supported for each edition of SQL Server 2012.
SQL Server Edition
Enterprise
Standard
Maximum Memory Supported
Operating system maximum
64 GB
Be sure to update the following variables after installing additional memory:
n
Set the SQL Server Max Server Memory server configuration option. For more information, see Configuring SQL Server on page 16.
It's suggested that enough memory be made available to cache the eddsdbo.Document table of your
largest, most active workspace(s) in RAM. If you don't host any particularly large workspace
databases but host many, you should have enough memory to cache the three largest workspaces
combined.
Relativity | Environment Optimization Guide - 59
9.4 SQL Server failover clustering
SQL Server failover clustering ensures SQL Server availability and provides protection in the event of
hardware failure. Failover to another node is quick and provides service availability, but it doesn't
provide data redundancy. Instead, data protection is usually provided at the storage level.
(Source: http://www.mssqltips.com/tipprint.asp?tip=1882.)
A SQL Server cluster appears on the network as a single SQL Server instance on a single computer.
Internally, only one of the nodes owns the cluster resource group at a time, serving all the client
requests for that failover cluster instance.
In case of a failure (hardware failures, operating system failures, and application or service failures)
or a planned upgrade, group ownership is moved to another node in the failover cluster. This
process is called failover.
By leveraging the Windows Server failover cluster functionality, SQL Server failover cluster provides
high availability through redundancy at the instance level.
Note: This information was provided by the following Microsoft article: http://msdn.microsoft.com/enus/library/ms189134.aspx.
SQL server clustering is only supported in Enterprise editions of Windows Server. The number of
nodes supported for failover clustering depends on the operating system and the SQL Server Edition.
9.5 Distributed Relativity SQL Servers
Scale out the existing Relativity environment by incorporating additional SQL Servers. This helps
distribute the load and allows you to store larger, more demanding databases on their own
Relativity | Environment Optimization Guide - 60
dedicated set of resources. Any number of Relativity servers can be included in an environment.
Each additional Relativity SQL server is referred to as a "Distributed" SQL server, unlike the Master
SQL server, which houses the EDDS database. There's only one EDDS database in a Relativity
environment.
You can create new workspaces on any distributed SQL server. You can also migrate existing
workspaces between servers as needed.
Note: Contact [email protected] to obtain distributed SQL Server setup documentation.
9.6 Web load balancing
Multiple web roles can be used to distribute Relativity user load.
9.6.1 Microsoft network load balancing
Relativity supports different methods of web load balancing and the ability to distribute user
sessions across multiple servers, which distributes the server load and allows for redundancy.
Currently, Relativity supports Windows Load Balancer, set to Single affinity mode. Relativity doesn't
support an affinity of None at this time.
Single affinity directs a specific IP address to the same server every time until the NLB Cluster is
broken, a new server is added to the cluster, or a server is turned off. If you have multiple users
behind a firewall, all of the users will be directed to a specific server and they'll stay there until the
cluster is broken. This doesn't provide true NLB support, but it's required because the viewer uses an
authentication token to create a second connection on the web server.
Note: Contact [email protected] to obtain NLB setup documentation.
9.6.2 Relativity user load balancing
You can use Relativity's Enable User Load Balancing feature to equally distribute user loads across
all web servers that have Enable User Load Balancing set to Yes. When a user connects to the login
page, the platform looks at the user status table to determine how many users are logged into each
web server. The user will then be re-directed to the web server with the lowest number of logged in
users.
This requires setting up multiple URLs in addition to having multiple web servers or VMs. For more
information, see the Admin Guide.
Note: This feature only load balances users logging into the system, not Relativity Desktop Client sessions.
Relativity | Environment Optimization Guide - 61
9.7 Terminal Services
To accommodate users with poor network connectivity, consider providing some type of a Terminal
Services option. We suggest having Terminal Services solution available as a backup. The hardware
required for this server role is dependent on the number of users it needs to support.
Deploying a program on a terminal server instead of on each device provides the following benefits:
n
n
n
n
You can quickly deploy Windows-based programs to computing devices across an enterprise. Terminal
Services is especially useful for programs that are frequently updated, infrequently used, or difficult to
manage.
It can significantly reduce the network bandwidth required to access remote applications.
It improves user productivity. Users can access programs running on a terminal server from devices
such as home computers, kiosks, low-powered hardware, and operating systems other than Windows.
It provides better program performance for branch office workers who need access to centralized data
stores. Data-intensive programs sometimes don't have client/server protocols that are optimized for
low-speed connections. Programs of this kind frequently perform better over a Terminal Services connection than over a typical wide area network (WAN).
For this and more information on Terminal Services, see http://technet.microsoft.com/enus/library/cc755053(WS.10).aspx. For the Windows Server 2008 R2 Performance Tuning Guidelines,
see http://msdn.microsoft.com/en-us/windows/hardware/gg463392.
9.8 Bandwidth tester
The Relativity bandwidth tester is designed to test the capacity of a network connection. This
application can be executed at any time. It's a valuable as a troubleshooting tool for users
experiencing viewer issues due to a lack of data rate support from a network connection.
To launch the bandwidth tester, click the Launch Bandwidth Tester icon in the bottom right corner of
the viewer, to the left of the Layout/Related Items pane.
For more information on the bandwidth tester, see the Admin Guide.
9.9 User notifications
There are several notifications available to help system admins better manage their Relativity
environments.
Relativity | Environment Optimization Guide - 62
9.9.1 Message of the day (MotD)
The message of the day is a message displayed to all users when they log into Relativity. MotD is
most commonly used to inform users of planned system maintenance.
To activate or change the message of the day, navigate to the Instance Details admin tab.
9.9.2 User status
The user status page displays a list of users currently logged into the system. To access the User
Status page, navigate to the User Status tab of the Relativity System Administrators section or any
workspace.
You can also send messages to any logged in users. This is helpful if you require emergency
downtime during a review. Relativity system admins can also force log out users from the system on
this page.
9.9.3 Default workspace tabs
When a user enters a workspace within Relativity, they are usually taken to the Documents tab. This
can be changed. Within the Tabs Tab of any workspace, you can set the default tab to be something
other than the Documents tab.
Is Default allows you to select one tab to be the default tab in a workspace. Reviewers logging into
the workspace will be taken to the default tab. If a reviewer does not have access to the Default tab,
he or she will be taken to the Documents tab.
This may be helpful in informing users of any upcoming workspace level maintenance. Additionally,
it allows workspace administrators to direct users to custom pages that may contain links to
instructional items, important information about the matter, or an overview of workspace review
progress.
Relativity | Environment Optimization Guide - 63
Proprietary Rights
This documentation (“Documentation”) and the software to which it relates (“Software”) belongs
to kCura LLC and/or kCura’s third party software vendors. kCura grants written license agreements
which contain restrictions. All parties accessing the Documentation or Software must: respect
proprietary rights of kCura and third parties; comply with your organization’s license agreement,
including but not limited to license restrictions on use, copying, modifications, reverse engineering,
and derivative products; and refrain from any misuse or misappropriation of this Documentation or
Software in whole or in part. The Software and Documentation is protected by the Copyright Act of
1976, as amended, and the Software code is protected by the Illinois Trade Secrets Act. Violations
can involve substantial civil liabilities, exemplary damages, and criminal penalties, including fines
and possible imprisonment.
©2015. kCura LLC. All rights reserved. Relativity® and kCura® are registered trademarks of kCura
LLC.
Relativity | Environment Optimization Guide - 64
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement