The TUNED_ADM command line tool enables switching between different tuning profiles in Linux. In this best practice, we used the TUNED_ADM tool to switch to an optimized Linux profile for SQL Server. 

Overview

The TUNED_ADM tool enables the Linux administrator to switch between profiles for the operating system. Predefined profiles enable the application of Linux configuration settings in a downloadable package. In this best practice, we downloaded and installed the TUNED-MSSQL in the Linux operating system. This resulted in the following changes in the tuned SQL Server profile:

• FORCE_LATENCY = 5

Certain configuration parameters adjust the PM QoS CPU DA latency according to the CPU load. For example, the force_latency parameter enables the user, or in this case the SQL Server profile, to force a specific value. For more information on this CPU configuration parameter and similar parameters, see the Red Hat Performance Tuning Guide.

• V.TRANSPARENT_HUGEPAGES set to ALWAYS

Transparent HugePage Support (THP) automates the promotion and demotion of memory pages. Promotion is the automation from small memory pages to larger memory page sizes and demotion is the automation from larger memory pages to smaller memory pages. SQL Server uses transparent HugePages to optimize performance thus, this parameter is set to ALWAYS.  

• VM.SWAPPINESS was set to 1

Swap space is used by the Linux operating system as virtual memory. This works by the Linux kernel writing data from RAM to the swap space, which allows for greater memory use on the system. By changing VM.SWAPPINESS to 1 the kernel is instructed to more aggressively reclaim unmapped memory, rather than using swap space. 

• VM.DIRTY_BACKGROUND_RATIO is set to 3

The DIRTY_BACKGROUND_RATIO is the percentage of memory that contains free pages and reclaimable pages, that can be filled with dirty pages before the pages are written to disk. Databases can aggressively use the kernel page cache which lowers the background ratio, forcing the kernel to flush the dirty pages to disk more frequently. 

• VM.DIRTY_RATIO is set to 80

The DIRTY_RATIO is the percentage of total system memory that contain dirty pages before the pages are written to disk. By setting DIRTY_PAGES to 80, the kernel is instructed to use 80 percent of the total system memory for dirty pages before flushing the data to disk. 

• VM.DIRTY_EXPIRE_CENTISECS is set to 500

The DIRTY_EXPIRE_CENTISECS define in centisecs (one hundredth of a second) when data is old enough to be written to disk. By setting DIRTY_EXPIRE_CENTISECS to 500, a dirty page can stay in memory for 500 centisecs before it is written to disk. 

• VM.DIRTY_WRITEBACK_CENTISECS is set to 100

The DIRTY_WRITEBACK_CENTISECS parameter defines the frequency the kernel will check to write dirty pages to disk. In this case, a value of 100 centisecs instructs the kernel to check every 100 centisecs to write dirty pages to disk. 

• VM.MAX_MAP_COUNT is set to 1600000

The MAX_MAP_COUNT defines the number of memory map areas a process may include. For example, databases use memory extensively which means increasing this value results in more available memory map areas for the database to use. 

In addition to the VM memory settings, this best practice also included network and kernel settings updated by the MSSQL tuned profile. The following list describes the network and kernel settings that were updated by the MSSQL tuned profile:  

• Net.core.rmem_default = 262144
• Net.core.rmem_max = 4194304
• Net.core.wmem_default = 262144
• Net.core.wmem_max = 1048576
• Kernel.numa_balancing = 0
• Kernel.sched_latency_ns = 60000000
• Kernel.sched_migration_cost_ns = 500000
• Kernel.sched_min_granularity_ns =15000000
• Kernel.sched_wakeup_granularity_ns = 2000000

Note: To maintain concice, no descriptions for these updates are included in this best practice. 

We performed additional tuning of the MSSQL configuration parameters to see if there was room for further optimization. The changes below yielded a slight performance improvement in the following metrics:

• INCLUDE set to THROUGHPUT-PERFORMANCE
• VM.DIRTY.RATIO set to 30
• VM. SWAPPINESS set to 1
• VM.DIRTY_BACKGROUND_RATIO set to 3
• NET.CORE.RMEM_DEFAULT set to 262144
• NET.CORE.RMEM_MAX set to 4194304
• NET.CORE.WMEM_DEFAULT set to 262144
• NET.COREWMEM_MAX set to 1048576

