Performance Optimization: Difference between revisions

From HPCWIKI
Jump to navigation Jump to search
No edit summary
No edit summary
 
Line 1: Line 1:
== Fine-Tune Linux Kernel Parameters ==
[[Linux]] is known for its flexibility and ability to be customized, which allows system administrators to adjust its behavior to achieve top performance through fine-tune its kernel parameters.<ref>https://xitoring.com/kb/how-to-fine-tune-linux-kernel-parameters/</ref> in general, Real-time tuning for [[benchmark]] can be done using sysctl -w command and permanent change by editing /etc/sysctl.conf and sysctl -p
HPCMATE [[Manual:DLSSystem|DLS system]] provides pre-configured kernel level [[optimization]] and [[UCM|UCM (Universial Cluster Manager)]] provides real-time kernel level optimization via real-time system monitoring.
== TCP/IP Network Parameters ==
TCP/IP stack parameters in Linux offers powerful possibilities for improved network performance.
{| class="wikitable"
{| class="wikitable"
|+
|+
!Typical symptom
!Key parameter
!Possible  reason
!Description
!Solutions
!Recommendation
|-
|-
|sharply rising system CPU utilization. In addition, the page fault exception handler is <code>do_huge_pmd_anonymous_page</code>. This means that the current system doesn’t have 2 MB of contiguous physical memory and that triggers the direct memory compaction. The direct memory compaction is time-consuming, so it leads to high system CPU utilization
|'''ipv4.tcp_fin_timeout'''
|THP-caused performance fluctuation.
|This controls how long a connection stays in the “FIN-WAIT-2” state after it’s gracefully closed. Lowering this value (default: 60 seconds) can free up resources faster. particularly useful for servers handling lots of short connections
The fragmentation index is associated with the <code>/proc/sys/vm/extfrag_threshold</code> parameter. The closer the number is to 1,000, the more the allocation failure is related to memory fragmentation.
|<code>Recommended Value: 20-30 seconds</code>
|-
|'''ipv4.tcp_tw_reuse'''
|This allows the reuse of sockets in “TIME-WAIT” state. On busy servers, enabling this parameter helps manage high loads more efficiently by enabling quicker recycling of connections
|'''ipv4.tcp_tw_reuse:''' ''Recommended Value: 1 (Enable)''
|-
|'''ipv4.tcp_max_syn_backlog'''
|This value controls the maximum number of connection requests that the server can queue up while waiting for full three-way handshake completion. Increasing this value helps prevent dropping new connections when your server is under heavy load
|''Recommended Values: Start with doubling the default and adjust based on your server’s traffic load''
|}


To verify whether the performance fluctuation is related to memory fragmentation:
== File System Parameters ==
|Disable [[THP (Transparent Huge Pages)]]
It determines how data is stored, retrieved, and organized on your hard drives or SSDs.
 
'''Databases (Write-Heavy)''': A lower ''vm.dirty_background_ratio'' ensures writes are flushed frequently, reducing the potential for significant data loss in case of issues. A slightly increased ''vm.dirty_ratio'' might reduce stalls experienced by the database when large amounts of data need to be written quickly.
 
'''Web Servers (Read-Heavy)''': Here, you might increase ''vm.dirty_ratio'' to prioritize buffering read operations for greater speed, as losing some recent writes from users due to a crash is often less of a concern than having slow website loading times.
{| class="wikitable"
|+
!Key parameter
!Description
!Recommendation
|-
|-
|vm.dirty_background_ratio
|This parameter controls at what percentage of system memory “dirty” (modified but not yet written to disk) pages will trigger the system to start writing them to disk in the background.
* ''Impact'': Reducing this value makes the system more proactive in keeping the amount of dirty memory low, which can help in write-heavy scenarios like '''Databases.'''
* ''Caution'': Setting it too low can increase disk activity if writes happen faster than they can be flushed.
|
|
|-
|vm.dirty_ratio
|This determines the maximum percentage of system memory that can be filled with dirty pages before processes trying to write are forced to pause and flush data to disk themselves.
* Impact: Increasing this lets the system build up a larger write buffer, potentially making writes more efficient, but risks more data loss if there’s a crash.
* Trade-offs: There’s a balance between minimizing stalls on writes and ensuring you don’t lose too much data if your server suddenly shuts down.
|
|
|}
== Memory Management Parameters ==
Adjusting vm.swappiness` and `vm.overcommit_memory` parameters allows system administrators to fine-tune how the system uses RAM and swap space.
{| class="wikitable"
|+
!Key parameter
!Description
!Recommendation
|-
|'''vm.swappiness'''
|This parameter controls the kernel’s tendency to swap memory to disk. `vm.swappiness` can have a value between 0 and 100, where a lower value reduces the system’s use of swap, preferring to keep more data in RAM, and a higher value makes the system more inclined to use the swap space. For servers, a lower swappiness value is often preferred to ensure that applications remain in RAM for faster access, unless the system is running out of memory.
|
|
|-
|-
|
|'''vm.overcommit_memory'''
|
|This parameter controls the kernel’s policy towards memory overcommitment.
The setting can be 0 (heuristic overcommit handling), 1 (always overcommit), 2 (don’t overcommit).
The default setting (0) allows the kernel to estimate the amount of memory available and overcommit to a certain extent, which is suitable for most scenarios.
Setting it to 1 allows unlimited overcommitment of memory, which can be useful in environments where applications are expected to request more memory than they actually use. Setting 2 makes the kernel strict about memory allocation, which can prevent out-of-memory scenarios but might restrict application performance.
|
|
|}
|}
== Todo ==


== Reference ==
== Reference ==

Latest revision as of 13:50, 1 September 2024

Fine-Tune Linux Kernel Parameters

Linux is known for its flexibility and ability to be customized, which allows system administrators to adjust its behavior to achieve top performance through fine-tune its kernel parameters.[1] in general, Real-time tuning for benchmark can be done using sysctl -w command and permanent change by editing /etc/sysctl.conf and sysctl -p


HPCMATE DLS system provides pre-configured kernel level optimization and UCM (Universial Cluster Manager) provides real-time kernel level optimization via real-time system monitoring.

TCP/IP Network Parameters

TCP/IP stack parameters in Linux offers powerful possibilities for improved network performance.

Key parameter Description Recommendation
ipv4.tcp_fin_timeout This controls how long a connection stays in the “FIN-WAIT-2” state after it’s gracefully closed. Lowering this value (default: 60 seconds) can free up resources faster. particularly useful for servers handling lots of short connections Recommended Value: 20-30 seconds
ipv4.tcp_tw_reuse This allows the reuse of sockets in “TIME-WAIT” state. On busy servers, enabling this parameter helps manage high loads more efficiently by enabling quicker recycling of connections ipv4.tcp_tw_reuse: Recommended Value: 1 (Enable)
ipv4.tcp_max_syn_backlog This value controls the maximum number of connection requests that the server can queue up while waiting for full three-way handshake completion. Increasing this value helps prevent dropping new connections when your server is under heavy load Recommended Values: Start with doubling the default and adjust based on your server’s traffic load

File System Parameters

It determines how data is stored, retrieved, and organized on your hard drives or SSDs.

Databases (Write-Heavy): A lower vm.dirty_background_ratio ensures writes are flushed frequently, reducing the potential for significant data loss in case of issues. A slightly increased vm.dirty_ratio might reduce stalls experienced by the database when large amounts of data need to be written quickly.

Web Servers (Read-Heavy): Here, you might increase vm.dirty_ratio to prioritize buffering read operations for greater speed, as losing some recent writes from users due to a crash is often less of a concern than having slow website loading times.

Key parameter Description Recommendation
vm.dirty_background_ratio This parameter controls at what percentage of system memory “dirty” (modified but not yet written to disk) pages will trigger the system to start writing them to disk in the background.
  • Impact: Reducing this value makes the system more proactive in keeping the amount of dirty memory low, which can help in write-heavy scenarios like Databases.
  • Caution: Setting it too low can increase disk activity if writes happen faster than they can be flushed.
vm.dirty_ratio This determines the maximum percentage of system memory that can be filled with dirty pages before processes trying to write are forced to pause and flush data to disk themselves.
  • Impact: Increasing this lets the system build up a larger write buffer, potentially making writes more efficient, but risks more data loss if there’s a crash.
  • Trade-offs: There’s a balance between minimizing stalls on writes and ensuring you don’t lose too much data if your server suddenly shuts down.

Memory Management Parameters

Adjusting vm.swappiness` and `vm.overcommit_memory` parameters allows system administrators to fine-tune how the system uses RAM and swap space.

Key parameter Description Recommendation
vm.swappiness This parameter controls the kernel’s tendency to swap memory to disk. `vm.swappiness` can have a value between 0 and 100, where a lower value reduces the system’s use of swap, preferring to keep more data in RAM, and a higher value makes the system more inclined to use the swap space. For servers, a lower swappiness value is often preferred to ensure that applications remain in RAM for faster access, unless the system is running out of memory.
vm.overcommit_memory This parameter controls the kernel’s policy towards memory overcommitment.

The setting can be 0 (heuristic overcommit handling), 1 (always overcommit), 2 (don’t overcommit). The default setting (0) allows the kernel to estimate the amount of memory available and overcommit to a certain extent, which is suitable for most scenarios. Setting it to 1 allows unlimited overcommitment of memory, which can be useful in environments where applications are expected to request more memory than they actually use. Setting 2 makes the kernel strict about memory allocation, which can prevent out-of-memory scenarios but might restrict application performance.

Todo

Reference