

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.
Note: These guidelines are applicable to all SQL Servers in the environment, including the Worker Manager SQL Server and the workers.
Install the latest Microsoft Windows Server Service Pack on all Relativity servers.
However, compatibility for higher .NET versions is not guaranteed. We do not recommend installing higher .NET versions than what is listed as required by your Relativity version. Furthermore, install any smaller security patches, Windows updates, and anything else at your own discretion. We only test major service packs, not every Microsoft update. Deploy any patches to your test instance of Relativity first. Ensure that a rollback plan is in place if you discover any issues during deployment.
Ensure you disable the option to Install updates automatically on all Relativity servers. Apply any required updates during a planned maintenance window.
Windows includes standard visual effects to make the user experience more enjoyable. These effects aren't required and consume CPU resources. We recommend disabling these effects on all Relativity servers.
Application performance is related to processor scheduling caching options that you set for Windows Server. Processor scheduling determines the responsiveness of applications you run interactively (as opposed to background applications that may be running on the system as services). We recommend that you select background services on all Relativity servers.
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.
Note: Work with your storage vendor to see if they recommend installing a defragmenting tool.
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's in use by all 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. This frees that RAM frame for other uses. Windows stores these "paged out" pages in one or more files. The name of the file is pagefile.sys. You can find this file in the root of a partition. One pagefile.sys file can exist in each disk partition.
You can configure the location and size of the page file in the Control Panel. To set these values, click System > 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. Windows Server creates a default size of the paging file that is 1.5 times the physical RAM, up to a maximum of 4095 MB.
Consider the following:
Manually setting the size of the paging file provides better performance than the server automatically sizing it. It's a best practice to set the initial minimum and maximum size settings for the paging file to the same value. This ensures no processing resources are lost to the dynamic resizing of the paging file. 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. This improves disk seek time.
Microsoft recommends isolating the paging file onto one or more dedicated physical drives. Configure these drives as either RAID-0 (striping) or RAID-1 (mirroring) arrays. Or the paging file should be on single disks without RAID. Redundancy is not normally required for the paging file. Don't configure the paging file on a RAID 5 array. It's not recommended to configure the paging file on a RAID 5. This is because paging file activity is write-intensive and RAID 5 arrays are better suited for read performance than write performance.
Configure all antivirus software on any of your Relativity servers to exclude the following areas:
Note: Keep in mind your environment may differ slightly.
C:\Windows\System32\config\systemprofile\AppData\Local\Relativity\TempStorage
Note: Keep in mind your environment may differ slightly.
C:\Windows\System32\config\systemprofile\AppData\Local\Relativity\TempStorage
C:\Windows\System32\config\systemprofile\AppData\Local\Relativity\TempStorage
Note: We recommend that you scan any raw data for malware before introducing it into your Relativity environment. If you perform a scan, you may be comfortable excluding the Temp directories on your worker servers from your antivirus scans as well. This results in better performance and fewer interruptions due to live scans on the temp files that Relativity Processing (Invariant) creates in these directories. Unscanned raw data has potential to introduce harmful files into your environment.
ARM archive locations - directory where the ARM archive locations are located.
Cache locations - directory where servers temporarily store converted copies of natives, images, productions, and other file types.
Whenever possible, avoid logging in to 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. If you have an external hard drive containing data that you want to import into Relativity, connect it to this server and launch the Desktop Client on it to perform the data imports or export.
We also recommend that you install the Marvel cluster to the management server. Use this cluster to monitor and report on the performance and usage of the Data Grid Cluster. The Marvel cluster saves the daily indexes to its own data node. Carefully monitor the drive space used by these indexes so that the drive doesn't run out of space.
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.
Why was this not helpful?
Check one that applies.
Thank you for your feedback.
Want to tell us more?
Great!