Recommendation

Using the TUNED_ADM tool to apply the TUNED-PROFILES-ORACLE package automates the application of many best practices in the Linux operating system. After applying the tuned oracle settings, we load tested the new configuration and compared it to the prior performance test. The load OLTP load test showed moderate performance improvements in the following metrics:

• New Orders per Minute (NOPM) 
• Transactions per Minute (TPM) 
• PowerMax IOPS
• Server CPU utilization
• Batch Requests Per Second (BRPS)

The TCP-C NOPM and TPM metrics produced a moderate performance increase, indicating the changes to the Linux operating system improved performance. PowerMax IOPS, overall CPU utilization, and SQL Server BRPS showed slight improvements.  

Overall, the configuration changes made to the Linux operating system fine tuned memory, network, and kernel configurations. These changes resulted in more efficient usage of system resources, providing moderate performance improvements. 

Implementation Steps

To update the tuned parameters and create a new file, navigate to /usr/lib/tuned and create a directory to store a new tuned.conf file. In our configuration, the parameters  captured below showed performance improvements

Once the file is created to enable this profile, execute the following commands:

#chmod +x /usr/lib/tuned/dellemc-amd/tuned.conf#tuned-adm profile dellemc-amd

Verify that it’s enabled using the following command:

# tuned-adm active

Additional Resources

Performance best practices and configuration guidelines for SQL Server on Linux 

In this best practice, the read-ahead Linux OS setting was changed to improve reads from storage. 

Overview

When the Linux operating system performs a read from disk, it reads additional data and this is referred to as read ahead. A benefit to reading additional data is the operating system improves performance if the data has relevance to what the application has requested. However, if the data has no relevance to what the application requested then reading the additional data could impact performance. Operating system administers can adjust the value of the read-ahead setting to optimize performance. For example, Microsoft recommends a read-ahead value of 4096 for SQL Server. The default read-ahead value was 8192 thus, in changing the value to 4096 the operating system will read half as much data.   

By changing the read-ahead value to 4096 our test results showed no performance gains. 

Recommendation

Changing the operating system to use a read-ahead value of 4096 had no impact on these performance metrics:

• New Orders per Minute (NOPM) 
• Transactions per Minute (TPM) 
• PowerMax IOPS
• Server CPU utilization
• Batch Requests per Second

Although our OLTP workload tests showed no performance improvements, this read-ahead best practice might be valuable for other databases. Thus, we are including the read-ahead recommendation as a Day 3, Fine Tuning recommendation. 

Implementation Steps

Use the blockdev command to view and edit the read-ahead value. To view the current read-ahead value for a particular block device, run:

blockdev --getra device

To modify the read-ahead value for that block device, run the following command. N represents the number of 512-byte sectors.

blockdev --setra N device

 References

Performance best practices and configuration guidelines for SQL Server on Linux

Red Hat Performance Turning Guide: File system performance tuning

 In this best practice the Linux OS was updated, not to record the access time on files. 

Overview

The Linux operating system tracks the last time a file was accessed, a timestamp referred to as atime. For example, when the Linux operating system reads data from a data file the access time is updated. Databases frequently access data files and updating the access time with each access represents an overhead on the operating system and storage system possibly impacting performance. 

It is possible to specify no-access-time (noatime), meaning the Linux operating system will not update the access time for files. The goal of this best practice was to reduce associated overhead and increase efficiency by setting the operating system to noatime.

The results of this best practice showed no performance improvements. 

Recommendation

Changing the operating system not to track last accessed time on database files showed no performance improvements for the following:

• New Orders per Minute (NOPM) 
• Transactions per Minute (TPM) 
• PowerMax IOPS.
• Server CPU utilization.
• Batch Requests per Second

The last accessed time recommendation has been a long-standing best practice that might have more value in the past. Still this best practice might have a greater impact on other database systems than our OLTP tests. For this reason, we recommend the read-ahead best practice as a Day 3, Fine Tuning consideration. 

Implementation Steps

To update the noatime mount option, navigate to /etc/fstab file. Within the file, update the entry for each device accessed by the SQL Server application. 

An example of this on the backup, data1 and data2 devices is shown below:

References 

Red Hat Performance Tuning Guide: File systems