Bagaimana untuk menyelesaikan masalah kependaman biasa dalam Redis

Gunakan arahan yang kompleks

Jika anda mendapati bahawa kelewatan akses tiba-tiba meningkat apabila menggunakan Redis, bagaimana untuk menyelesaikan masalah?

Pertama sekali, langkah pertama ialah menyemak log perlahan Redis. Melalui fungsi statistik arahan log perlahan Redis, kita boleh menetapkan pilihan berikut untuk melihat arahan yang menyebabkan kelewatan besar dalam pelaksanaan.

Pertama tetapkan ambang log perlahan Redis Hanya arahan yang melebihi ambang akan direkodkan. Unit di sini ialah mikrosaat. rekod untuk disimpan. :

# 命令执行超过5毫秒记录慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000条慢日志
CONFIG SET slowlog-max-len 1000

Selepas tetapan selesai, semua arahan yang dilaksanakan akan direkodkan oleh Redis jika kelewatan lebih daripada 5 milisaat Kami melaksanakan SLOWLOG get 5 untuk menanyakan 5 log perlahan:

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 执行时间
   3) (integer) 5299        # 执行耗时(微妙)
   4) 1) "LRANGE"           # 具体执行的命令和参数
      2) "user_list_2000"
      3) "0"
      4) "-1"
2) 1) (integer) 32692
   2) (integer) 1593763337
   3) (integer) 5044
   4) 1) "GET"
      2) "book_price_1000"
...

Dengan melihat log perlahan Melalui pengelogan, kita dapat mengetahui arahan yang memakan masa untuk dilaksanakan pada masa yang sama jika perniagaan anda sering menggunakan perintah dengan kerumitan di atas O(N), seperti sort, sunion, zunionstore , kekunci, imbasan atau semasa melaksanakan perintah O(N) ) mengendalikan jumlah data yang agak besar, dan dalam kes ini, Redis akan memakan masa yang sangat lama untuk memproses data.

Jika penggunaan CPU bagi contoh Redis adalah tinggi, tetapi volum permintaan perkhidmatan anda tidak besar, ia mungkin disebabkan oleh penggunaan arahan dengan kerumitan yang tinggi.

Penyelesaian adalah dengan tidak menggunakan arahan yang kompleks ini dan tidak mendapatkan terlalu banyak data pada satu masa Cuba mengendalikan sejumlah kecil data setiap kali supaya Redis boleh memproses dan mengembalikannya dalam masa.

Menyimpan kunci besar

Jika anda menanyakan log perlahan dan mendapati ia tidak disebabkan oleh arahan dengan kerumitan yang tinggi, contohnya, operasi SET dan DELETE muncul dalam rekod log perlahan, maka anda harus curiga Adakah terdapat situasi di mana Redis menulis kunci besar?

Apabila Redis menulis data baharu, ruang memori diperuntukkan untuknya dan apabila data dipadamkan daripada Redis, ruang memori yang sepadan turut dikeluarkan.

Apabila data yang ditulis oleh kunci adalah sangat besar, Redis memperuntukkan memori juga akan menjadi lebih memakan masa. Begitu juga, apabila memadam data kunci ini, ia akan mengambil masa yang lama untuk melepaskan memori.

Anda perlu menyemak kod perniagaan anda untuk melihat sama ada bigkey sedang ditulis Anda perlu menilai jumlah data yang ditulis Lapisan perniagaan harus mengelak daripada menyimpan jumlah data yang berlebihan dalam satu kunci.

Sebagai tindak balas kepada masalah kunci besar, Redis secara rasmi melancarkan mekanisme bebas malas dalam versi 4.0, yang digunakan untuk melepaskan memori kunci besar secara tak segerak dan mengurangkan kesan ke atas prestasi Redis. Walaupun begitu, kami tidak mengesyorkan menggunakan Bigkey juga akan menjejaskan prestasi pemindahan semasa proses penghijrahan kelompok. Ini akan diperkenalkan secara terperinci kemudian dalam artikel berkaitan kelompok.

Tamat Tempoh Pekat

Kadangkala anda akan mendapati bahawa tiada kelewatan besar apabila menggunakan Redis, tetapi pada satu ketika tertentu, gelombang kelewatan tiba-tiba berlaku, dan masa dilaporkan perlahan-lahan. Mata adalah sangat teratur, seperti jam tertentu, atau kekerapan ia akan berlaku.

Jika ini berlaku, anda perlu mempertimbangkan sama ada terdapat sejumlah besar kunci yang telah tamat tempoh bersama.

Jika sebilangan besar kunci tamat tempoh pada masa yang tetap, kelewatan mungkin meningkat apabila mengakses Redis pada masa ini.

Strategi tamat tempoh Redis menggunakan dua strategi: pemadaman biasa + pemadaman malas;

Perhatikan bahawa tugasan berjadual pemadaman biasa Redis juga dilaksanakan dalam utas utama Redis, iaitu, jika Semasa proses melaksanakan tamat tempoh aktif, terdapat situasi di mana sejumlah besar kunci tamat tempoh perlu dipadamkan Oleh itu, semasa akses perniagaan, permintaan perniagaan mesti diproses hanya selepas tugas tamat tempoh selesai. Pada masa ini, masalah peningkatan kelewatan akses perniagaan akan berlaku, dan kelewatan maksimum ialah 25 milisaat.

