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-23Lines changed: 27 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,12 +14,18 @@ ms.author: kendownie
14
14
This article explains how you can improve performance for network file system (NFS) Azure file shares.
15
15
16
16
## Applies to
17
-
18
-
| File share type | SMB | NFS |
19
-
|-|:-:|:-:|
20
-
| Standard file shares (GPv2), LRS/ZRS |||
21
-
| Standard file shares (GPv2), GRS/GZRS |||
22
-
| Premium file shares (FileStorage), LRS/ZRS |||
17
+
| Management model | Billing model | Media tier | Redundancy | SMB | NFS |
## Increase read-ahead size to improve read throughput
25
31
@@ -46,13 +52,12 @@ To change this value, set the read-ahead size by adding a rule in udev, a Linux
46
52
sudo udevadm control --reload
47
53
```
48
54
49
-
## `Nconnect`
50
-
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.
55
+
## NFS nconnect
56
+
NFS nconnect is a client-side mount option for NFS file shares that allows you to use multiple TCP connections between the client and your NFS file share.
52
57
53
-
### Benefits of `nconnect`
58
+
### Benefits
54
59
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.
60
+
With nconnect, you can increase performance at scale using fewer client machines to reduce total cost of ownership (TCO). The nconnect feature 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 SSD 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.
@@ -63,24 +68,23 @@ With `nconnect`, you can increase performance at scale using fewer client machin
63
68
64
69
### Prerequisites
65
70
66
-
- The latest Linux distributions fully support `nconnect`. For older Linux distributions, ensure that the Linux kernel version is 5.3 or higher.
71
+
- The latest Linux distributions fully support nconnect. For older Linux distributions, ensure that the Linux kernel version is 5.3 or higher.
67
72
- Per-mount configuration is only supported when a single file share is used per storage account over a private endpoint.
68
73
69
-
### Performance impact of `nconnect`
74
+
### Performance impact
70
75
71
-
We achieved the following performance results when using the `nconnect` mount option with NFS Azure file shares on Linux clients at scale. For more information on how we achieved these results, see [performance test configuration](#performance-test-configuration).
76
+
We achieved the following performance results when using the nconnect mount option with NFS Azure file shares on Linux clients at scale. For more information on how we achieved these results, see [performance test configuration](#performance-test-configuration).
72
77
73
78
:::image type="content" source="media/nfs-performance/nconnect-iops-improvement.png" alt-text="Screenshot showing average improvement in IOPS when using nconnect with NFS Azure file shares." border="false":::
74
79
75
80
:::image type="content" source="media/nfs-performance/nconnect-throughput-improvement.png" alt-text="Screenshot showing average improvement in throughput when using nconnect with NFS Azure file shares." border="false":::
76
81
77
-
### Recommendations for `nconnect`
78
-
82
+
### Recommendations
79
83
Follow these recommendations to get the best results from `nconnect`.
80
84
81
85
#### Set `nconnect=4`
82
86
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.
87
+
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.
84
88
85
89
#### Size virtual machines carefully
86
90
@@ -90,18 +94,18 @@ Depending on your workload requirements, it's important to correctly size the cl
90
94
91
95
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
96
93
-
### `Nconnect` per-mount configuration
97
+
### Per mount configuration
94
98
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.
99
+
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.
96
100
97
-
#### Scenario 1: `nconnect`per-mount configuration over private endpoint with multiple storage accounts (supported)
101
+
#### Scenario 1: permount configuration over private endpoint with multiple storage accounts (supported)
@@ -112,7 +116,7 @@ If a workload requires mounting multiple shares with one or more storage account
112
116
> [!NOTE]
113
117
> 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.
114
118
115
-
#### Scenario 3: `nconnect`per-mount configuration over private endpoint with multiple shares on single storage account (not supported)
119
+
#### Scenario 3: permount configuration over private endpoint with multiple shares on single storage account (not supported)
0 commit comments