Predis: خطأ أثناء قراءة السطر من الخادم

هل اتبعت بالفعل الخطوات الموضحة هنا لتصحيح مشكلتك قبل فتح مشكلة جديدة بنفس العنوان؟ راجع أيضًا هذا الموضوع في قائمة Redis ، فقد يكون أيضًا شيئًا لا علاقة له بقضايا جانب العميل.

شكرا لك. سأحاول ضبط socket_timeout و read_write_timeout وإبلاغ النتائج التي توصلت إليها هنا لاحقًا.

إذا كنت تستخدم Predis في نص برمجي يشبه البرنامج الخفي ، فيجب عليك تعيين read_write_timeout إلى -1 إذا كنت تريد تعطيل المهلة تمامًا (تعمل هذه القيمة مع الإصدارات الأقدم والأحدث من Predis). تذكر أيضًا أنه يجب عليك تعطيل المهلة الافتراضية لـ Redis عن طريق تعيين timeout = 0 في redis.conf أو سيقوم

nrk ، جرب كما ذكرنا وهو يعمل الآن بشكل مثالي. شكرا لك!

ومع ذلك ، لا يزال هناك الكثير من مهلات الاتصال بين الحين والآخر. لقد قمت بالفعل بتعيين timeout = 0 و read_write_timeout على -1. هل هناك أي شيء يمكننا القيام به لتصحيح هذا عند حدوثه؟

timeout ليس معلمة اتصال يتعرف عليها Predis ، يجب عليك استخدام connection_timeout بدلاً من ذلك. القيمة الافتراضية لـ connection_timeout هي 5 ثوانٍ ، يمكنك محاولة رفع قيمتها ولكن لا أعتقد أنه حل لمشكلتك. يجب أن تحاول معرفة ما يحدث على الخادم الخاص بك عند حدوث هذه المهلات ، فهذا يعتمد حقًا على التطبيق الخاص بك لذلك لا يمكنني تقديم أي مساعدة. يمكن أن تكون الأسباب المحتملة لهذه المهلات:

1. مشكلات اتصال الشبكة إذا لم يكن خادم Redis على المضيف المحلي
2. هل أنت متأكد من أنك لا تستخدم مكالمات باهظة الثمن للأمر KEYS في مكان ما في نصوصك؟ اعتمادًا على عدد المفاتيح المخزنة في Redis ، يمكن أن يؤدي KEYS إلى حظر الخادم الذي ، في هذه الأثناء ، لن يكون قادرًا على معالجة الطلبات الأخرى أو الاتصالات الواردة.

سأترك هذه المشكلة مفتوحة في الوقت الحالي ، لكنني متأكد تمامًا من أنها ليست شيئًا متعلقًا بـ Predis.

nrk. كما نصحنا ، رفعتُ Connection_timeout إلى 30. سأراقب هذا.

1. نعم ، نحن نستخدم عدة عقد redis ليست مضيفة محلية لكنها على شبكة خاصة (لذلك على الأقل يجب أن تكون أكثر استقرارًا؟)
2. عدم استخدام المفاتيح. ومع ذلك ، نحن نلتقط كل 900 ثانية. من السجل ، يبدو أن النظام يستغرق 8 ثوانٍ للحفظ على HD. ألا يجب أن يكون سبب انتهاء مهلة الاتصال صحيحًا؟
3. أي نصيحة حول كيفية مراقبة الخادم عند حدوث المهلة؟ المهلة عشوائية جدًا. لقد تحققت من سجل redis ، وهو في الغالب مجرد لقطات للرسائل.

تحديث آخر ، قمت بقياس الاتصال ، ويبدو أن الاستثناء حدث بالفعل بعد 5 ثوانٍ. حاولت تعديل connection_timeout عبر:

جديد Predis_Client ($ param، array ('read_write_timeout' => -1، 'connection_timeout' => 30)) ؛

هل هذا صحيح؟ لا يبدو أنه يسري مفعول 30s connection_timeout ولا يزال يطرح الاستثناءات.

إنها معلمات اتصال وليست خيارات عميل ، لذلك يجب تحديد read_write_timeout و connection_timeout كمعلمات في $param .

1. ما لم تكن شبكة خاصة على Amazon EC2 (زمن انتقال مرتفع ومشكلات متنوعة من وقت لآخر) ، فلا ينبغي أن تفعل ذلك.
2. لا يجب أن يؤدي الالتقاط إلى حظر الخادم على حد علمي
3. يمكنك التحقق من توقيتات المهلات مقابل سجلات اللقطات. بخلاف ذلك ، يعتمد الأمر حقًا على بنية التطبيق والبنية التحتية الخاصة بك ، آسف ولكن لا يمكنني تقديم الدعم لك في ذلك.

بصراحة ، لا يفعل Predis أي شيء خيالي مع موارد المقبس عند الاتصال بمضيف لأنه شيء يتم تفويضه بالكامل تقريبًا إلى عناصر PHP الداخلية ، لذلك يمكن أن يكون خطأ في PHP (غير مرجح ، ولكن لا يزال احتمالًا) أو بعض التكوين / وقت التشغيل مشكلة على خوادمك ، أو يقوم Redis ببعض العمليات الثقيلة التي تنتهي بحجب الخادم لفترة من الوقت.

