Perbincangan ringkas tentang sebab mengapa Redis lambat dan cara menyelesaikannya

Artikel ini membawa anda pengetahuan yang berkaitan tentang Redis terutamanya sebab mengapa Redis lambat dan kaedah penyelesaian masalah Artikel ini memperkenalkannya secara terperinci melalui kod sampel, yang sangat membantu semua orang atau bekerja mempunyai rujukan dan nilai pembelajaran tertentu. Saya harap ia akan membantu semua orang.

Pembelajaran yang disyorkan: Tutorial video Redis

Punca 1: Memori instance mencapai had atas

Idea Penyelesaian Masalah

Jika tika Redis anda menetapkan had ingatan maksimum memori, ia juga boleh menyebabkan Redis menjadi perlahan.

Apabila kami menggunakan Redis sebagai cache tulen, kami biasanya menetapkan memori maksimum had atas memori untuk kejadian ini, dan kemudian menetapkan strategi penghapusan data. Apabila ingatan contoh mencapai maxmemory, anda mungkin mendapati bahawa kelewatan operasi meningkat setiap kali anda menulis data baharu selepas itu.

Sebab kelembapan

Apabila memori Redis mencapai memori maksimum, Redis mesti menendang keluar beberapa data daripada kejadian setiap kali sebelum menulis data baharu contoh di bawah maxmemory sebelum data baharu boleh ditulis.

Logik menendang keluar data lama juga mengambil masa, dan tempoh masa tertentu bergantung pada strategi penghapusan yang anda konfigurasikan:

• allkeys-lru: tanpa mengira kunci Sama ada tamat tempoh tetapkan, hapuskan kunci yang paling kurang diakses baru-baru ini
• volatile-lru: hanya hapuskan kunci yang paling kurang diakses baru-baru ini dengan set masa tamat
• allkeys-random: tanpa mengira sama ada kunci ditetapkan untuk tamat tempoh , hapuskan kekunci secara rawak
• rawak meruap: hanya hapuskan kunci secara rawak dengan masa tamat tempoh ditetapkan
• allkeys-ttl: hapuskan kunci yang hampir tamat tempoh tidak kira sama ada kunci ditetapkan untuk tamat tempoh
• noeviction: Tiada kunci akan dihapuskan Selepas ingatan contoh mencapai maksimum, ralat akan dikembalikan secara langsung apabila data baharu ditulis
• allkeys-lfu: Tidak kira sama ada kunci ditetapkan untuk tamat tempoh. kunci dengan kekerapan akses terendah akan dihapuskan (disokong dalam versi 4.0)
• volatile-lfu: Hanya hapuskan kekerapan akses terendah dan tetapkan kunci masa tamat tempoh (disokong oleh versi 4.0)

Strategi mana yang hendak digunakan bergantung pada senario perniagaan tertentu. Secara amnya, yang paling biasa digunakan ialah strategi penghapusan allkeys-lru / volatile-lru Logik pemprosesan mereka adalah untuk mengeluarkan sekumpulan kunci secara rawak dari contoh setiap kali (nombor ini boleh dikonfigurasikan), kemudian menghapuskan kunci yang paling kurang diakses, dan kemudian. gunakan kekunci yang tinggal untuk sementara waktu simpan kekunci dalam kumpulan, teruskan memilih kumpulan kunci secara rawak, bandingkan dengan kunci dalam kumpulan sebelumnya, dan kemudian hapuskan kunci yang paling kurang diakses. Ulangi ini sehingga ingatan contoh jatuh di bawah memori maksimum.

Perlu diingatkan bahawa logik untuk menghapuskan data dalam Redis adalah sama seperti memadam kekunci tamat tempoh Ia juga dilaksanakan sebelum perintah itu benar-benar dilaksanakan dengan kata lain, ia juga akan meningkatkan kelewatan operasi Redis kami Selain itu, menulis OPS Semakin tinggi ia, semakin ketara kelewatannya.

Selain itu, jika bigkey turut disimpan dalam instance Redis anda pada masa ini, ia juga akan mengambil masa yang lama untuk menghapuskan dan memadamkan bigkey untuk melepaskan memori.

Adakah anda melihatnya? Bahaya bigkey ada di mana-mana, sebab tu saya ingatkan awal-awal supaya jangan simpan bigkey sebanyak mungkin.

Penyelesaian

