Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini memberikan detail tentang cara mengoptimalkan performa Google Cloud NetApp Volumes.
Sebelum memulai
Sebelum Anda membuat perubahan pada volume untuk mengoptimalkan performa, tinjau
pertimbangan performa.
Menyesuaikan setelan volume
Anda dapat mengoptimalkan performa dengan menyesuaikan setelan volume berikut:
Meningkatkan kapasitas volume: Anda dapat meningkatkan kapasitas volume tingkat layanan Premium, Extreme, atau Standar untuk meningkatkan throughput volume maksimum yang dapat dicapai. Untuk volume tingkat layanan Flex, tingkatkan kapasitas penyimpanan
gabungan.
Upgrade tingkat layanan: Anda dapat mengupgrade volume tingkat layanan Premium
ke tingkat layanan Extreme untuk meningkatkan throughput. Sebaiknya
tentukan volume ke kumpulan penyimpanan yang berbeda dengan level layanan
yang berbeda.
Meningkatkan kapasitas volume dan mengupgrade tingkat layanan tidak mengganggu
workload I/O yang sedang diproses di volume dan tidak memengaruhi akses ke volume
dengan cara apa pun.
Menyesuaikan klien
Anda dapat meningkatkan performa dengan menyesuaikan setelan berikut di klien:
Klien yang berlokasi bersama: hasil latensi secara langsung terpengaruh oleh
kemampuan dan lokasi klien. Untuk hasil terbaik, tempatkan klien
di region yang sama dengan volume atau sedekat mungkin. Uji dampak zona
dengan menguji latensi dari klien di setiap zona dan gunakan zona dengan
latensi terendah.
Mengonfigurasi bandwidth jaringan Compute Engine: kemampuan jaringan VM Compute Engine bergantung pada jenis instance yang digunakan. Biasanya,
instance yang lebih besar dapat mendorong throughput jaringan yang lebih besar. Sebaiknya Anda
memilih virtual machine klien dengan kemampuan bandwidth jaringan
yang sesuai, memilih antarmuka jaringan Google Virtual NIC (gVNIC), dan
mengaktifkan performa Tier_1. Untuk informasi selengkapnya, lihat dokumentasi Compute Engine
tentang bandwidth jaringan.
Membuka beberapa sesi TCP: jika aplikasi Anda memerlukan throughput tinggi,
Anda pada akhirnya dapat memenuhi satu sesi transmission control protocol (TCP)
yang mendasari sesi NFS dan SMB normal. Untuk kasus tersebut, tingkatkan
jumlah sesi TCP yang digunakan koneksi NFS dan SMB Anda.
Gunakan salah satu tab berikut untuk menyesuaikan klien berdasarkan jenis
klien:
Linux
Secara tradisional, klien NFS menggunakan satu sesi TCP untuk semua sistem file yang dipasang NFS yang berbagi endpoint penyimpanan. Dengan menggunakan
opsi pemasangan nconnect,
Anda dapat meningkatkan jumlah sesi TCP yang didukung hingga maksimum
16.
Sebaiknya lakukan praktik terbaik berikut untuk menyesuaikan jenis klien Linux
Anda agar dapat memanfaatkan nconnect sepenuhnya:
Meningkatkan jumlah sesi TCP dengan nconnect: Setiap sesi TCP tambahan akan menambahkan antrean untuk 128 permintaan yang belum selesai, sehingga meningkatkan potensi konkurensi.
Menetapkan parameter sunrpc.max_tcp_slot_table_entries:
sunrpc.max_tcp_slot_table_entries adalah parameter penyesuaian tingkat koneksi
yang dapat Anda ubah untuk mengontrol performa. Sebaiknya
tetapkan sunrpc.max_tpc_slot_table_enteries ke 128 permintaan atau per
koneksi dan jangan melebihi 10.000 slot untuk semua klien NFS dalam
satu project yang terhubung ke Volume NetApp. Untuk menetapkan parameter sunrpc.max_tcp_slot_table_entries, tambahkan parameter ke file /etc/sysctl.conf dan muat ulang file parameter menggunakan perintah sysctl -p.
Menyesuaikan nilai maksimum yang didukung per sesi menjadi 180: Tidak seperti NFSv3,
klien NFSv4.1 menentukan hubungan antara klien dan server
dalam sesi. Meskipun Volume NetApp mendukung hingga 128
permintaan yang tertunda per koneksi menggunakan NFSv3, NFSv4.1 dibatasi hingga
180 permintaan yang tertunda per sesi. Klien NFSv4.1 Linux secara default menggunakan
64 max_session_slots per sesi, tetapi Anda dapat menyesuaikan nilai ini
sesuai kebutuhan. Sebaiknya ubah nilai maksimum yang didukung per sesi
menjadi 180.
Untuk menyesuaikan max_session_slots, buat file konfigurasi di bagian
/etc/modprobe.d. Pastikan tidak ada tanda petik (" ") yang muncul
inline. Jika tidak, opsi tidak akan diterapkan.
Grafik perbandingan nconnect NFS berikut menunjukkan dampak
penggunaan konfigurasi nconnect terhadap beban kerja NFS. Informasi
ini diambil menggunakan Fio dengan setelan berikut:
Beban kerja baca 100%
Ukuran blok 8 KiB terhadap satu volume
Virtual machine n2-standard-32 menggunakan OS Red Hat 9
Set kerja 6 TiB
Menggunakan nilai nconnect 16 menghasilkan performa yang lima kali lebih baik
daripada saat tidak diaktifkan.
Windows
Untuk klien berbasis Windows, klien dapat menggunakan SMB Multichannel
dengan Receive Side Scaling (RSS) untuk membuka beberapa koneksi TCP. Untuk
mencapai konfigurasi ini, virtual machine Anda harus memiliki adaptor jaringan
yang dialokasikan dan mendukung RSS. Sebaiknya tetapkan RSS ke empat atau delapan nilai, tetapi nilai apa pun yang lebih dari satu akan meningkatkan throughput.
Grafik berikut menampilkan perbedaan yang dapat dihasilkan oleh konfigurasi RSS
pada beban kerja SMB. Informasi ini diambil menggunakan Fio dengan
setelan berikut:
Beban kerja baca 100%
Ukuran blok 8 KiB terhadap satu volume
Satu virtual machine n2-standard-32 yang menjalankan OS Windows 2022
Set kerja 6 TiB
Delapan tugas dijalankan hanya dengan opsi RSS klien SMB yang berubah di antara
eksekusi pengujian. Menggunakan nilai RSS 4, 8, dan 16 meningkatkan performa
dua kali lipat jika dibandingkan dengan menggunakan nilai 1. Setiap instance RSS dijalankan sembilan kali dengan parameter numjobs 8. Parameter iodepth
ditingkatkan sebanyak lima kali setiap eksekusi hingga throughput maksimum tercapai.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["# Optimize performance\n\nThis page provides details on how you can optimize Google Cloud NetApp Volumes\nperformance.\n\nBefore you begin\n----------------\n\nBefore you make changes to your volumes to optimize performance, review\n[performance considerations](/netapp/volumes/docs/performance/performance-considerations).\n\nAdjust volume settings\n----------------------\n\nYou can optimize performance by adjusting the following volume settings:\n\n- **Increase volume capacity**: You can increase the capacity of your Premium,\n Extreme or Standard service level volume to improve maximum achievable volume\n throughput. For volumes of Flex service level, increase storage pools capacity\n instead.\n\n- **Upgrade your service level**: You can upgrade your Premium service level\n volumes to the Extreme service level to improve throughput. We recommend that\n you assign the volume to a different storage pool with a different service\n level.\n\nIncreasing volume capacity and upgrading service levels are both non-disruptive\nto I/O workloads in process on the volume and don't affect access to the volume\nin any way.\n\nAdjust the client\n-----------------\n\nYou can improve performance by adjusting the following settings on the client:\n\n- **Co-locate clients**: latency results are directly impacted by the\n capabilities and location of the client. For best results, place the client\n in the same region as the volume or as close as possible. Test the zonal\n impact by testing latency from a client in each zone and use the zone with\n the lowest latency.\n\n- **Configure Compute Engine network bandwidth** : the network capabilities of\n Compute Engine virtual machines depend on the instance type used. Typically,\n larger instances can drive more network throughput. We recommend that you\n select a client virtual machine with an appropriate network bandwidth\n capability, select the Google Virtual NIC (gVNIC) network interface and\n enable `Tier_1` performance. For more information, see Compute Engine\n documentation on [network bandwidth](/compute/docs/network-bandwidth).\n\n- **Open multiple TCP sessions**: if your application requires high throughput,\n you can eventually saturate the single transmission control protocol (TCP)\n session that underlies a normal NFS and SMB session. For such cases, increase\n the number of TCP sessions your NFS and SMB connection uses.\n\n Use one of the following tabs to adjust your client based on the type of\n client: \n\n ### Linux\n\n Traditionally, an NFS client uses a single TCP session for all\n NFS-mounted file systems that share a storage endpoint. Using the\n [`nconnect` mount option](https://man7.org/linux/man-pages/man5/nfs.5.html)\n lets you increase the number of supported TCP sessions up to a maximum\n of 16.\n\n We recommend the following best practices for adjusting your Linux client\n type to fully take advantage of `nconnect`:\n - **Increase the number of TCP sessions with `nconnect`**: Each\n additional TCP session adds a queue for 128 outstanding requests,\n improving potential concurrency.\n\n - **Set `sunrpc.max_tcp_slot_table_entries` parameter** :\n `sunrpc.max_tcp_slot_table_entries` is a connection-level adjustment\n parameter which you can modify to control performance. We recommend\n setting `sunrpc.max_tpc_slot_table_enteries` to 128 requests or per\n connection and not surpassing 10,000 slots for all NFS clients within\n a single project connecting to NetApp Volumes. To set the\n `sunrpc.max_tcp_slot_table_entries` parameter, add the parameter to\n your `/etc/sysctl.conf` file and reload the parameter file using the\n `sysctl -p` command.\n\n - **Tune maximum supported value per session to 180** : Unlike NFSv3,\n NFSv4.1 clients define the relationship between the client and server\n in sessions. While NetApp Volumes supports up to 128\n outstanding requests per connection using NFSv3, NFSv4.1 is limited to\n 180 outstanding requests per session. Linux NFSv4.1 clients default to\n `64 max_session_slots` per session but you can tune this value as\n needed. We recommend changing the maximum supported value per session\n to 180.\n\n To tune `max_session_slots`, create a configuration file under\n `/etc/modprobe.d`. Make sure that no quotation marks (\" \") appear\n inline. Otherwise, the option doesn't take effect. \n\n $ echo \"options nfs max_session_slots=180\" \u003e /etc/modprobe/d/nfsclient/conf\n $ reboot\n\n Use the systool -v -m nfs command to see the current maximum in use\n by the client. For the command to work, at least one NFSv4.1 mount\n must be in place.\n\n $ systool -v -v nfs\n {\n Module = \"nfs\"\n ...\n Parameters:\n ...\n Max_session_slots = \"63\" \u003c-\n ...\n }\n\n The following NFS `nconnect` comparison graph demonstrates the impact\n using the nconnect configuration can have on an NFS workload. This\n information was captured using Fio with the following settings:\n - 100% read workload\n\n - 8 KiB block size against a single volume\n\n - `n2-standard-32` virtual machine using Red Hat 9 OS\n\n - 6 TiB working set\n\n Using an `nconnect` value of 16 resulted in five times more performance\n than when it wasn't enabled.\n\n ### Windows\n\n For Windows-based clients, the client can use [SMB Multichannel](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn610980(v=ws.11))\n with Receive Side Scaling (RSS) to open multiple TCP connections. To\n achieve this configuration, your virtual machine must have an allocated\n network adapter that supports RSS. We recommend setting RSS to four or\n eight values, however, any value over one should increase throughput.\n\n The following graph displays the difference using the RSS configuration\n can have on an SMB workload. This information was captured using Fio with\n the following settings:\n - 100% read workload\n\n - 8 KiB block size against a single volume\n\n - Single `n2-standard-32` virtual machine running a Windows 2022 OS\n\n - 6 TiB working set\n\n Eight jobs were run with only the SMB client RSS option changing between\n test executions. Using RSS values of 4, 8, and 16 increased performance\n two-fold when compared to using a value of 1. Each RSS instance was run\n nine times with a `numjobs` parameter of 8. The `iodepth` parameter was\n increased by five each execution until maximum throughput was reached.\n\nWhat's next\n-----------\n\nRead about [storage pools](/netapp/volumes/docs/configure-and-use/storage-pools/overview)."]]
