Memecahkan masalah latensi dan waktu habis Azure Cache for Redis

Artikel
12/09/2023

Operasi klien yang tidak menerima respons tepat waktu dapat menghasilkan latensi tinggi atau pengecualian waktu habis. Operasi bisa kehabisan waktu di berbagai tahap. Saat waktu habis berasal dari bantuan untuk menentukan penyebab dan mitigasi.

Bagian ini membahas pemecahan masalah latensi dan waktu habis yang terjadi ketika menyambungkan ke Azure Cache for Redis.

Pemecahan masalah sisi klien
Pemecahan masalah sisi server

Catatan

Beberapa langkah pemecahan masalah dalam panduan ini menyertakan petunjuk untuk menjalankan perintah Redis dan memantau beragam metrik performa. Untuk informasi dan instruksi lebih lanjut, lihat artikel di bagian Informasi tambahan.

Pemecahan masalah sisi klien

Berikut adalah pemecahan masalah sisi klien.

Konfigurasi lonjakan lalu lintas dan kumpulan utas

Ledakan lalu lintas yang dikombinasikan dengan pengaturan ThreadPool yang buruk dapat mengakibatkan keterlambatan dalam memproses data yang sudah dikirim oleh Redis Server tetapi belum dikonsumsi di sisi klien. Periksa metrik "Kesalahan" (Ketik: UnresponsiveClients) untuk memvalidasi jika host klien Anda dapat mengikuti lonjakan lalu lintas yang tiba-tiba.

Pantau bagaimana statistik ThreadPool Anda berubah seiring waktu menggunakan ThreadPoolLogger contoh. Anda dapat menggunakan TimeoutException pesan dari StackExchange.Redis untuk menyelidiki lebih lanjut:

    System.TimeoutException: Timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
    IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)

Dalam pengecualian sebelumnya, ada beberapa masalah yang menarik:

Perhatikan bahwa di bagian IOCP dan bagian WORKER Anda memiliki Busy nilai yang lebih besar dari nilai Min. Perbedaan ini berarti pengaturan ThreadPool Anda perlu disesuaikan.
Anda juga dapat melihat in: 64221. Nilai ini menunjukkan bahwa 64.221 byte diterima di lapisan soket kernel klien tetapi tidak dibaca oleh aplikasi. Perbedaan ini biasanya berarti bahwa aplikasi Anda (misalnya, StackExchange.Redis) tidak membaca data dari jaringan secepat server mengirimkannya kepada Anda.

Anda dapat mengonfigurasikan ThreadPool Pengaturan untuk memastikan bahwa kumpulan alur Anda diskalakan dengan cepat di bawah skenario ledakan.

Nilai kunci besar

Untuk informasi tentang menggunakan beberapa kunci dan nilai yang lebih kecil, lihat Consider more keys and smaller values.

Anda dapat menggunakan redis-cli --bigkeys perintah untuk memeriksa kunci besar di cache Anda. Untuk informasi selengkapnya, lihat redis-cli, antarmuka saluran perintah Redis--Redis.

Tingkatkan ukuran VM Anda untuk mendapatkan kemampuan bandwidth yang lebih tinggi
- Lebih banyak bandwidth pada komputer virtual klien atau server Anda dapat mengurangi waktu transfer data untuk respons yang lebih besar.
- Bandingkan penggunaan jaringan Anda saat ini pada kedua mesin dengan batas ukuran komputer virtual Anda saat ini. Lebih banyak bandwidth hanya pada server atau hanya pada klien mungkin tidak cukup.
Tingkatkan jumlah objek koneksi yang digunakan aplikasi Anda.
- Gunakan pendekatan round-robin untuk membuat permintaan atas objek koneksi yang berbeda

CPU tinggi pada host klien

Penggunaan CPU klien yang tinggi menunjukkan sistem tidak dapat mengikuti pekerjaan yang ditetapkan untuknya. Meskipun cache mengirim respons dengan cepat, klien mungkin gagal memproses respons secara tepat waktu. Rekomendasi kami adalah menjaga CPU klien kurang 80%. Periksa metrik "Kesalahan" (Ketik: UnresponsiveClients) untuk menentukan jika host klien Anda dapat memproses respons dari server Redis tepat waktu.

Pantau penggunaan CPU seluruh sistem klien menggunakan metrik yang tersedia di portal Microsoft Azure atau melalui penghitung kinerja pada mesin. Berhati-hatilah untuk tidak memantau proses CPU karena satu proses dapat memiliki penggunaan CPU yang rendah tetapi CPU di seluruh sistem bisa tinggi. Perhatikan lonjakan penggunaan CPU yang sesuai dengan habisnya waktu. CPU tinggi juga dapat menyebabkan nilai tinggi in: XXX dalam TimeoutException pesan kesalahan seperti yang dijelaskan di bagian [Ledakan lalu lintas].

Catatan