• Elakkan menyimpan bigkey dan kurangkan masa melepaskan ingatan
• Strategi penyingkiran ditukar kepada penyingkiran rawak, yang lebih baik daripada LRU Ia lebih pantas (dilaraskan berdasarkan keadaan perniagaan)
• Pisah kejadian dan edarkan tekanan penyingkiran kunci kepada berbilang kejadian
• Jika anda menggunakan Redis 4.0 atau lebih tinggi, dayakan layz -mekanisme bebas , letakkan operasi menghapuskan kunci dan melepaskan memori ke dalam benang latar belakang (konfigurasikan lazyfree-lazy-eviction = ya)

Punca 2: Hidupkan halaman memori yang besar

Idea Penyelesaian Masalah

• Kita semua tahu bahawa apabila aplikasi memohon memori daripada sistem pengendalian, ia digunakan untuknya mengikut halaman memori dan saiz halaman memori konvensional ialah 4KB.
• Bermula dari 2.6.38, kernel Linux menyokong mekanisme halaman besar memori, yang membolehkan aplikasi memohon memori daripada sistem pengendalian dalam unit 2MB.
• Unit memori yang digunakan oleh aplikasi pada sistem pengendalian setiap kali menjadi lebih besar, tetapi ini juga bermakna masa yang diperlukan untuk memohon memori menjadi lebih lama.

Punca kelembapan

• Apabila Redis melaksanakan RDB latar belakang dan penulisan semula AOF, ia menggunakan proses anak fork untuk mengendalikannya. Walau bagaimanapun, selepas proses utama menghentikan proses kanak-kanak, proses utama pada masa ini masih boleh menerima permintaan tulis, dan permintaan tulis masuk akan menggunakan kaedah Salin Pada Tulis (salin atas tulis) untuk mengendalikan data memori.
• Dalam erti kata lain, apabila proses utama mempunyai data yang perlu diubah suai, Redis tidak akan mengubah suai secara langsung data dalam memori sedia ada, sebaliknya ia akan menyalin data memori dahulu dan kemudian mengubah suai data masuk memori baharu , ini dipanggil "salin-pada-tulis".
• Copy-on-write juga boleh difahami sebagai, sesiapa yang perlu menulis perlu menyalin dahulu dan kemudian mengubah suai.
• Kelebihan ini ialah sebarang operasi tulis oleh proses induk tidak akan menjejaskan kegigihan data proses anak (proses anak hanya mengekalkan semua data dalam keseluruhan kejadian pada saat fork, dan tidak tidak peduli perubahan data baru, kerana proses kanak-kanak hanya memerlukan snapshot memori, yang kemudiannya diteruskan ke cakera).
• Tetapi sila ambil perhatian bahawa apabila proses utama menyalin data memori, peringkat ini melibatkan penggunaan memori baharu Jika sistem pengendalian menghidupkan halaman memori yang besar pada masa ini, maka dalam tempoh ini, walaupun jika pelanggan Jika hanya 10B data diubah suai, Redis juga akan digunakan pada sistem pengendalian dalam unit 2MB apabila memohon memori Masa yang diambil untuk memohon memori akan menjadi lebih lama, yang akan meningkatkan kelewatan setiap permintaan tulis dan menjejaskan Prestasi Redis.
• Begitu juga, jika permintaan tulis ini beroperasi pada kunci besar, maka apabila proses utama menyalin blok memori kunci besar, memori yang diminta pada satu-satu masa akan menjadi lebih besar dan masa akan menjadi lebih lama. Ia boleh dilihat bahawa bigkey menjejaskan prestasi di sini sekali lagi.

Penyelesaian

Matikan mekanisme halaman yang besar.

Pertama sekali, anda perlu menyemak sama ada mesin Redis mempunyai halaman besar didayakan:

$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Jika pilihan output sentiasa, ini bermakna mekanisme halaman besar didayakan pada masa ini, dan kita perlu mematikannya.

$ echo never > /sys/kernel/mm/transparent_hugepage/enabled

Tetapi untuk pangkalan data seperti Redis, yang sangat sensitif terhadap prestasi dan kependaman, kami berharap Redis akan mengambil masa yang sesingkat mungkin setiap kali ia digunakan untuk ingatan, jadi saya tidak mengesyorkan anda mendayakan ini mekanisme pada mesin Redis.

Punca 3: Gunakan Swap

Idea Penyelesaian Masalah

