Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Esta página fornece detalhes sobre como verificar o desempenho do volume.
Medir a performance do volume usando o Fio
Use a ferramenta de geração de E/S, Fio, para medir o desempenho
de referência.
Como usar o Fio
O Fio aplica uma carga de trabalho que pode ser especificada por uma interface de linha de comando ou
um arquivo de configuração. Durante a execução, o Fio mostra um indicador de progresso com a capacidade de processamento
atual e os números de entrada e saída por segundo (IOPS). Depois que ele terminar, um
resumo detalhado será exibido.
Exemplo de resultados do Fio
Os exemplos a seguir mostram um job de gravação aleatória de 4k com um único thread em execução por
60 segundos, que é uma maneira útil de medir a latência de referência. Nos comandos
a seguir, o parâmetro --directory aponta para uma pasta com um compartilhamento
do NetApp Volumes montado:
O exemplo anterior mostra uma média de 2.000 IOPS. Esse valor é
esperado para um job de linha de execução única com latência de 0,5 ms (IOPS = 1000 ms/0.5 ms = 2000).
A média de capacidade de processamento é 8.002 KiBps, que é o resultado esperado para 2.000
IOPS com um tamanho de bloco de 4 KiB (2000 1/s * 4 KiB = 8,000 KiB/s).
Medir a latência
A latência é uma métrica fundamental para a performance do volume. É o resultado dos recursos do cliente
e do servidor, da distância entre o cliente e o servidor (seu volume)
e do equipamento entre eles. O principal componente da métrica é a latência induzida
pela distância.
É possível fazer um ping no IP do seu volume para conferir o tempo de ida e volta, que é uma estimativa aproximada da latência.
A latência é afetada pelo tamanho do bloco e se você está fazendo operações de leitura ou
gravação. Recomendamos que você use os seguintes parâmetros para medir a
latência de referência entre o cliente e um volume:
Substitua os parâmetros rw (read/write/randread/randwrite) e bs (tamanho do bloco)
para ajustar sua carga de trabalho. Tamanhos de bloco maiores resultam em latência mais alta, em que as leituras
são mais rápidas que as gravações. Os resultados podem ser encontrados na linha lat.
Medir IOPS
As IOPS são um resultado direto da latência e da simultaneidade. Use uma das
seguintes guias com base no tipo de cliente para medir IOPS:
Substitua os parâmetros rw (read/write/randread/randwrite), bs (blocksize)
e iodepth (concorrência) para ajustar sua carga de trabalho. Os resultados podem ser encontrados na
linha iops.
Medir a capacidade de processamento
A capacidade é IOPS multiplicado pelo tamanho do bloco. Use uma das guias a seguir com base
no seu tipo de cliente para medir a taxa de transferência:
Substitua os parâmetros rw (read/write/randread/randwrite), bs (blocksize)
e iodepth (concorrência) para ajustar sua carga de trabalho. Só é possível alcançar um alto
throughput usando tamanhos de bloco de 64k ou maiores e alta simultaneidade.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["# Verify performance\n\nThis page provides details on how to verify volume performance.\n\nMeasure volume performance using Fio\n------------------------------------\n\nUse the I/O generator tool, [Fio](https://fio.readthedocs.io/en/latest/fio_doc.html), to measure baseline\nperformance.\n\nUsing Fio\n---------\n\nFio applies a workload which you can specify through a command line interface or\na configuration file. While it runs, Fio shows a progress indicator with current\nthroughput and input and output per second (IOPS) numbers. After it ends, a\ndetailed summary displays.\n\nFio results example\n-------------------\n\nThe following examples show a single-threaded, 4k random write job running for\n60 seconds, which is a useful way to measure baseline latency. In the following\ncommands, the `--directory` parameter points to a folder with a mounted\nNetApp Volumes share: \n\n $ FIO_COMMON_ARGS=--size=10g --fallocate=none --direct=1 --runtime=60 --time_based --ramp_time=5\n $ fio $FIO_COMMON_ARGS --directory=/netapp --ioengine=libaio --rw=randwrite --bs=4k --iodepth=1 --name=nv\n cvs: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1\n fio-3.28\n Starting 1 process\n cvs: Laying out IO file (1 file / 10240MiB)\n Jobs: 1 (f=1): [w(1)][100.0%][w=7856KiB/s][w=1964 IOPS][eta 00m:00s]\n cvs: (groupid=0, jobs=1): err= 0: pid=1891: Wed Dec 21 14:56:37 2022\n write: IOPS=1999, BW=7999KiB/s (8191kB/s)(469MiB/60001msec); 0 zone resets\n slat (usec): min=4, max=417, avg=12.06, stdev= 5.71\n clat (usec): min=366, max=27978, avg=483.59, stdev=91.34\n lat (usec): min=382, max=28001, avg=495.96, stdev=91.89\n clat percentiles (usec):\n | 1.00th=[ 408], 5.00th=[ 429], 10.00th=[ 437], 20.00th=[ 449],\n | 30.00th=[ 461], 40.00th=[ 469], 50.00th=[ 482], 60.00th=[ 490],\n | 70.00th=[ 498], 80.00th=[ 515], 90.00th=[ 529], 95.00th=[ 553],\n | 99.00th=[ 611], 99.50th=[ 652], 99.90th=[ 807], 99.95th=[ 873],\n | 99.99th=[ 1020]\n bw ( KiB/s): min= 7408, max= 8336, per=100.00%, avg=8002.05, stdev=140.09, samples=120\n iops : min= 1852, max= 2084, avg=2000.45, stdev=35.06, samples=120\n lat (usec) : 500=70.67%, 750=29.17%, 1000=0.15%\n lat (msec) : 2=0.01%, 4=0.01%, 50=0.01%\n cpu : usr=2.04%, sys=3.25%, ctx=120561, majf=0, minf=58\n IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, \u003e=64=0.0%\n submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, \u003e=64=0.0%\n complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, \u003e=64=0.0%\n issued rwts: total=0,119984,0,0 short=0,0,0,0 dropped=0,0,0,0\n latency : target=0, window=0, percentile=100.00%, depth=1\n\n Run status group 0 (all jobs):\n WRITE: bw=7999KiB/s (8191kB/s), 7999KiB/s-7999KiB/s (8191kB/s-8191kB/s), io=469MiB (491MB), run=60001-60001msec\n\nRead the following lines for details about the performance results:\n\n- **Latency** : `lat (usec): min=382, max=28001, avg=495.96, stdev=91.89`\n\n The average latency is 495.96 microseconds (usec), roughly 0.5 ms, which is\n an ideal latency.\n- **IOPS** : `min= 1852, max= 2084, avg=2000.45, stdev=35.06, samples=120`\n\n The preceding example shows an average of 2,000 IOPS. That value is\n expected for a single-threaded job with 0.5 ms latency (`IOPS = 1000 ms/0.5 ms = 2000`).\n- **Throughput** : `bw ( KiB/s): min= 7408, max=8336, per=100.00%, avg=8002.05, stdev=140.09`\n\n The throughput average is 8002 KiBps, which is the expected result for 2,000\n IOPS with a block size of 4 KiB (`2000 1/s * 4 KiB = 8,000 KiB/s`).\n\n### Measure latency\n\nLatency is a fundamental metric for volume performance. It's a result of client\nand server capabilities, the distance between client and server (your volume),\nand equipment in between. The main component of the metric is distance-induced\nlatency.\n\nYou can ping the IP of your volume to get the round-trip time, which is a rough\nestimate of your latency.\n\nLatency is affected by the block size and whether you are doing read or write\noperations. We recommend that you use the following parameters to measure the\nbaseline latency between your client and a volume: \n\n### Linux\n\n```bash\nfio --directory=/netapp \\\n --ioengine=libaio \\\n --rw=randwrite \\\n --bs=4k --iodepth=1 \\\n --size=10g \\\n --fallocate=none \\\n --direct=1 \\\n --runtime=60 \\\n --time_based \\\n --ramp_time=5 \\\n --name=latency\n```\n\n### Windows\n\n```bash\nfio --directory=Z\\:\\\n--ioengine=windowsaio\n--thread\n--rw=randwrite\n--bs=4k\n--iodepth=1\n--size=10g\n--fallocate=none\n--direct=1\n--runtime=60\n--time_based\n--ramp_time=5\n--name=latency\n```\n\nReplace the parameters `rw` (read/write/randread/randwrite) and `bs` (block size)\nto fit your workload. Larger block sizes result in higher latency, where reads\nare faster than writes. The results can be found in the `lat` row.\n\n### Measure IOPS\n\nIOPS are a direct result of the latency and concurrency. Use one of the\nfollowing tabs based on your client type to measure IOPS: \n\n### Linux\n\n```bash\nfio --directory=/netapp \\\n--ioengine=libaio \\\n--rw=randread \\\n--bs=4k \\\n--iodepth=32 \\\n--size=10g \\\n--fallocate=none \\\n--direct=1 \\\n--runtime=60 \\\n--time_based \\\n--ramp_time=5 \\\n--name=iops\n```\n\n### Windows\n\n```bash\nfio --directory=Z\\:\\\n--ioengine=windowsaio\n--thread\n--rw=randread\n--bs=4k\n--iodepth=32\n--size=10g\n--fallocate=none\n--direct=1\n--runtime=60\n--time_based\n--ramp_time=5\n--numjobs=16\n--name=iops\n```\n\nReplace the parameters `rw` (read/write/randread/randwrite), `bs` (blocksize),\nand `iodepth` (concurrency) to fit your workload. The results can be found in\nthe `iops` row.\n\n### Measure throughput\n\nThroughput is IOPS multiplied by blocksize. Use one of the following tabs based\non your client type to measure throughput: \n\n### Linux\n\n```bash\nfio --directory=/netapp \\\n--ioengine=libaio \\\n--rw=read \\\n--bs=64k \\\n--iodepth=32 \\\n--size=10g \\\n--fallocate=none \\\n--direct=1 \\\n--runtime=60 \\\n--time_based \\\n--ramp_time=5 \\\n--numjobs=16 \\\n--name=throughput\n```\n\n### Windows\n\n```bash\nfio --directory=Z\\:\\\n--ioengine=windowsaio\n--thread\n--rw=read\n--bs=64k\n--iodepth=32\n--size=10g\n--fallocate=none\n--direct=1\n--runtime=60\n--time_based\n--ramp_time=5\n--numjobs=16\n--name=throughput\n```\n\nReplace the parameters `rw` (read/write/randread/randwrite), `bs` (blocksize),\nand `iodepth` (concurrency) to fit your workload. You can only achieve high\nthroughput using block sizes 64k or larger and high concurrency.\n\nWhat's next\n-----------\n\nReview [performance benchmarks](/netapp/volumes/docs/performance/performance-benchmarks)."]]