StackExchange.Redis 1.1.603 dan yang lebih baru menyertakan metrik local-cpu dalam pesan kesalahan TimeoutException. Pastikan Anda menggunakan versi terbaru paket StackExchange.Redis NuGet. Bug akan secara teratur diperbaiki dalam kode untuk membuatnya lebih canggih untuk waktu habis. Memiliki versi terbaru adalah penting.

Untuk mengurangi penggunaan CPU klien yang tinggi:

Selidiki apa yang menyebabkan lonjakan CPU.
Tingkatkan klien Anda ke ukuran komputer virtual yang lebih besar dengan kapasitas CPU yang lebih banyak.

Pembatasan bandwidth jaringan pada host klien

Tergantung pada arsitektur komputer klien, mereka mungkin memiliki batasan tentang berapa banyak bandwidth jaringan yang mereka miliki. Jika klien melebihi bandwidth yang tersedia dengan membebani kapasitas jaringan berlebih, maka data tidak diproses di sisi klien secepat server mengirimkannya. Situasi ini dapat menyebabkan waktu habis.

Pantau bagaimana perubahan penggunaan Bandwidth Anda dari waktu ke waktu menggunakan contoh BandwidthLogger. Kode ini mungkin tidak berhasil berjalan di beberapa lingkungan dengan izin terbatas (seperti situs web Azure).

Untuk memitigasi, mengurangi konsumsi bandwidth jaringan atau meningkatkan ukuran komputer virtual klien menjadi satu dengan kapasitas jaringan yang lebih banyak. Untuk informasi selengkapnya, lihat Large request or response size.

Pengaturan TCP untuk aplikasi klien berbasis Linux

Karena pengaturan TCP optimis di Linux, aplikasi klien yang dihosting di Linux dapat mengalami masalah konektivitas. Untuk informasi selengkapnya, lihat TCP settings for Linux-hosted client applications

RedisSessionStateProvider coba lagi waktu habis

Jika Anda menggunakan RedisSessionStateProvider, pastikan Anda mengatur batas waktu coba lagi dengan benar. Nilainya retryTimeoutInMilliseconds harus lebih tinggi dari nilainya operationTimeoutInMilliseconds. Jika tidak, tidak ada percobaan ulang yang terjadi. Dalam contoh berikut, retryTimeoutInMilliseconds diatur ke 3000. Untuk informasi lebih lanjut, lihat Penyedia Keadaan Sesi ASP.NET untuk Azure Cache for Redis dan Cara menggunakan parameter konfigurasi Penyedia Keadaan Sesi dan Penyedia Cache Output.

<add 
    name="AFRedisCacheSessionStateProvider"
    type="Microsoft.Web.Redis.RedisSessionStateProvider"
    host="enbwcache.redis.cache.windows.net"
    port="6380"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

Pemecahan masalah sisi server

Berikut adalah pemecahan masalah sisi server.

Pemeliharaan server

Pemeliharaan yang direncanakan atau tidak direncanakan dapat menyebabkan gangguan dengan koneksi klien. Jumlah dan jenis pengecualian tergantung letak permintaan pada jalur kode saat cache menutup koneksinya. Misalnya, operasi yang mengirim permintaan tetapi tidak menerima respons ketika failover terjadi mungkin mendapatkan pengecualian waktu habis. Permintaan baru pada objek koneksi tertutup akan menerima pengecualian koneksi hingga koneksi ulang berhasil tersambung.

Untuk informasi selengkapnya, periksa bagian lain ini:

Memperbarui saluran dan Menjadwalkan pembaruan
Ketahanan koneksi
AzureRedisEventsPemberitahuan

Untuk memeriksa apakah Azure Cache for Redis Anda mengalami failover saat waktu habis terjadi, periksa Kesalahan metrik. Pada menu Resource portal Azure, pilih Metrics. Kemudian buat bagan baru yang mengukur Errors metrik, dibagi dengan ErrorType. Setelah membuat bagan ini, Anda akan melihat hitungan untuk Failover.

Untuk informasi selengkapnya tentang failover, lihat Failover and patching for Azure Cache for Redis.

Beban server tinggi

Beban server yang tinggi berarti server Redis tidak dapat mengikuti permintaan, yang mengarah ke waktu habis. Server mungkin lambat merespons dan tidak dapat mengikuti laju permintaan.

Pantau metrik seperti beban server. Perhatikan lonjakan Server Load penggunaan yang sesuai dengan waktu habis. Buat peringatan pada metrik pada pemuatan server untuk diberi tahu lebih awal tentang dampak potensial.

Ada beberapa perubahan yang dapat Anda lakukan untuk mengurangi beban server yang tinggi:

Selidiki apa yang menyebabkan beban server tinggi seperti perintah jangka panjang, yang dicatat dalam artikel ini, karena tekanan memori yang tinggi.
Skalakanke lebih banyak pecahan untuk mendistribusikan beban di beberapa proses Redis atau skala ke ukuran cache yang lebih besar dengan lebih banyak core CPU. Untuk informasi selengkapnya, lihat Tanya Jawab Umum perencanaan Azure Cache for Redis.
Jika beban kerja produksi Anda pada cache C1 dipengaruhi secara negatif oleh latensi ekstra dari pemindaian virus, Anda dapat mengurangi efeknya dengan membayar penawaran tingkat yang lebih tinggi dengan beberapa inti CPU, seperti C2.

Lonjakan beban server

Pada cache C0 dan C1 , Anda mungkin melihat lonjakan pendek dalam beban server yang tidak disebabkan oleh peningkatan permintaan beberapa kali sehari saat pemindaian virus berjalan pada VM. Anda melihat latensi yang lebih tinggi untuk permintaan saat pemindaian virus terjadi pada tingkat ini. Cache pada tingkat C0 dan C1 hanya memiliki satu inti untuk multitugas, membagi pekerjaan melayani pemindaian virus dan permintaan Redis.

Penggunaan memori tinggi

Bagian ini dipindahkan. Untuk informasi selengkapnya, lihat High memory usage.

Perintah jangka panjang

Beberapa perintah Redis lebih mahal untuk dieksekusi daripada yang lain. Dokumentasi perintah Redis menunjukkan kompleksitas waktu setiap perintah. Pemrosesan perintah Redis yang berulir tunggal. Perintah apa pun yang memerlukan waktu lama untuk berjalan dapat memblok lainnya yang mencarinya.

Anda harus meninjau perintah yang Anda keluarkan ke server Redis Anda untuk memahami dampak performanya. Misalnya, perintah KEYS sering digunakan tanpa mengetahui bahwa itu adalah operasi O(N). Anda dapat menghindari KEYS dengan menggunakan SCAN untuk mengurangi lonjakan CPU.

Dengan menggunakan perintah SLOWLOG GET, Anda dapat mengukur perintah mahal yang dijalankan terhadap server.

Pelanggan dapat menggunakan konsol untuk menjalankan perintah Redis ini untuk menyelidiki perintah yang sudah lama berjalan dan mahal.

SLOWLOG digunakan untuk membaca dan mengatur ulang log kueri lambat Redis. Ini dapat digunakan untuk menyelidiki perintah jangka panjang di sisi klien. Redis Slow Log adalah sistem untuk mencatat kueri yang melebihi waktu eksekusi tertentu. Waktu eksekusi tidak termasuk operasi I/O seperti berbicara dengan klien, mengirim balasan, dan sebagainya, tetapi hanya waktu yang diperlukan untuk benar-benar menjalankan perintah. Pelanggan dapat mengukur/mencatat perintah mahal yang dijalankan terhadap server Redis mereka menggunakan SLOWLOG perintah .
MONITOR adalah perintah debugging yang mengalirkan kembali setiap perintah yang diproses oleh server Redis. Ini dapat membantu dalam memahami apa yang terjadi pada database. Perintah ini banyak permintaannya dan dapat berdampak negatif terhadap kinerja. Itu bisa menurunkan kinerja.
INFO - perintah mengembalikan informasi dan statistik tentang server dalam format yang mudah diurai oleh komputer dan mudah dibaca oleh manusia. Dalam hal ini, bagian CPU dapat berguna untuk menyelidiki penggunaan CPU. Beban server 100 (nilai maksimum) menandakan bahwa server Redis sibuk sepanjang waktu dan tidak pernah menganggur saat memproses permintaan.

Sampel output:

# CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1

DAFTAR KLIEN - mengembalikan informasi dan statistik tentang server koneksi klien dalam format yang sebisa mungkin dapat dibaca manusia.

Batasan bandwidth jaringan

Ukuran cache yang berbeda memiliki kapasitas bandwidth jaringan yang berbeda. Jika server melebihi bandwidth yang tersedia, maka data tidak dikirim ke klien secepat mungkin. Permintaan klien bisa kehabisan waktu karena server tidak dapat mendorong data ke klien cukup cepat.

Metrik "Cache Read" dan "Cache Write" dapat digunakan untuk melihat berapa banyak bandwidth sisi server yang digunakan. Anda dapat melihat metrik ini di portal. Buat pemberitahuan pada metrik seperti baca cache atau tulis cache untuk diberi tahu lebih awal tentang potensi dampak.

Untuk mengurangi situasi saat penggunaan bandwidth jaringan mendekati kapasitas maksimum:

Ubah perilaku panggilan klien untuk mengurangi permintaan jaringan.
Skalakan ke ukuran cache yang lebih besar dengan kapasitas bandwidth jaringan yang lebih banyak. Untuk informasi selengkapnya, lihat Tanya Jawab Umum perencanaan Azure Cache for Redis.

Pengecualian waktu habis StackExchange.Redis

Untuk mengetahui informasi lebih spesifik terkait cara mengatasi waktu habis saat menggunakan StackExchange.Redis, lihat Menyelidiki pengecualian batas waktu di StackExchange.Redis.