Jika anda mendapati Redis tiba-tiba menjadi sangat perlahan, setiap operasi mengambil masa sehingga Beratus-ratus milisaat atau walaupun beberapa saat, maka anda perlu menyemak sama ada Redis menggunakan Swap Dalam kes ini, Redis pada dasarnya tidak dapat menyediakan perkhidmatan berprestasi tinggi.

Punca kelembapan

Apakah itu Swap? Mengapakah menggunakan Swap menyebabkan kemerosotan prestasi Redis?

Jika anda mengetahui sesuatu tentang sistem pengendalian, anda akan tahu bahawa untuk mengurangkan kesan memori yang tidak mencukupi pada aplikasi, sistem pengendalian membenarkan sebahagian daripada data dalam memori ditukar kepada cakera untuk menampan penggunaan memori aplikasi , data memori ini ditukar ke kawasan pada cakera, iaitu Swap.

Masalahnya ialah apabila data dalam memori dialihkan ke cakera, apabila Redis mengakses data semula, ia perlu membacanya dari cakera Kelajuan mengakses cakera adalah ratusan kali lebih perlahan daripada mengakses memori! Terutama untuk pangkalan data seperti Redis, yang mempunyai keperluan prestasi yang sangat tinggi dan sangat sensitif terhadap prestasi, kelewatan operasi ini tidak boleh diterima.

Pada ketika ini, anda perlu menyemak penggunaan memori mesin Redis untuk mengesahkan sama ada Swap digunakan. Anda boleh menyemak sama ada proses Redis menggunakan Swap dengan cara berikut:

Hasil output adalah seperti berikut

SAIZ: 1256 KB

SWAP: 0 KB
SAIZ: 4 KB
SWAP: 0 KB
SAIZ: 132 KB
SWAP: 0 KB
SAIZ: SAIZ: 63488 kB
Tukar:                                                                                                                                                       … 🎜>...


Keputusan ini akan senaraikan penggunaan memori proses Redis.

Setiap baris Saiz mewakili saiz sekeping memori yang digunakan oleh Redis Saiz di bawah mewakili saiz memori dan berapa banyak data yang telah ditukar kepada cakera Jika kedua-dua nilai ini​​ adalah sama, ia bermakna bahawa ini Data dalam memori blok telah ditukar sepenuhnya ke cakera.

Jika hanya sejumlah kecil data ditukar ke cakera, sebagai contoh, setiap Swap menduduki bahagian kecil Saiz yang sepadan, impaknya tidak begitu besar. Jika beratus-ratus megabait atau bahkan GB memori ditukar kepada cakera, maka anda perlu berwaspada Dalam kes ini, prestasi Redis pasti akan menurun secara mendadak.

Penyelesaian

Tingkatkan memori mesin supaya Redis mempunyai memori yang mencukupi untuk menggunakan

untuk mengatur ruang memori dan melepaskan secukupnya Memori digunakan oleh Redis, dan kemudian Swap of Redis dikeluarkan untuk membenarkan Redis menggunakan semula memori

Proses melepaskan Swap of Redis biasanya memerlukan memulakan semula kejadian kesan memulakan semula contoh pada perniagaan, proses induk-hamba biasanya dilakukan terlebih dahulu, kemudian lepaskan Swap nod induk lama, mulakan semula contoh nod induk lama, tunggu sehingga penyegerakan data pangkalan data hamba selesai, dan kemudian. lakukan suis tuan-hamba.

Dapat dilihat apabila Redis menggunakan Swap, prestasi Redis pada masa ini pada asasnya tidak dapat memenuhi keperluan prestasi tinggi (anda boleh memahami bahawa seni mempertahankan diri telah dimansuhkan), jadi anda juga perlu mencegah keadaan ini. terlebih dahulu.
• Cara untuk mencegahnya ialah anda perlu memantau memori dan penggunaan Swap mesin Redis, penggera apabila memori tidak mencukupi atau Swap digunakan, dan mengendalikannya tepat pada masanya.
• Punca 4: kelebihan lebar jalur rangkaian

Idea penyelesaian masalah

Jika anda telah mengelakkan senario di atas yang menyebabkan masalah prestasi, dan Redis stabil Ia mempunyai telah berjalan untuk masa yang lama, tetapi selepas beberapa ketika, operasi Redis tiba-tiba mula perlahan, dan ia berterusan. Apakah sebab untuk keadaan ini?

