You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/storage/files/nfs-performance.md
+27-20Lines changed: 27 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,20 @@
1
1
---
2
2
title: Improve NFS Azure file share performance
3
-
description: Learn ways to improve the performance of NFS Azure file shares at scale, including the nconnect mount option for Linux clients.
3
+
description: Learn ways to improve the performance and throughput of NFS Azure file shares at scale, including the nconnect mount option for Linux clients.
4
4
author: khdownie
5
5
ms.service: azure-file-storage
6
6
ms.custom: linux-related-content
7
7
ms.topic: conceptual
8
-
ms.date: 09/26/2023
8
+
ms.date: 05/09/2024
9
9
ms.author: kendownie
10
10
---
11
11
12
-
# Improve NFS Azure file share performance
13
-
This article explains how you can improve performance for NFS Azure file shares.
12
+
# Improve performance for NFS Azure file shares
13
+
14
+
This article explains how you can improve performance for network file system (NFS) Azure file shares.
14
15
15
16
## Applies to
17
+
16
18
| File share type | SMB | NFS |
17
19
|-|:-:|:-:|
18
20
| Standard file shares (GPv2), LRS/ZRS |||
@@ -21,9 +23,9 @@ This article explains how you can improve performance for NFS Azure file shares.
21
23
22
24
## Increase read-ahead size to improve read throughput
23
25
24
-
The `read_ahead_kb` kernel parameter in Linux represents the amount of data that should be "read ahead" or prefetched during a sequential read operation. Linux kernel versions prior to 5.4 set the read-ahead value to the equivalent of 15 times the mounted file system's `rsize` (the client-side mount option for read buffer size). This sets the read-ahead value high enough to improve client sequential read throughput in most cases.
26
+
The `read_ahead_kb` kernel parameter in Linux represents the amount of data that should be "read ahead" or prefetched during a sequential read operation. Linux kernel versions before 5.4 set the read-ahead value to the equivalent of 15 times the mounted file system's `rsize`, which represents the client-side mount option for read buffer size. This sets the read-ahead value high enough to improve client sequential read throughput in most cases.
25
27
26
-
However, beginning with Linux kernel version 5.4, the Linux NFS client uses a default `read_ahead_kb` value of 128 KiB. This small value might reduce the amount of read throughput for large files. Customers upgrading from Linux releases with the larger read-ahead value to those with the 128 KiB default might experience a decrease in sequential read performance.
28
+
However, beginning with Linux kernel version 5.4, the Linux NFS client uses a default `read_ahead_kb` value of 128 KiB. This small value might reduce the amount of read throughput for large files. Customers upgrading from Linux releases with the larger read-ahead value to releases with the 128 KiB default might experience a decrease in sequential read performance.
27
29
28
30
For Linux kernels 5.4 or later, we recommend persistently setting the `read_ahead_kb` to 15 MiB for improved performance.
29
31
@@ -46,11 +48,11 @@ To change this value, set the read-ahead size by adding a rule in udev, a Linux
46
48
47
49
## `Nconnect`
48
50
49
-
`Nconnect` is a client-side Linux mount option that increases performance at scale by allowing you to use more TCP connections between the client and the Azure Premium Files service for NFSv4.1, while maintaining the resiliency of platform as a service (PaaS).
51
+
`Nconnect` is a client-side Linux mount option that increases performance at scale by allowing you to use more Transmission Control Protocol (TCP) connections between the client and the Azure Premium Files service for NFSv4.1.
50
52
51
53
### Benefits of `nconnect`
52
54
53
-
With `nconnect`, you can increase performance at scale using fewer client machines to reduce total cost of ownership (TCO). `Nconnect` increases performance by using multiple TCP channels on one or more NICs, using single or multiple clients. Without `nconnect`, you'd need roughly 20 client machines in order to achieve the bandwidth scale limits (10 GiB/s) offered by the largest premium Azure file share provisioning size. With `nconnect`, you can achieve those limits using only 6-7 clients. That’s almost a 70% reduction in computing cost, while providing significant improvements to IOPS and throughput at scale (see table).
55
+
With `nconnect`, you can increase performance at scale using fewer client machines to reduce total cost of ownership (TCO). `Nconnect` increases performance by using multiple TCP channels on one or more NICs, using single or multiple clients. Without `nconnect`, you'd need roughly 20 client machines in order to achieve the bandwidth scale limits (10 GiB/s) offered by the largest premium Azure file share provisioning size. With `nconnect`, you can achieve those limits using only 6-7 clients, reducing compute costs by nearly 70% while providing significant improvements in I/O operations per second (IOPS) and throughput at scale. See the following table.
@@ -77,25 +79,29 @@ We achieved the following performance results when using the `nconnect` mount op
77
79
Follow these recommendations to get the best results from `nconnect`.
78
80
79
81
#### Set `nconnect=4`
82
+
80
83
While Azure Files supports setting `nconnect` up to the maximum setting of 16, we recommend configuring the mount options with the optimal setting of `nconnect=4`. Currently, there are no gains beyond four channels for the Azure Files implementation of `nconnect`. In fact, exceeding four channels to a single Azure file share from a single client might adversely affect performance due to TCP network saturation.
81
84
82
85
#### Size virtual machines carefully
83
-
Depending on your workload requirements, it’s important to correctly size the client machines to avoid being restricted by their [expected network bandwidth](../../virtual-network/virtual-machine-network-throughput.md#expected-network-throughput). You don't need multiple NICs in order to achieve the expected network throughput. While it's common to use [general purpose VMs](../../virtual-machines/sizes-general.md) with Azure Files, various VM types are available depending on your workload needs and region availability. For more information, see [Azure VM Selector](https://azure.microsoft.com/pricing/vm-selector/).
84
86
85
-
#### Keep queue depth less than or equal to 64
86
-
Queue depth is the number of pending I/O requests that a storage resource can service. We don't recommend exceeding the optimal queue depth of 64. If you do, you won't see any more performance gains. For more information, see [Queue depth](understand-performance.md#queue-depth).
87
+
Depending on your workload requirements, it’s important to correctly size the client virtual machines (VMs) to avoid being restricted by their [expected network bandwidth](../../virtual-network/virtual-machine-network-throughput.md#expected-network-throughput). You don't need multiple network interface controllers (NICs) in order to achieve the expected network throughput. While it's common to use [general purpose VMs](../../virtual-machines/sizes-general.md) with Azure Files, various VM types are available depending on your workload needs and region availability. For more information, see [Azure VM Selector](https://azure.microsoft.com/pricing/vm-selector/).
88
+
89
+
#### Keep queue depth less than or equal to 64
90
+
91
+
Queue depth is the number of pending I/O requests that a storage resource can service. We don't recommend exceeding the optimal queue depth of 64 because you won't see any more performance gains. For more information, see [Queue depth](understand-performance.md#queue-depth).
92
+
93
+
### `Nconnect` per-mount configuration
87
94
88
-
### `Nconnect` per-mount configuration
89
95
If a workload requires mounting multiple shares with one or more storage accounts with different `nconnect` settings from a single client, we can't guarantee that those settings will persist when mounting over the public endpoint. Per-mount configuration is only supported when a single Azure file share is used per storage account over the private endpoint as described in Scenario 1.
90
96
91
-
#### Scenario 1: (supported) `nconnect` per-mount configuration over private endpoint with multiple storage accounts
97
+
#### Scenario 1: `nconnect` per-mount configuration over private endpoint with multiple storage accounts (supported)
@@ -106,7 +112,7 @@ If a workload requires mounting multiple shares with one or more storage account
106
112
> [!NOTE]
107
113
> Even if the storage account resolves to a different IP address, we can't guarantee that address will persist because public endpoints aren't static addresses.
108
114
109
-
#### Scenario 3: (not supported) `nconnect` per-mount configuration over private endpoint with multiple shares on single storage account
115
+
#### Scenario 3: `nconnect` per-mount configuration over private endpoint with multiple shares on single storage account (not supported)
@@ -194,11 +200,12 @@ When using the `nconnect` mount option, you should closely evaluate workloads th
194
200
- Latency sensitive write workloads that are single threaded and/or use a low queue depth (less than 16)
195
201
- Latency sensitive read workloads that are single threaded and/or use a low queue depth in combination with smaller I/O sizes
196
202
197
-
Not all workloads require high-scale IOPS or throughout performance. For smaller scale workloads, `nconnect` might not make sense. Use the following table to decide whether `nconnect`will be advantageous for your workload. Scenarios highlighted in green are recommended, while those highlighted in red are not. Those highlighted in yellow are neutral.
203
+
Not all workloads require high-scale IOPS or throughout performance. For smaller scale workloads, `nconnect` might not make sense. Use the following table to decide whether `nconnect`is advantageous for your workload. Scenarios highlighted in green are recommended, while scenarios highlighted in red aren't. Scenarios highlighted in yellow are neutral.
198
204
199
205
:::image type="content" source="media/nfs-performance/nconnect-latency-comparison.png" alt-text="Screenshot showing various read and write I O scenarios with corresponding latency to indicate when nconnect is advisable." border="false":::
200
206
201
207
## See also
202
-
- For mounting instructions, see [Mount NFS file Share to Linux](storage-files-how-to-mount-nfs-shares.md).
203
-
- For a comprehensive list of mount options, see [Linux NFS man page](https://linux.die.net/man/5/nfs).
204
-
- For information on latency, IOPS, throughput, and other performance concepts, see [Understand Azure Files performance](understand-performance.md).
208
+
209
+
-[Mount NFS file Share to Linux](storage-files-how-to-mount-nfs-shares.md)
210
+
-[List of mount options](https://linux.die.net/man/5/nfs)
![prmerger-automator[bot]](https://avatars.githubusercontent.com/u/22479449?v=4&size=40){kind=avatar}
0 commit comments