Predis: Kesalahan saat membaca baris dari server

Sudahkah Anda mengikuti langkah-langkah yang dijelaskan di sini untuk men-debug masalah Anda sebelum membuka edisi baru dengan judul yang sama? Lihat juga utas ini di daftar Redis, mungkin juga sesuatu yang tidak terkait dengan masalah sisi klien.

Terima kasih nk. Saya akan mencoba mengatur socket_timeout dan read_write_timeout dan melaporkan temuan saya di sini nanti.

Jika Anda menggunakan Predis dalam skrip seperti daemon, Anda harus menyetel read_write_timeout ke -1 jika Anda ingin sepenuhnya menonaktifkan batas waktu (nilai ini berfungsi dengan versi Predis yang lebih lama dan lebih baru). Juga, ingat bahwa Anda harus menonaktifkan batas waktu default Redis dengan menyetel timeout = 0 di redis.conf atau Redis akan memutuskan koneksi klien yang tidak aktif setelah 300 detik tidak aktif.

nrk, coba seperti yang disebutkan dan sekarang berfungsi dengan baik. Terima kasih!

Namun, masih ada banyak waktu habis koneksi sekarang dan nanti. Saya sudah mengatur timeout = 0 dan read_write_timeout ke -1. Apakah ada yang bisa kita lakukan untuk men-debug ini ketika itu terjadi?

timeout bukan parameter koneksi yang dikenali oleh Predis, Anda harus menggunakan connection_timeout sebagai gantinya. Nilai default untuk connection_timeout adalah 5 detik, Anda dapat mencoba menaikkan nilainya tetapi menurut saya itu bukan solusi untuk masalah Anda. Anda harus mencoba dan melihat apa yang terjadi di server Anda ketika batas waktu itu terjadi, itu sangat tergantung pada aplikasi Anda jadi saya tidak dapat membantu apa pun. Kemungkinan alasan untuk batas waktu tersebut adalah:

1. masalah konektivitas jaringan jika server Redis Anda tidak ada di localhost
2. apakah Anda yakin Anda tidak menggunakan panggilan mahal ke perintah KEYS di suatu tempat di skrip Anda? Bergantung pada jumlah penyimpanan kunci di Redis, KEYS dapat berakhir dengan memblokir server yang, sementara itu, tidak akan dapat memproses permintaan lain atau koneksi masuk.

Saya akan membiarkan masalah ini terbuka untuk saat ini, tapi saya yakin itu pasti bukan sesuatu yang berhubungan dengan Predis.

nrk. Seperti yang disarankan, saya telah menaikkan connection_timeout menjadi 30. Akan memantau ini.

1. Ya, kami menggunakan beberapa redis node yang bukan localhost tetapi berada di jaringan pribadi (jadi setidaknya harus lebih stabil?)
2. Tidak menggunakan KUNCI. Namun, kami memotret setiap 900-an. Dari log tampak bahwa sistem membutuhkan waktu 8 detik untuk menyimpan ke HD. Seharusnya tidak menjadi penyebab koneksi timeout kan?
3. Adakah saran tentang cara memantau server ketika batas waktu terjadi? Waktu tunggunya cukup acak. Saya memeriksa log redis, dan kebanyakan itu hanya memotret pesan.

Pembaruan lain, saya mengukur koneksi, dan tampaknya memang pengecualian terjadi setelah 5 detik. Saya mencoba memodifikasi connection_timeout melalui:

new Predis_Client($param, array('read_write_timeout' => -1, 'connection_timeout' => 30));

Apakah itu benar? Tampaknya tidak berpengaruh pada 30-an connection_timeout dan masih menimbulkan pengecualian.

Mereka adalah parameter koneksi dan bukan opsi klien, jadi read_write_timeout dan connection_timeout harus ditentukan sebagai parameter di $param .

1. Kecuali jika itu bukan jaringan pribadi di Amazon EC2 (latensi tinggi dan berbagai masalah dari waktu ke waktu), maka seharusnya tidak.
2. Snapshotting seharusnya tidak memblokir server sejauh yang saya tahu
3. Anda dapat memeriksa pengaturan waktu batas waktu terhadap log snapshot. Selain itu, itu sangat tergantung pada arsitektur aplikasi dan infrastruktur Anda, maaf, tetapi saya tidak dapat memberikan dukungan untuk itu.

Sejujurnya, Predis tidak melakukan sesuatu yang mewah dengan sumber daya soket saat menghubungkan ke Host karena itu adalah sesuatu yang didelegasikan hampir seluruhnya ke internal PHP, jadi itu bisa berupa bug di PHP (tidak mungkin, tetapi masih ada kemungkinan) atau beberapa konfigurasi/runtime masalah di server Anda, atau Redis melakukan beberapa operasi berat yang akhirnya memblokir server untuk sementara waktu.

