تشغيل الموقع وتوليد الصور على VPS واحد: تخطيط موارد يمنع توقف الموقع أثناء مهام الذكاء الاصطناعي

يمكن تشغيل الموقع وتوليد الصور على نفس VPS، لكن نجاح النموذج يتطلب تقسيم الموارد والمهام إلى فئات، وحفظ طوابير العمل، وعدم ربط استجابة المستخدم بسرعة مهام الذكاء الاصطناعي. إليك طريقة عملية للتخطيط وقياس السعة دون افتراض قيم تناسب كل خادم.

لماذا تتنافس الخدمات رغم اختلاف المهام؟

خادم VPS صغير قد يجمع موقعًا عامًا وقاعدة بيانات ومحرك بحث محلي وأتمتة وكيل ونظام إنشاء صور. كل خدمة لها إيقاع مختلف: موقع الويب يحتاج زمن استجابة قصيرًا ومستقرًا، أما توليد الصور فقد يستهلك CPU و RAM و I/O لفترات طويلة. لو أعطيت كل مهمة صلاحية استخدام جميع موارد الجهاز، فالمنافسة لا تُحل تلقائيًا لأن النظام لا يعرف أي خدمة أهم للمستخدم. ضع ميزانية معلنة للموارد لكل فئة قبل رفع التزامن.

للبدء قسم المهام إلى حرجة للزائر، ومهمة للعمل التجاري لكن غير فورية، وأعمال تحسين مؤجلة. خادم HTTP وقاعدة البيانات التي تخدمه في الفئة الأولى، بينما إنشاء صورة غلاف يمكن وضعه في طابور ثانٍ. هذا لا يعني إهمال الصور؛ بل يعني فصل موعد التوليد عن موعد ظهور المقال إذا كانت المنصة تسمح بصورة مؤقتة أو إرفاق لاحق موثق، مع تمييز ما يحتاج مراجعة بشرية للتحقق من الجودة.

ارسم خط أساس قبل تخصيص الحصص

قِس لمدة مناسبة أحمال اليوم الطبيعي وذروة الزيارات ووقت انتهاء التحديثات. اجمع memory available و RSS لأهم العمليات والقرص وال ـCPU وقياس زمن HTTP. لا تستخدم متوسط CPU وحده؛ فقد يختنق الموقع بسبب انتظار القرص أو قاعدة البيانات بينما يظهر المعالج غير مشغول. احسب ذروة الذاكرة لكل خدمة، لا حجمها وقت الخمول، وأضف احتياطيًا للنظام وكاش الملفات والزيادات العابرة.

كثير من الجداول تفشل لأنها تجمع قيمًا تخص أوقاتًا مختلفة أو تتجاهل الاستهلاك المشترك. مثلًا إذا كان التطبيق يحتاج 1 جيجابايت في الذروة وقاعدة البيانات 2 جيجابايت، فلا يعني بقاء 9 جيجابايت من خادم 12 جيجابايت أن من الآمن تخصيصها كلها لعمال الصور. اترك مساحة لطلبات جديدة وعمليات نسخ احتياطي وخدمات البنية، وابدأ بعامل توليد واحد حتى تثبت الحاجة والقدرة على الزيادة.

ميزانية الذاكرة هي قيد شامل وليست حدًا لكل عملية فقط

إذا وضعت MemoryMax=2G لكل وحدة عمل، يمكن لعشر وحدات أن تطلب معًا 20 جيجابايت، حتى لو كان الخادم كله 12 جيجابايت. الحل ليس إلغاء الحدود بل إضافة سقف إجمالي للتزامن أو تجميع العمال داخل cgroup لها حصة مشتركة. راجع وراثة الحدود لدى العمليات الفرعية وأي خدمات transient، لأن التنفيذ قد ينفصل عن العملية التي تحسبها في الطابور. والأفضل عد الوظائف النشطة بالفعل من مصدر واحد وتقديم حالة واضحة عند بلوغ الحد.

تذكر أن RSS للعملية ليس مجموعًا بسيطًا لاستهلاك كل الذاكرة عندما تشارك العمليات صفحات بينهما؛ لذلك راقب على مستوى النظام أيضًا. إذا بدأ swap يرتفع مع زيادة زمن الطلبات، تعامل مع الأمر باعتباره إشارة إلى قرب الإنهاك حتى إن كانت عمليات الخلفية لا تزال تعمل. إيقاف إطلاق المهام الجديدة أولًا يمنح الويب فرصة للحفاظ على الاستجابة.

ميزانية CPU والقرص والشبكة

إنتاج صورة قد يتضمن توليدًا عن بعد ثم تنزيلها وتحويلها إلى WebP ورفعها وفحصها، وقد تكون مرحلة التحويل المحلية هي الأعلى استهلاكًا للمعالج أو الذاكرة. ضع CPUQuota أو أولوية أقل لعمال الصور عند الحاجة، لكن راقب التأثير الفعلي لأن تقليل CPU بعنف قد يطيل مدة احتجاز الذاكرة. افصل الأعمال التي تتطلب قرصًا كثيفًا عن فترات النسخ الاحتياطي وقاعدة البيانات لتجنب تنازع I/O.

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

ضع طابور إنتاج صور مستقلًا عن النشر

يمكن أن يكون لكل مقال حالتان منفصلتان: editorialScheduled و imagesPending. عندما تكتمل الكتابة وتُحجز مواعيد النشر، تُنشأ مهام صور مفصلة لها imageSpec و articleId و role و priority. تتولى خدمة توليد الصور إنتاج الغلاف والصورة الداخلية وفق هذا الوصف، ثم تفحص مخرجاتها وتربطها بالمقال. لا تخزن مجرد عنوان المقال كتعليمات صورة؛ يجب وصف المشهد والمواد والزوايا والنص والمساحة الآمنة والعناصر الممنوعة.

