Read performance issue with Azure NetApp Files

Question

Read performance issue with Azure NetApp Files

Gerald Monard 5

I have different HPC clusters. On one of them I see read performance issue on all my NetApp Files NFS mounts.

Here is an example of ior results:

access    bw(MiB/s)  IOPS       Latency(s)  block(KiB) xfer(KiB)  open(s)    wr/rd(s)   close(s)   total(s)   iter
------    ---------  ----       ----------  ---------- ---------  --------   --------   --------   --------   ----
write     1366.11    87573      0.000045    4194304    16.00      0.017390   11.97      0.002041   11.99      0
read      405.06     25926      0.000150    4194304    16.00      0.003591   40.45      0.000009   40.45      0
write     1301.43    83405      0.000048    4194304    16.00      0.014975   12.57      0.002138   12.59      1
read      399.86     25594      0.000002    4194304    16.00      0.004152   40.97      0.000010   40.97      1
write     1396.16    89450      0.000045    4194304    16.00      0.011210   11.72      0.001402   11.74      2
read      26258      1692193    0.000002    4194304    16.00      0.004289   0.619655   0.000007   0.623956   2

The max throughput is supposed to be 3200 MiB/s for that volume. I have 405 then 26258. I have run difference benchmarks, changing the chunk size (4MiB, 16 kiB), the total block size (4 Gib, 16 GiB), the number of threads, etc. Always the same issue, the write performance is fine, the read performance is random.

I have two other clusters in a different subscription, using the same benchmark parameters, all is fine.

Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-05-05T20:22:51.5066667+00:00
Hi @ Gerald Monard,

Welcome to Microsoft Q&A Platform.

As stated in What should I do to optimize or tune Azure NetApp Files performance?

There are many things that can impact performance outside of Azure NetApp Files. Examples of outside factors are VM SKU size, Network bottlenecks, and Linux configuration.

You can take the following actions per the performance requirements:

Ensure the virtual machine (VM) is sized appropriately.

Enable Accelerated Networking for the VM.

Select the desired service level and size for the capacity pool.

Create a volume with the desired quota size for the capacity and performance.

There is no need to set accelerated networking for the network interface cards (NICs) in the dedicated subnet of Azure NetApp Files. Accelerated networking is a capability that only applies to Azure VMs. Azure NetApp Files NICs are optimized by design.

Tune Linux NFS mount options: Enable nconnect (e.g., mount -o nconnect=4) to spread I/O over multiple TCP connections.

Cap rsize/wsize to 256 KiB or 1 MiB—don’t let defaults grow too large.

Check RPC slot usage: Linux defaults to 65,536 slots but ANF only supports 128 concurrent operations. If you flood more, reads can stall.

Reference

ANF Performance Calculator : https://bluexp.netapp.com/azure-netapp-files/sizer

https://docs.microsoft.com/azure/azure-netapp-files/azure-netapp-files-performance-considerations

https://learn.microsoft.com/azure/azure-netapp-files/performance-linux-mount-options
https://learn.microsoft.com/azure/azure-netapp-files/performance-linux-concurrency-session-slots

Please "upvote" if the information helped you. This will help us and others in the community as well.
Gerald Monard 5 Reputation points

2026-05-05T20:32:54.1366667+00:00

I have tried several VMs size.

rsize/wsize are capped at 256 KiB

nconnect=8

Accelerated networking is enabled.

I am using AlmaLinux HPC 9. On my other clusters that don't have this issue, I am using AlmaLinux 8 HPC. Could it be the reason?
Gerald Monard 5 Reputation points

2026-05-05T23:01:10.7266667+00:00

I played with the RPC slot usage (sunrpc.tcp_max_slots_table_entries=128, then sysctl -p, then remount).
No better luck.
How can I troubleshoot the issue?
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-05-06T01:16:12.2766667+00:00

Hi @ Gerald Monard,

Azure NetApp Files metrics include “Other IOPS,” which represents metadata operations such as LOOKUP, GETATTR, and ACCESS.

Read operations typically involve multiple metadata calls in addition to data transfer. If metadata operations increase significantly, they can impact read throughput.

Differences in Linux distributions (e.g., AlmaLinux 8 vs AlmaLinux 9) can result in different NFS client behavior, including increased metadata requests.

Please monitor “Other IOPS” in Azure NetApp Files metrics by following Ways to access metrics

About storage performance operation metrics

Please "upvote" if the information helped you. This will help us and others in the community as well.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-05-21T15:07:59.3+00:00

Hi @ Gerald Monard,

I see Vallepu has Addressed your queries.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-05-26T10:17:35.17+00:00

Hi @ Gerald Monard,

I see Vallepu has Addressed your queries.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

2 answers

Your answer

Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-05-05T20:22:51.5066667+00:00

Hi @ Gerald Monard,

Welcome to Microsoft Q&A Platform.

As stated in What should I do to optimize or tune Azure NetApp Files performance?

There are many things that can impact performance outside of Azure NetApp Files. Examples of outside factors are VM SKU size, Network bottlenecks, and Linux configuration.

You can take the following actions per the performance requirements:

Ensure the virtual machine (VM) is sized appropriately.

Enable Accelerated Networking for the VM.

Select the desired service level and size for the capacity pool.

Create a volume with the desired quota size for the capacity and performance.