Dan kelewatan akses ini tidak akan direkodkan dalam log perlahan. Log perlahan hanya merekodkan masa pelaksanaan sebenar bagi dasar tamat tempoh aktif Redis dilaksanakan sebelum perintah operasi Jika perintah operasi tidak mencapai ambang log perlahan, ia tidak akan dikira dalam statistik log perlahan. perniagaan telah mengalami peningkatan kelewatan.

Penyelesaiannya ialah menambah masa rawak pada tamat tempoh terpusat dan menyebarkan masa kunci ini yang perlu tamat tempoh.

Memori contoh mencapai had atas

Kadangkala apabila kami menggunakan Redis sebagai cache tulen, kami akan menetapkan memori maksimum had atas memori untuk contoh, dan kemudian mendayakan strategi penghapusan LRU.

Apabila ingatan contoh mencapai maxmemory, anda akan mendapati bahawa menulis data baharu mungkin menjadi lebih perlahan setiap kali.

Sebab kelembapan adalah apabila memori Redis mencapai memori maksimum, sebelum setiap data baharu ditulis, sebahagian daripada data mesti ditendang keluar untuk mengekalkan memori di bawah memori maksimum.

Logik menendang keluar data lama juga mengambil masa, dan tempoh masa tertentu bergantung pada strategi penyingkiran yang dikonfigurasikan

garpu serius memakan masa

Jika Jika anda Redis mempunyai fungsi menjana RDB secara automatik dan penulisan semula AOF didayakan, ia boleh meningkatkan kelewatan akses Redis apabila menjana RDB dan penulisan semula AOF di latar belakang Selepas tugasan ini selesai, kelewatan hilang.

Apabila menghadapi situasi ini, ia biasanya disebabkan oleh melaksanakan tugas menjana penulisan semula RDB dan AOF.

Menjana RDB dan AOF memerlukan proses induk untuk menghentikan proses anak untuk kegigihan data Semasa proses pelaksanaan fork, proses induk perlu menyalin jadual halaman memori ke proses anak jumlah memori, maka satu salinan diperlukan sumber CPU adalah ketat pada masa ini, garpu akan mengambil masa yang lebih lama walaupun mencapai tahap kedua. Ini akan menjejaskan prestasi Redis secara serius.

CPU Mengikat

Banyak kali, apabila kami menggunakan perkhidmatan, untuk meningkatkan prestasi dan mengurangkan kehilangan prestasi penukaran konteks apabila program menggunakan berbilang CPU, kami biasanya menggunakan proses mengikat kepada CPU beroperasi.

Tetapi apabila menggunakan Redis, kami tidak mengesyorkan melakukan ini atas sebab berikut.

Redis terikat CPU, apabila melakukan ketekunan data, proses anak bercabang akan mewarisi keutamaan penggunaan CPU proses induk, dan pada masa ini proses anak akan menggunakan sejumlah besar sumber CPU untuk kegigihan data. Proses anak akan bersaing dengan proses utama untuk CPU, yang juga akan menyebabkan proses utama mempunyai sumber CPU yang tidak mencukupi dan meningkatkan kelewatan akses.

Jadi apabila menggunakan proses Redis, jika anda perlu mendayakan mekanisme penulisan semula RDB dan AOF, anda tidak boleh melakukan operasi mengikat CPU

Gunakan Swap

Jika anda mendapati bahawa Redis tiba-tiba berubah Ia sangat perlahan, dan setiap akses mengambil masa ratusan milisaat atau bahkan beberapa saat Kemudian semak sama ada Redis menggunakan Swap Dalam kes ini, Redis pada dasarnya tidak dapat menyediakan perkhidmatan berprestasi tinggi.

Kami tahu bahawa sistem pengendalian menyediakan mekanisme Swap Tujuannya adalah untuk menukar sebahagian daripada data dalam ingatan kepada cakera apabila memori tidak mencukupi, untuk menampan penggunaan memori.

Tetapi selepas data dalam memori ditukar kepada cakera, mengakses data memerlukan bacaan daripada cakera, yang jauh lebih perlahan daripada memori!

Terutama untuk pangkalan data dalam memori berprestasi tinggi seperti Redis, jika memori dalam Redis ditukar kepada cakera, masa operasi ini tidak boleh diterima untuk pangkalan data yang sangat sensitif prestasi seperti Redis. Anda boleh mematikan Swap sistem pengendalian buat sementara waktu

Beban kad rangkaian terlalu tinggi

Ciri-cirinya ialah ia mula perlahan dari suatu masa tertentu dan berterusan. Pada masa ini, anda perlu menyemak sama ada trafik kad rangkaian mesin telah habis.

Beban rangkaian yang tinggi boleh menyebabkan masalah seperti kelewatan penghantaran data dan kehilangan data pada lapisan rangkaian dan tahap TCP. Selain ingatan, Redis berprestasi tinggi kerana prestasi IO rangkaiannya yang sangat baik. Walau bagaimanapun, apabila bilangan permintaan terus meningkat, beban pada kad rangkaian akan meningkat dengan sewajarnya.

Jika ini berlaku, anda perlu menyemak contoh Redis pada mesin ini yang mempunyai trafik yang berlebihan dan mengisi lebar jalur rangkaian, dan kemudian mengesahkan sama ada peningkatan mendadak dalam trafik adalah situasi perniagaan biasa anda perlu mengembangkan kapasiti dalam masa atau memindahkan contoh untuk mengelakkan kejadian lain mesin ini daripada terjejas.

Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah kependaman biasa dalam Redis. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!