يا هلا بيك يا بشمهندس! لو بتكتب سكربتات PHP طويلة الأمد (Long-running scripts)، زي الـ Daemon processes اللي بتشتغل في الخلفية، أو نظام طوابير الانتظار (Message Queues) زي Laravel Horizon أو RabbitMQ workers، غالباً قابلتك المشكلة المرعبة دي: السكربت بيبدأ يشتغل زي الفل، وفجأة تلاقي استهلاك الرام (Memory Consumption) طالع في العالي لحد ما السيرفر يهنج أو الـ OOM Killer (Out Of Memory Killer) يعمل كراش للابليكيشن.

المشكلة دي بتظهر عشان لغة PHP متصممة في الأصل إنها تنظف الـ Memory بتاعتها لوحدها بعد ما أي HTTP Request يخلص. لكن لما السكربت يشتغل لفترة طويلة من غير ما يقفل، الـ Garbage Collector بيتلخبط، وهنا بيحصل تسريب الذاكرة أو ما يُعرف بـ (Memory Leaks). في المقال ده، هنتكلم بالتفصيل وبالعامية المصرية البسيطة عن إزاي تكتشف المشكلة دي وتحلها باحترافية.

إيه هو أصل الحكاية؟ وليه الـ Memory Leaks بتحصل في الـ PHP؟

في الـ Web Requests العادية، إنت مش بتشيل هم الـ Memory Leak قوي، لأن السيرفر بيقفل الـ Process ويفضي الرام أول ما الـ Request يخلص. لكن في السكربتات اللي بتشتغل كـ (Daemon Processes)، الـ Process بتفضل مفتوحة لأيام وأسابيع.

تسريب الذاكرة (Memory Leak) معناه إن السكربت بيحجز مساحة في الرام عشان يعمل عملية معينة، وبعد ما يخلص، بينسى يشيل البيانات دي أو يحررها (Free memory). النتيجة؟ مع كل لفة (Iteration) في الـ Loop، استهلاك الرام بيزيد لحد ما الـ MemoryLimit تخلص.

الأسباب الشهيرة للموضوع ده هي:

• الـ Global Variables أو الـ Static Variables اللي بتفضل متخزنة جوه الرอม طول فترة تشغيل السكربت.
• الدورات الدائرية للبيانات (Circular References) اللي الـ Garbage Collector أحياناً بيعجز عن تنظيفها لوحده.
• فتح قواعد بيانات أو اتصال بـ (Database Connections) وتخزين الـ Results جوه Array كبيرة من غير ما تفضيها أول بأول.

ازاي تراقب استهلاك الرام جوه السكربت؟ (Memory Monitoring)

أول خطوة عشان تحل المشكلة هي انك تراقبها عينك بعينك جوه الكود. لغة PHP بتوفر لنا دوال جاهزة وممتازة جداً عشان نعرف السكربت بيستهلك قد إيه رام في اللحظة دي.

تعال نشوف مثال عملي لإزاي تستخدم دالة memory_get_usage() جوه الـ Loop بتاعتك:

while (true) {
    // شغل الـ Worker الأساسي هنا
    processQueueJob();

    // طباعة استهلاك الرام بالميجابايت
    $memoryUsage = memory_get_usage(true) / 1024 / 1024;
    echo "Current Memory Usage: " . round($memoryUsage, 2) . " MB\n";

    // تنظيف إجباري للـ Garbage Collector
    gc_collect_cycles();
}

الدالة دي هتعرفك فوراً لو الرام في صعود مستمر من غير ما تنزل، ودي أول علامة واضحة على وجود (Memory Leak).

أهم الأدوات لاكتشاف وتحليل الـ Memory Leaks في الـ PHP

لو السكربت كبير ومعقد ومش عارف مكان التسريب بالظبط، هتضطر تستخدم أدوات احترافية (Debugging Tools) تساعدك تدخل جوه اعماق الرام.

1. استخدام Xdebug مع Webgrind

أداة الـ (Xdebug) مش بس للـ Breakpoints، دي كمان بتقدر تعمل بيها Profile لاستهلاك الذاكرة. بتطلع لك تقرير مفصل (Memory Profiling) بيعرفك كل دالة (Function) أو كلاس استهلكت قد إيه من الذاكرة بالظبط.

2. إضافة Memprof

مكتبة (Memprof) دي عبارة عن PHP Extension مخصصة تماماً لاكتشاف تسريب الذاكرة. بتعمل تتبع لكل مكان تم فيه حجز رام وما اتعملوش Free، وبتطلع لك النتيجة في ملف تقدر تحلله بسهولة.

أفضل الممارسات (Best Practices) لمنع الـ Memory Leaks في الـ Daemons

الوقاية خير من العلاج، وعشان تريح دماغك من الكراشات المفاجئة، اتبع القواعد البسيطة دي في كتابة سكربتات الـ PHP طويلة الأمد:

• إعادة تشغيل السكربت دورياً (Restart the Daemon): استخدم أدوات زي Supervisor. خلي السكربت يقفل لوحده أو يعمل Restart بعد ما يخلص عدد معين من المهام (Jobs) أو بعد مرور وقت محدد. دي أسهل وأضمن طريقة.
• استخدام unset(): لو عندك متغيرات كبيرة أو الـ Results بتاعة داتا بيس ضخمة، اول ما تخلص شغل بيها اعمل لها unset($variable) فوراً عشان تفضي الرام.
• تجنب Global State: حاول تبعد عن تخزين البيانات لفترات طويلة في متغيرات عامة، وخلي شغلك كله (Scope-limited).

خاتمة ونصيحة أخوية

يا بشمهندس، الـ Memory Leaks ممكن تكون من أعقد المشاكل اللي بتواجه المطورين لأنها مش بتظهر فوراً وقت الـ Testing المحلي، دي بتظهر في الإنتاج (Production) بعد ما السكربت يشتغل ساعات طويلة. الصبر والتتبع بالأدوات هو مفتاح الحل. دائماً صمم سكربتات الـ Queues بتاعتك وهي حاطة في اعتبارها إن السيرفر مش هيديها مساحة رام غير محدودة.