nrk ، شكرا لك مرة أخرى على ردك. لقد وجدت المشكلة ، وهي فقط الخادم الذي نفد من مشكلة ip_conntrack. بمجرد إصلاح conntrack ، تنتهي مهلة الاتصال أيضًا.

من الجيد معرفة أنك قد وجدت أخيرًا المشكلة الفعلية وراء هذه المهلات. ربما سأضيف هذا في مكان ما في الأسئلة الشائعة لمنح المستخدمين قائمة أولية بالفحوصات لاستكشاف مشكلات المهلة وإصلاحها.

حصل على نفس الخطأ ، تم حله باستخدام إعداد read_write_timeout على أنه 0.
لقد فعلت ذلك في بريدس ، هل يمكننا فعل الشيء نفسه باستخدام عميل بريدس؟
كما هو موضح هنا http://code.google.com/p/dires/source/browse/trunk/predis/examples/PubSubContext.php؟r=4
أقوم بعمل عميل بريد بريديس باستخدام: $ redis = new Predis \ Client ("tcp: //". $ turboConfig-> getActivitiesRedisHost ())؛ كيف يمكنني تمرير read_write_timeout في التنفيذ الخاص بي.

amitchhajer ، يقبل العميل نفس معلمات الاتصال مع كل من المصفوفات المسماة أو سلاسل URI ، لذلك إذا كنت تستخدم سلسلة URI ، فيمكنك فقط إضافتها كما لو كانت سلسلة استعلام: tcp://127.0.0.1:6379?read_write_timeout=0 .

شكرا nrk للمعلومات ، يعمل بشكل جيد الآن.

ماذا لو احتجنا إلى تغيير read_write_timeout في وقت التشغيل؟ هل يوجد معين محدد لمعلمات المهلة (باستثناء المنشئ)؟

معلمات اتصال bondeg غير قابلة للتغيير عن قصد مما يعني أنه لا يمكنك تغييرها بمجرد تهيئة الاتصال ، ولكن يمكنك التغلب على هذا القيد عن طريق جلب مورد الدفق الأساسي من كائن الاتصال الذي يستخدمه العميل وتغيير خيارات الدفق وفقًا لذلك. فيما يلي مقتطف صغير ، بافتراض أنك لا تستخدم العميل في وضع المجموعة أو النسخ المتماثل:

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

يرجى ملاحظة أن إجراء $connection->getResource() يؤدي بشكل فعال إلى تشغيل عملية connect() لـ Redis ، لذا فقد ينتهي بك الأمر بفقدان مزايا الاتصالات البطيئة اعتمادًا على كيفية استخدامك لهذه الميزة.

يرجى ملاحظة أنه تمت إعادة تسمية المعلمة connection_timeout إلى timeout في الإصدار الجديد من Predis.

أنا أستخدم "مفاتيح h " على نطاق واسع جدًا. يمكن أن يؤدي هذا إلى أقفال؟

إذا كنت تستخدم Predis في نص برمجي يشبه البرنامج الخفي ، فيجب عليك تعيين read_write_timeout إلى -1 إذا كنت تريد تعطيل المهلة تمامًا (تعمل هذه القيمة مع الإصدارات الأقدم والأحدث من Predis). تذكر أيضًا أنه يجب عليك تعطيل المهلة الافتراضية لـ Redis عن طريق تعيين timeout = 0 في redis.conf أو سيقوم

هل هناك أي عيب أو تحذير مرتبط بتعيين timeout = 0 في redis.conf؟

ما أظن أنه .. لأن الاتصالات لن تنقطع أبدًا
سيبقى استخدام Redis مرتفعًا

nrk ، شكرا لك مرة أخرى على ردك. لقد وجدت المشكلة ، وهي فقط الخادم الذي نفد من مشكلة ip_conntrack. بمجرد إصلاح conntrack ، تنتهي مهلة الاتصال أيضًا.

كيف تصلح هذا العقد .. أين تبحث؟

هل هناك أي عيب أو تحذير مرتبط بتعيين timeout = 0 في redis.conf؟

@ aditya-Rewari-cb في الواقع timeout = 0 في redis.conf هو الخيار الافتراضي منذ Redis 2.4 (تم إصداره قبل بضع سنوات) لذلك أقول أنه لا توجد عيوب.

إذا كنت تستخدم Predis في نص برمجي يشبه البرنامج الخفي ، فيجب عليك تعيين read_write_timeout إلى -1 إذا كنت تريد تعطيل المهلة تمامًا (تعمل هذه القيمة مع الإصدارات الأقدم والأحدث من Predis). تذكر أيضًا أنه يجب عليك تعطيل المهلة الافتراضية لـ Redis عن طريق تعيين timeout = 0 في redis.conf أو سيقوم

nrk أنا معالجة خفية (عمال مشرف Laravel) ، بالإضافة إلى التخزين المؤقت المنتظم
هل من الحذر عند استخدام "read_write_timeout" => -1؟
كنت أرغب في تأكيد أي احتمال للكسر أو الخطأ .. في استخدامي المعتاد للتخزين المؤقت لـ Redis ، بسبب هذا التغيير!

شكرا !