مقالات عملية مرتبة حسب المجال والمستوى، اختر المجال المناسب واقرأ من مستوى مبتدئ إلى محترف.
تطبيقك بيرمي too many clients وقت الذروة والسيرفر مرتاح؟ السبب إن كل اتصال بيفتح عملية كاملة في Postgres. اعرف تركّب PgBouncer بنمط transaction pooling وتنزّل 600 اتصال لـ 20 اتصال حقيقي في أقل من 10 دقايق، بمثال بسيط ثم شرح علمي، إعداد قابل للنسخ، أرقام قبل وبعد، trade-offs، ومتى لا تستخدمه، مع مصادر رسمية.
سيرفرك بيرفض اتصالات جديدة والـ CPU والرام مرتاحين؟ غالبًا جدول nf_conntrack امتلأ فبيدروب كل SYN جديد. مقال للمحترف يشرح تتبّع الاتصال بمثال دفتر الفندق، ثم علميًا، مع أوامر تشخيص، ثلاث روافع حل (رفع السقف، تقليل الـ timeouts، NOTRACK) بأرقام حقيقية للذاكرة، trade-offs، ومتى لا تستخدمها، مع مصادر رسمية.
لو تطبيقك يرمي EMFILE فجأة والـ CPU مرتاح، المشكلة في سقف واصفات الملفات (1024 الافتراضي). اكتشفها بأمر واحد واضبط LimitNOFILE صح، مع الفرق بين تسريب الواصفات ورفع الحد.
لو السيرفر رفض الكتابة بـ No space left on device و df -h يقول عندك مساحة، المشكلة إنك خلّصت الـ inodes مش المساحة. اكتشفها بـ df -i وحلّها خطوة بخطوة.
لو نداءاتك بين الخدمات بطيئة وCoreDNS عليه ضغط غريب، غالبًا السبب إعداد ndots:5 اللي بيحوّل كل بحث DNS لـ 4 أو 5 استعلامات. اتعلّم تكتشفها وتصلّحها بـ FQDN وdnsConfig وNodeLocal DNSCache بأرقام وأوامر قابلة للنسخ.
لو الـ Pod بيدخل في حلقة restart أو بيرمي 502 وهو لسه بيقلّع، المشكلة غالبًا في ضبط الـ probes. اضبط liveness و readiness و startup صح بمثال بسيط وكود YAML قابل للنسخ وأرقام حقيقية.
لو الـ Pod بيموت بـ Exit 137 من غير سبب واضح، المشكلة إنه تخطّى حدّ الذاكرة فقتله الكيرنل. هنا تفهمها بمثال بسيط، تكتشفها بأمر واحد، وتصلّحها بضبط requests وlimits صح، بأرقام ومصادر رسمية.
عمليات Zombie بتتراكم لمّا تطبيقك يشتغل كـ PID 1 جوّه Docker من غير ما يحصدها، لحد ما جدول العمليات يمتلي وأي fork جديد يفشل. اعرف السبب على مستوى الكيرنل، وإزاي --init و tini يحلّوها في سطر واحد، مع أرقام قبل وبعد ومصادر.