Pada masa ini, anda perlu menyemak sama ada lebar jalur rangkaian mesin Redis terlebih muatan, dan sama ada terdapat kejadian yang mengisi lebar jalur rangkaian keseluruhan mesin.

Sebab kelembapan

Apabila lebar jalur rangkaian terlebih beban, pelayan akan mengalami kelewatan penghantaran paket, kehilangan paket, dsb. pada lapisan TCP dan lapisan rangkaian.

Prestasi tinggi Redis, selain memori operasi, terletak pada IO rangkaian Jika terdapat kesesakan dalam rangkaian IO, ia juga akan menjejaskan prestasi Redis dengan serius.

Penyelesaian

Sahkan tepat pada masanya bahawa tika Redis telah mengisi lebar jalur rangkaian Jika ia adalah akses perniagaan biasa, anda perlu mengembangkan atau memindahkannya contoh dalam masa yang perlu dielakkan Oleh kerana trafik contoh ini terlalu besar, ia mempengaruhi kejadian lain mesin ini.

Pada peringkat operasi dan penyelenggaraan, anda perlu meningkatkan pemantauan pelbagai penunjuk mesin Redis, termasuk trafik rangkaian Apabila trafik rangkaian mencapai ambang tertentu, penggera terlebih dahulu dan sahkan serta kembangkan kapasiti tepat pada masanya cara.

Sebab 5: Sebab lain

• 1) Sambungan pendek yang kerap
• Aplikasi perniagaan anda harus menggunakan sambungan panjang untuk mengendalikan Redis, elakkan Kerap sambungan pendek.

Sambungan pendek yang kerap akan menyebabkan Redis menghabiskan banyak masa untuk mewujudkan dan melepaskan sambungan Jabat tangan tiga hala dan gelombang empat hala TCP juga akan meningkatkan kelewatan akses.

2) Pemantauan operasi dan penyelenggaraan

Saya juga menyatakan sebelum ini bahawa jika anda ingin meramalkan kelembapan Redis terlebih dahulu, adalah penting untuk melakukan kerja yang baik dalam pemantauan.

Pemantauan sebenarnya adalah pengumpulan pelbagai penunjuk masa jalan Redis Pendekatan biasa adalah untuk program pemantauan kerap mengumpul maklumat INFO Redis, dan kemudian melakukan paparan data dan penggera berdasarkan data status dalam maklumat INFO.

Apa yang perlu saya ingatkan di sini ialah anda tidak boleh mengambil mudah apabila menulis beberapa skrip pemantauan atau menggunakan komponen pemantauan sumber terbuka.

Apabila menulis skrip pemantauan untuk mengakses Redis, cuba gunakan sambungan panjang untuk mengumpul maklumat status untuk mengelakkan sambungan pendek yang kerap. Pada masa yang sama, anda juga mesti memberi perhatian untuk mengawal kekerapan akses kepada Redis untuk mengelak daripada menjejaskan permintaan perniagaan.

Apabila menggunakan beberapa komponen pemantauan sumber terbuka, yang terbaik adalah memahami prinsip pelaksanaan komponen ini dan mengkonfigurasi komponen ini dengan betul untuk mengelakkan pepijat dalam komponen pemantauan, mengakibatkan sejumlah besar operasi Redis dalam tempoh yang singkat masa dan menjejaskan prestasi Redis berlaku.

Apa yang berlaku kepada kami pada masa itu ialah apabila DBA menggunakan beberapa komponen sumber terbuka, disebabkan oleh isu konfigurasi dan penggunaan, program pemantauan kerap ditubuhkan dan diputuskan sambungan daripada Redis, menyebabkan Redis bertindak balas dengan perlahan.

3) Program lain bersaing untuk mendapatkan sumber

Akhir sekali, saya perlu mengingatkan anda bahawa mesin Redis anda adalah yang terbaik dan hanya digunakan untuk menggunakan kejadian Redis Untuk aplikasi lain, cuba sediakan persekitaran yang agak "tenang" untuk Redis untuk menghalang program lain daripada menduduki CPU, memori dan sumber cakera, menyebabkan sumber tidak mencukupi diperuntukkan kepada Redis.

Pembelajaran yang disyorkan: Tutorial video Redis

Atas ialah kandungan terperinci Perbincangan ringkas tentang sebab mengapa Redis lambat dan cara menyelesaikannya. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!