There is no need to set accelerated networking for the network interface cards (NICs) in the dedicated subnet of Azure NetApp Files. Accelerated networking is a capability that only applies to Azure VMs. Azure NetApp Files NICs are optimized by design.

Tune Linux NFS mount options: Enable nconnect (e.g., mount -o nconnect=4) to spread I/O over multiple TCP connections.

Cap rsize/wsize to 256 KiB or 1 MiB—don’t let defaults grow too large.

Check RPC slot usage: Linux defaults to 65,536 slots but ANF only supports 128 concurrent operations. If you flood more, reads can stall.

Reference

ANF Performance Calculator : https://bluexp.netapp.com/azure-netapp-files/sizer

https://docs.microsoft.com/azure/azure-netapp-files/azure-netapp-files-performance-considerations

https://learn.microsoft.com/azure/azure-netapp-files/performance-linux-mount-options
https://learn.microsoft.com/azure/azure-netapp-files/performance-linux-concurrency-session-slots

Please "upvote" if the information helped you. This will help us and others in the community as well.
Gerald Monard 5 Reputation points

2026-05-05T20:32:54.1366667+00:00

I have tried several VMs size.

rsize/wsize are capped at 256 KiB

nconnect=8

Accelerated networking is enabled.

I am using AlmaLinux HPC 9. On my other clusters that don't have this issue, I am using AlmaLinux 8 HPC. Could it be the reason?
Gerald Monard 5 Reputation points

2026-05-05T23:01:10.7266667+00:00

I played with the RPC slot usage (sunrpc.tcp_max_slots_table_entries=128, then sysctl -p, then remount).
No better luck.
How can I troubleshoot the issue?
Vallepu Venkateswarlu 10,590 Reputation points Microsoft External Staff Moderator

2026-05-06T01:16:12.2766667+00:00

Hi @ Gerald Monard,

Azure NetApp Files metrics include “Other IOPS,” which represents metadata operations such as LOOKUP, GETATTR, and ACCESS.

Read operations typically involve multiple metadata calls in addition to data transfer. If metadata operations increase significantly, they can impact read throughput.

Differences in Linux distributions (e.g., AlmaLinux 8 vs AlmaLinux 9) can result in different NFS client behavior, including increased metadata requests.

Please monitor “Other IOPS” in Azure NetApp Files metrics by following Ways to access metrics

About storage performance operation metrics

Please "upvote" if the information helped you. This will help us and others in the community as well.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-05-21T15:07:59.3+00:00

Hi @ Gerald Monard,

I see Vallepu has Addressed your queries.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.
Ganesh Patapati 12,170 Reputation points Microsoft External Staff Moderator

2026-05-26T10:17:35.17+00:00

Hi @ Gerald Monard,

I see Vallepu has Addressed your queries.

Can you please update us if the action plan provided was helpful?

Should there be any follow-up questions or concerns, please let us know and we shall try to address them.

Answer 1

Gerald Monard 5

I have talked with (other) people from NetApp.

After some exchanges, here is what we agreed on:

write is faster than read because NetApp's write is cached on its side. That can explain why we reach max throughput quickly for write
read performance on 1-4 threads because that's the performance from NetApp without caching on either side.

0 comments

Answer 2

Hello,
Thanks for your replies @Vallepu Venkateswarlu and @Ganesh Patapati .
Update(s) on my side:

I have redone the benchmarks making sure that I really flush the cache between each read or write measurement.

The results are even more disappointing:

  | Operation | Chunk Size | Block size | Threads | Threads per node | Bandwidth (MiB) | % Max bw |
  | --------- | ---------- | ---------- | ------- | ---------------- | --------------- | -------- |
  | read | 16 kiB | 4 GiB |   1 |   1 |  112.46 | 3.51 % |
  | read | 16 kiB | 4 GiB |   4 |   4 |  422.73 | 13.21 % |
  | read | 16 kiB | 4 GiB |   8 |   8 |  836.36 | 26.14 % |
  | read | 16 kiB | 4 GiB |  16 |  16 | 1645.12 | 51.41 % |
  | read | 16 kiB | 4 GiB |  32 |  32 | 2926.80 | 91.46 % |
  | read | 16 kiB | 4 GiB |  60 |  60 | 3178.82 | 99.34 % |
  | read | 16 kiB | 4 GiB | 120 | 120 | 3122.06 | 97.56 % |

  | Operation | Chunk Size | Block size | Threads | Threads per node | Bandwidth (MiB) | % Max bw |
  | --------- | ---------- | ---------- | ------- | ---------------- | --------------- | -------- |
  | write | 16 kiB | 4 GiB |   1 |   1 |  975.73 | 30.49 % |
  | write | 16 kiB | 4 GiB |   4 |   4 | 1808.07 | 56.50 % |
  | write | 16 kiB | 4 GiB |   8 |   8 | 2114.65 | 66.08 % |
  | write | 16 kiB | 4 GiB |  16 |  16 | 2465.93 | 77.06 % |
  | write | 16 kiB | 4 GiB |  32 |  32 | 2670.59 | 83.46 % |
  | write | 16 kiB | 4 GiB |  60 |  60 | 2280.56 | 71.27 % |
  | write | 16 kiB | 4 GiB | 120 | 120 | 2494.36 | 77.95 % |