أرى هذه الأخطاء في السجلات بعد التحديث إلى 2026.4.1(e404d9aabc) مؤخرًا:
رسالة (تم الإبلاغ عن 151769 نسخة)
استثناء المهمة: لا يمكن تخصيص خيط
سجل التتبع
/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'Thread.new'
/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'block in Socket.tcp_with_fast_fallback'
/usr/local/lib/ruby/3.4.0/socket.rb:710:in 'Array#map'
/usr/local/lib/ruby/3.4.0/socket.rb:710:in 'Socket.tcp_with_fast_fallback'
/usr/local/lib/ruby/3.4.0/socket.rb:661:in 'Socket.tcp'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/ruby_connection.rb:122:in 'RedisClient::RubyConnection#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/ruby_connection.rb:48:in 'RedisClient::RubyConnection#initialize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:849:in 'Class#new'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:849:in 'block in RedisClient#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/middlewares.rb:12:in 'RedisClient::BasicMiddleware#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:848:in 'RedisClient#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:824:in 'RedisClient#raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:779:in 'RedisClient#ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:372:in 'RedisClient#call_v'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis/client.rb:90:in 'Redis::Client#call_v'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/rack-mini-profiler-4.0.1/lib/mini_profiler/profiling_methods.rb:90:in 'block in Redis::Client#profile_method'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:152:in 'block in Redis#send_command'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:151:in 'Monitor#synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:151:in 'Redis#send_command'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis/commands/keys.rb:256:in 'Redis::Commands::Keys#del'
/var/www/discourse/lib/discourse_redis.rb:168:in 'block in DiscourseRedis#del'
/var/www/discourse/lib/discourse_redis.rb:29:in 'DiscourseRedis.ignore_readonly'
/var/www/discourse/lib/discourse_redis.rb:165:in 'DiscourseRedis#del'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/distributed_mutex.rb:48:in 'MiniScheduler::DistributedMutex#synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/distributed_mutex.rb:15:in 'MiniScheduler::DistributedMutex.synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:365:in 'MiniScheduler::Manager#lock'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:316:in 'MiniScheduler::Manager#tick'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler.rb:74:in 'block (2 levels) in MiniScheduler.start'
اس_المضيف ip-172-x-x-x-app
معرف_العملية 286281
إصدار_التطبيق 3532c825824ee1259628545c7bd5311ecb918009
قاعدة_البيانات_الحالية default
اس_المضيف_الحالي discussion.mcebuddy2x.com
الرسالة أثناء تشغيل مدير الجدولة
الوقت 7:57 مساءً
من المرجح أن يكون هذا قيدًا على موارد الخادم الخاص بك. ما الذي تشغله الذاكرة العشوائية (RAM) حاليًا؟ هل تملك أي تفاصيل عن القطرة (droplet) التي تعمل عليها؟
هذا يُظهر الحد الأقصى لعدد عمليات/خيوط المستخدم المسموح بها.
ulimit -a
هذا يُظهر جميع حدود الموارد.
cat /sys/fs/cgroup/pids.max
هذا يتحقق من الحد الأقصى لعدد العمليات (PIDs) المسموح به لحاوية أو نظام cgroup.
الآن استخدم logout للعودة إلى المضيف:
systemctl show docker | grep TasksMax
هذا يتحقق مما إذا كان systemd قد فرض حدًا للمهام/الخيوط على خدمة Docker.
systemctl show containerd | grep TasksMax
هذا يقوم بنفس نوع الفحص، لكن لخدمة containerd بدلاً من Docker مباشرةً.
docker inspect app | grep -i pid
هذا يتحقق من حدود وإعدادات العمليات/معرفات العمليات (PIDs) لحاوية Discourse الخاصة بك. الأمر grep -i pid: يقوم بفلترة أي شيء يحتوي على «pid» (بغض النظر عن حالة الأحرف).
إذا استمر ظهور الأخطاء، يرجى لصق مخرجات هذه الأوامر هنا، فهذا سيكون مفيدًا.
يبدو أن إعادة البناء من واجهة سطر الأوامر قد حلّت المشكلة. سأواصل مراقبتها. يبدو أن شيئًا ما يتعلق بتحديث المتصفح من النسخة التجريبية إلى النسخة المستقرة خلال الأسبوع الماضي هو ما أثار هذه المشكلة.
هل يجب أن تكون هناك قيود على ترقية المتصفح؟ هل يمكن لترقية المتصفح اكتشاف المشكلات المحتملة وإبرازها أو منع حدوث الترقية؟
من المرجح أن إعادة البناء أعادت تعيين موضع cgroup للحاوية، مما يفسر استقرارها مرة أخرى.
نظرًا لوجود أخطاء “can’t alloc thread” الأصلية، ولأن كل شيء آخر (ulimits، TasksMax، معرّفات عمليات Docker) غير محدود، فإن المشتبه به المتبقي هو ضغط cgroup الخاص بمعرّفات العمليات (PIDs).
إذا كان pids.current يقترب من ~2000+ مقارنة بحد أقصى يبلغ ~2285، فسيكون ذلك تأكيدًا على أن الحاوية كانت تصل إلى سقف معرّفات العمليات في cgroup خلال دفعات إعادة الاتصال بجدول المواعيد / Redis.
هذا سيُفسّر أيضًا سبب ظهور المشكلة فقط بعد الترقية (زيادة في تبديل الخيوط)، ولماذا أدت إعادة البناء إلى تنظيفها مؤقتًا.
كم عدد العمليات (معرّفات العمليات/الخيوط) التي تعمل حاليًا داخل الحاوية/cgroup ↩︎
الحد الأقصى لعدد العمليات (معرّفات العمليات/الخيوط) المسموح به في تلك الحاوية (الحاوية الخاصة بك) ↩︎
شكرًا - هذا يستبعد ضغط PID الحالي بعد إعادة البناء.
بما أن pids.current هو فقط 227 مقابل 4194304، فإن الحاوية بالتأكيد ليست قريبة من الحد الأقصى لـ PID في cgroup الآن.
الجزء المثير للاهتمام هو أن pids.max السابق كان يبدو أنه 2285، بينما بعد إعادة البناء أصبح الآن 4194304. لذا، قد تكون إعادة البناء قد أعدت تعيين حد cgroup (أي تجديد حاوية التطبيق)، وهذا يفسر سبب عدم وجود دليل على مشكلة استنفاد نشطة لـ PID في الوقت الحالي.
إذا عاد الخطأ، سيكون من المفيد نسخ ولصق هذه الأوامر في الوقت الذي يفشل فيه:
cat /sys/fs/cgroup/pids.current
cat /sys/fs/cgroup/pids.max
ps -eLf | wc -l
هذا سيوضح ما إذا كان الفشل ناتجًا عن ضغط PID، أم أننا يجب أن ننظر في مكان آخر🙂
