Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Optimalkan kinerja jaringan pada instance EC2 Windows
Untuk mencapai kinerja jaringan maksimum pada instance Windows Anda dengan jaringan yang disempurnakan, Anda mungkin perlu memodifikasi konfigurasi sistem operasi default. Kami merekomendasikan perubahan konfigurasi berikut untuk aplikasi yang memerlukan performa jaringan tinggi. Pengoptimalan lain (seperti mengaktifkan pembongkaran checksum dan mengaktifkanRSS, misalnya) sudah dikonfigurasi pada Windows resmi. AMIs
catatan
TCPpembongkaran cerobong asap harus dinonaktifkan dalam sebagian besar kasus penggunaan, dan telah tidak digunakan lagi pada Windows Server 2016.
Selain optimasi sistem operasi ini, Anda juga harus mempertimbangkan unit transmisi maksimum (MTU) lalu lintas jaringan Anda, dan menyesuaikan sesuai dengan beban kerja dan arsitektur jaringan Anda. Untuk informasi selengkapnya, lihat Unit transmisi maksimum jaringan (MTU) untuk EC2 instans Anda.
AWS secara teratur mengukur latensi pulang-pergi rata-rata antara instance yang diluncurkan dalam kelompok penempatan cluster 50us dan latensi ekor 200us pada persentil 99,9. Jika aplikasi Anda memerlukan latensi rendah secara konsisten, sebaiknya gunakan ENA driver versi terbaru pada instans kinerja tetap yang dibangun di Sistem Nitro.
Konfigurasikan afinitas penskalaan CPU sisi Terima
Receive side scaling (RSS) digunakan untuk mendistribusikan CPU beban lalu lintas jaringan di beberapa prosesor. Secara default, Amazon Windows resmi AMIs dikonfigurasi dengan RSS diaktifkan. ENAantarmuka jaringan elastis menyediakan hingga delapan RSS antrian. Dengan mendefinisikan CPU afinitas untuk RSS antrian, serta untuk proses sistem lainnya, dimungkinkan untuk menyebarkan CPU beban melalui sistem multi-core, memungkinkan lebih banyak lalu lintas jaringan untuk diproses. Pada jenis instans dengan lebih dari 16vCPUs, kami menyarankan Anda menggunakan Set-NetAdapterRSS
PowerShell cmdlet, yang secara manual mengecualikan prosesor boot (prosesor logis 0 dan 1 ketika hyper-threading diaktifkan) dari RSS konfigurasi untuk semua antarmuka jaringan elastis, untuk mencegah pertengkaran dengan berbagai komponen sistem.
Windows sadar hyper-thread dan memastikan bahwa RSS antrian kartu antarmuka jaringan tunggal (NIC) selalu ditempatkan pada inti fisik yang berbeda. Oleh karena itu, kecuali hyper-threading dinonaktifkan, untuk sepenuhnya mencegah pertengkaran dengan yang lainNICs, sebarkan RSS konfigurasi masing-masing NIC di antara kisaran 16 prosesor logis. Set-NetAdapterRss
Cmdlet memungkinkan Anda untuk menentukan per- NIC rentang prosesor logis yang valid dengan mendefinisikan nilai BaseProcessorGroup,,, BaseProcessorNumber MaxProcessingGroup MaxProcessorNumber, dan NumaNode (opsional). Jika tidak ada inti fisik yang cukup untuk sepenuhnya menghilangkan antar NIC pertentangan, meminimalkan rentang yang tumpang tindih atau kurangi jumlah prosesor logis dalam rentang antarmuka elastic network tergantung pada beban kerja antarmuka yang diharapkan (dengan kata lain, antarmuka jaringan administratif volume rendah mungkin tidak memerlukan banyak antrian yang ditetapkan). RSS Juga, seperti yang disebutkan sebelumnya, berbagai komponen harus berjalan pada CPU 0, dan oleh karena itu kami sarankan untuk mengecualikannya dari semua RSS konfigurasi ketika cukup vCPUs tersedia.
Misalnya, ketika ada tiga antarmuka jaringan elastis pada CPU instance 72 v dengan 2 NUMA node dengan hyper-threading diaktifkan, perintah berikut menyebarkan beban jaringan antara keduanya CPUs tanpa tumpang tindih dan mencegah penggunaan inti 0 sepenuhnya.
Set-NetAdapterRss -Name NIC1 -BaseProcessorGroup 0 -BaseProcessorNumber 2 -MaxProcessorNumber 16 Set-NetAdapterRss -Name NIC2 -BaseProcessorGroup 1 -BaseProcessorNumber 0 -MaxProcessorNumber 14 Set-NetAdapterRss -Name NIC3 -BaseProcessorGroup 1 -BaseProcessorNumber 16 -MaxProcessorNumber 30
Perhatikan bahwa pengaturan ini tetap ada untuk setiap adaptor jaringan. Jika sebuah instance diubah ukurannya menjadi satu dengan jumlah yang berbedavCPUs, Anda harus mengevaluasi kembali RSS konfigurasi untuk setiap antarmuka elastic network yang diaktifkan. Dokumentasi Microsoft lengkap untuk cmdlet dapat ditemukan di sini: Set
Catatan khusus untuk SQL beban kerja: Kami juga menyarankan Anda meninjau pengaturan afinitas utas I/O bersama dengan RSS konfigurasi antarmuka network elastis Anda untuk meminimalkan I/O dan pertentangan jaringan untuk hal yang sama. CPUs Lihat Konfigurasi server: topeng afinitas