nrk, terima kasih lagi atas balasan Anda. Saya menemukan masalahnya, dan itu hanya server yang kehabisan masalah ip_conntrack. Setelah conntrack diperbaiki, batas waktu koneksi juga hilang.

Senang mengetahui bahwa Anda akhirnya menemukan masalah sebenarnya di balik batas waktu tersebut. Saya mungkin akan menambahkan ini di suatu tempat di FAQ untuk memberi pengguna daftar awal pemeriksaan untuk pemecahan masalah waktu habis.

mendapatkan kesalahan yang sama, diselesaikan menggunakan pengaturan read_write_timeout sebagai 0.
Saya melakukan itu di predis, bisakah kita melakukan hal yang sama menggunakan klien predis?
seperti yang ditunjukkan di sini http://code.google.com/p/dires/source/browse/trunk/predis/examples/PubSubContext.php?r=4
Saya membuat klien predis menggunakan : $redis = new Predis\Client("tcp://".$turboConfig->getActivitiesRedisHost()); bagaimana saya harus melewati read_write_timeout dalam implementasi saya.

@amitchhajer klien menerima parameter koneksi yang sama dengan array bernama atau string URI, jadi jika Anda menggunakan string URI, Anda bisa menambahkannya seolah-olah itu adalah string kueri: tcp://127.0.0.1:6379?read_write_timeout=0 .

@nrk terima kasih atas infonya, berfungsi dengan baik sekarang.

Bagaimana jika kita perlu mengubah read_write_timeout saat runtime? Apakah ada penyetel untuk parameter batas waktu (kecuali konstruktor)?

Parameter koneksi

$connection = $client->getConnection();
$stream = $connection->getResource();
stream_set_timeout($stream, 2);

Harap dicatat bahwa melakukan $connection->getResource() secara efektif memicu operasi connect() ke Redis sehingga Anda mungkin akan kehilangan manfaat dari koneksi lambat tergantung pada bagaimana Anda akan menggunakan fitur ini.

Harap perhatikan bahwa parameter connection_timeout telah diubah namanya menjadi timeout dalam versi baru Predis.

Saya menggunakan ' h keys' cukup ekstensif. Bisakah ini menyebabkan kunci?

Jika Anda menggunakan Predis dalam skrip seperti daemon, Anda harus menyetel read_write_timeout ke -1 jika Anda ingin sepenuhnya menonaktifkan batas waktu (nilai ini berfungsi dengan versi Predis yang lebih lama dan lebih baru). Juga, ingat bahwa Anda harus menonaktifkan batas waktu default Redis dengan menyetel timeout = 0 di redis.conf atau Redis akan memutuskan koneksi klien yang tidak aktif setelah 300 detik tidak aktif.

Adakah kelemahan atau kehati-hatian yang terkait dengan pengaturan timeout=0 di redis.conf ?

Yang saya curigai adalah .. karena koneksi tidak akan pernah putus
Pemanfaatan redis akan tetap tinggi

nrk, terima kasih lagi atas balasan Anda. Saya menemukan masalahnya, dan itu hanya server yang kehabisan masalah ip_conntrack. Setelah conntrack diperbaiki, batas waktu koneksi juga hilang.

Bagaimana cara memperbaiki kontrak ini .. di mana mencarinya?

Adakah kelemahan atau kehati-hatian yang terkait dengan pengaturan timeout=0 di redis.conf ?

@aditya-rewari-cb sebenarnya timeout = 0 di redis.conf adalah default sejak Redis 2.4 (dirilis beberapa tahun yang lalu) jadi saya akan mengatakan tidak ada kekurangan.

Jika Anda menggunakan Predis dalam skrip seperti daemon, Anda harus menyetel read_write_timeout ke -1 jika Anda ingin sepenuhnya menonaktifkan batas waktu (nilai ini berfungsi dengan versi Predis yang lebih lama dan lebih baru). Juga, ingat bahwa Anda harus menonaktifkan batas waktu default Redis dengan menyetel timeout = 0 di redis.conf atau Redis akan memutuskan koneksi klien yang tidak aktif setelah 300 detik tidak aktif.

@nrk Saya menggunakan Redis dengan proses daemon (pekerja pengawas laravel), serta , dengan caching biasa
Adakah peringatan untuk menggunakan 'read_write_timeout' => -1 ?
Saya ingin mengonfirmasi kemungkinan kerusakan atau bug .. dalam penggunaan Redis caching reguler saya, karena perubahan ini!

Terima kasih !