لمنع إعادة إنشاء الصورة نفسها، استخدم هوية ثابتة تجمع المقال والدور والإصدار، مثل articleId+cover+revision1. ميّز بين صورة فشلت وصورة مولدة تنتظر الجودة وصورة تم رفعها وصورة تم ربطها ونشرها. لا تعتبر انتهاء أمر Codex دليلًا على ظهور الصورة على الموقع؛ اختبر الرابط العام ووسوم OG وصحة العرض فوق العنوان، وأعد ربط الصورة إذا انقطعت المزامنة بين قاعدة البيانات وخدمة الملفات.

الأولوية عند الضغط ليست بالضرورة للأقدم

عندما يزداد طابور الصور، أعط الأولوية لمقال سيُنشر قريبًا أو مقال منشور بلا غلاف، ثم تابع الصور الداخلية والتحسينات البصرية القديمة. احفظ قائمة انتظار قابلة للاستئناف بدلاً من نسخ عشرات المهام إلى جلسة طويلة من عامل واحد. احذر starvation حيث تبقى الصور القديمة مؤجلة إلى الأبد؛ يمكن وضع أولوية جديدة مع رفع تدريجي لأقدم عنصر حتى لا يُنسى.

لا تجعل إدخال 100 مقال دفعة واحدة يطلق 100 عملية توليد بالتوازي. الأفضل أن تكون هناك نقطة استلام واحدة تستخرج عنصرًا أو عنصرين وفق سعة الجهاز. وإذا كان النموذج الخارجي يعيد رفضًا مؤقتًا بسبب الحصة، فأجل العنصر مع backoff وأخبر نظام المتابعة بسبب التأخير، دون إعادة المحاولة في حلقة سريعة أو فتح عشرات جلسات بديلة.

حماية المسارات العامة من عمال الخلفية

عرف معيار أمان بسيطًا: إذا زاد معدل 5 xx أو زمن صفحة المقالات فوق حد يعتمد على قياس سابق، يقلل مشرف المهام الثقيلة التزامن أو يوقف مؤقتًا قبول أعمال جديدة. لا توقف الخادم العام كي تسمح لرسم غلاف بالاكتمال. يمكن تنفيذ هذا بمهام systemd محدودة وملفات حالة أو منظومة Queue متخصصة، بحسب حجم الفريق. الأهم وجود حدود صريحة وقرار تلقائي يستند إلى صحة الموقع لا إلى الرغبة في إنتاج أكبر عدد.

لا تعتمد فقط على Restart=always للعمال؛ فقد يقلب فشل اتصال خارجي إلى عاصفة إعادة تشغيل. استخدم فترات انتظار ومحدد محاولات وقفلًا يمنع تضارب نسخ العامل الواحد. وراجع سجلات المهلة ووحدات transient إذا كنت تستخدم وكيلًا برمجيًا يطلق عملية طرف ثالث. نجاح مهمة فردية لا يثبت أن النظام قادر على إنتاج مئات الصور باستمرار.

كيف تختبر التصميم قبل زيادة الإنتاج؟

شغّل موقعًا تجريبيًا أو فترة انخفاض زيارات مع عامل صورة واحد، وقِس زمن صفحات فعلية من خارج السيرفر. ثم ارفع التزامن بمقدار صغير وأعد القياس. اوقف الاختبار إذا بدأت مهلات قاعدة البيانات أو زاد swap أو فشلت طلبات الويب، ولا تتجاهل ذلك لأن عملية الصور انتهت لاحقًا. كرر سيناريو فصل الشبكة أثناء رفع الصورة وتحقق من أن إعادة المحاولة لا تنشئ ملفين مختلفين لنفس المقال بلا داعٍ.

اختبر أيضًا إلغاء المهمة: هل تنتهي العملية التابعة وتنظف ملفاتها المؤقتة، أم تبقى في قائمة العمليات؟ هل يحافظ الطابور على المقال وملف الصورة المؤقت إن كان قابلًا للاستئناف؟ هل تعيد خدمة المزامنة ارتباط الصورة عندما تعود قاعدة البيانات للعمل؟ هذه التفاصيل غالبًا أهم لتجربة حقيقية من السرعة القصوى لصورة واحدة في بيئة فارغة.

جدول سياسات عملية لخادم واحد

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

الجدول الذي يختصر القرار: الصفحة تعيد 200 لكن بطء الاستجابة يرتفع أثناء رسم الصور: قلل تزامن العمال وقِس؛ الصفحة تعيد 502 مع ارتفاع swap: أوقف تدفق الخلفية وافحص المنبع؛ Codex ينهي المهمة بلا ملف: تحقق من نتيجة التوليد ومسار الاستيراد؛ صورة مرفوعة لا تظهر: راجع ربط media_id بنسخة المقال وذاكرة CDN. لكل حالة اختبار إثبات مناسب، فلا تخلط بين نجاح توليد الصورة ونجاح نشرها.

معيار النجاح في دورة 48 ساعة

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

راجع أدلة systemd.resource-control و Google SRE عن overload و Backpressure، ووثائق Node.js لتفسير استهلاك العمليات. وأخيرًا احرص أن يكون الفريق قادرًا على إيقاف طابور الصور وحده وقت طارئ دون خسارة المواصفات المحفوظة. هذه هي فائدة فصل الكتابة والجدولة عن التصوير: استمرار نشر المعرفة دون جعل توليد عنصر بصري واحد سببًا في توقف منصة كاملة.