النتيجة التي تريدها ليست مجرد "اختفاء التحذير". الحل الصحيح يعني أن عملية PHP التي تُشغّل ownCloud 10 تُبلغ عن حد ذاكرة لا يقل عن 512 ميجابايت، وأن تحذير مسؤول ownCloud يختفي، وأن المهام المجدولة أو مهام سطر الأوامر تستخدم حدًا مناسبًا أيضًا، وأن المضيف لا يزال لديه ذاكرة فعلية كافية لتشغيل PHP وخادم الويب وقاعدة البيانات والمهام الخلفية دون استخدام مكثف للذاكرة الافتراضية.
في إصدار ownCloud Classic 10.16، تستخدم بيئة Docker الرسمية OWNCLOUD_MEMORY_LIMIT=512Mملفًا افتراضيًا موصى به. كما تُفرّق وثائق ownCloud بين إعدادات PHP المستخدمة من قِبل خادم الويب وتلك المستخدمة من قِبل النظام php-cli. هذا التمييز هو السبب الرئيسي وراء قيام المسؤولين أحيانًا بتغيير ملف الإعدادات memory_limit، وإعادة تشغيل الخدمة، ومع ذلك يظلون يرون نفس التحذير.
يبدأ هذا الدليل بالفحوصات الأقل إزعاجًا، ثم يعرض مسارات Apache وPHP-FPM وCLI وDocker. كما يشرح متى يكون رفع الحد مبررًا، ومتى تكون المشكلة الحقيقية هي عدم كفاية ذاكرة الوصول العشوائي (RAM) الخاصة بالمضيف وليس إعدادات PHP نفسها.
| يفحص | نتيجة جيدة | إذا فشل |
|---|---|---|
| نظرة عامة على إدارة ownCloud | لا يوجد تحذير "حد ذاكرة PHP أقل من القيمة الموصى بها" | ربما قمت بتعديل إعدادات PHP الخاطئة أو لم تقم بإعادة تشغيل الخدمة الصحيحة. |
| بيئة تشغيل PHP للويب | memory_limitيعرض 512 ميجابايت أو أعلى | ابحث عن ملف التكوين المحمّل المستخدم بواسطة طلب الويب. |
| بيئة تشغيل CLI / cron | php -r 'echo ini_get("memory_limit");'يُظهر القيمة المقصودة | قم بتعديل ما يتعلق بواجهة سطر الأوامر php.iniأيضًا. |
| ذاكرة المضيف | ذاكرة وصول عشوائي كافية متاحة؛ ضغط تبديل منخفض أو معدوم | لا تستمر في زيادة حدود PHP بشكل عشوائي. راجع عدد عمال PHP أو حجم الاستضافة. |
| سجلات | لا توجد أخطاء متكررة من نوع "نفاد حجم الذاكرة المسموح به". | حدد عبء العمل الذي يستهلك الذاكرة قبل رفع الحد مرة أخرى. |
افتح إعدادات إدارة ownCloud ولاحظ تحذير حد الذاكرة. قبل إجراء أي تغيير، سجّل إصدار ownCloud، وإصدار PHP، ونوع خادم الويب، وحد الذاكرة الحالي. هذا يُعطيك بيانات أساسية ويساعد على تجنّب تغيير تثبيت PHP الخاطئ على الأنظمة التي تحتوي على إصدارات PHP متعددة.
تشير وثائق ownCloud الحالية (الإصدار 10.16) إلى أن متطلبات الخادم تعتمد بشكل كبير على عدد المستخدمين، وعدد الملفات، ومستوى النشاط. ويُحدد إعداد Docker الخاص بها هذا الإعداد OWNCLOUD_MEMORY_LIMIT=512Mالافتراضي ويوصي بالاحتفاظ به. وهذا يجعل 512 ميجابايت حدًا أدنى معقولًا لحل التحذير، ولكنه لا يضمن أن جميع أحمال العمل ستناسب هذا الحجم.
المراجع الرسمية: توصيات نشر ownCloud ومتغيرات بيئة Docker الخاصة بـ ownCloud .
php --iniيُبلغ التقرير عن إعدادات واجهة سطر الأوامر PHP. وقد تختلف هذه الإعدادات عن إعدادات PHP المستخدمة من قِبل Apache أو PHP-FPM لخدمة ownCloud.قم بتشغيل هذه الأوامر لمعرفة ما يستخدمه برنامج PHP في سطر الأوامر:
php --ini
php -r 'echo ini_get("memory_limit"), PHP_EOL;'يُعدّ هذا مفيدًا occلمهام cron، ولكنه لا يُثبت ما يستخدمه طلب الويب. تُوثّق ownCloud صراحةً مسارات التكوين المنفصلة مثل:
/etc/php/<version>/apache2/php.ini
/etc/php/<version>/fpm/php.ini
/etc/php/<version>/cli/php.iniإذا كانت واجهة سطر الأوامر (CLI) الخاصة بك تُظهر 512 ميجابايت بينما لا تزال صفحة الإدارة تُظهر خطأً، فإن هذا التناقض يُعد علامة قوية على أن خادم الويب يقوم بتحميل ملف آخر php.ini.
راجع ملاحظات تكوين PHP الخاصة بـ ownCloud ، والتي تحذر تحديدًا من أنه قد يلزم تغيير إعدادات PHP في أكثر من ملف INI واحد.
الاختبار الأكثر موثوقية هو فحص كود PHP من نفس بيئة تطوير الويب التي تُشغّل منصة ownCloud. توضح وثائق ownCloud كيفية استخدام phpinfo.phpصفحة مؤقتة:
<?php phpinfo(); ?>ضعه مؤقتًا في جذر الموقع، وافتحه في متصفح، ثم حدد موقعه:
ثم احذف ملف phpinfo فورًا . يحذر ownCloud من أن ترك صفحة phpinfo عامة يعرض معلومات حساسة للخادم.
إذا قال المتصفح /etc/php/7.4/fpm/php.iniبينما php --iniيقول /etc/php/7.4/cli/php.ini، فأنت الآن تعرف بالضبط لماذا لم يؤدِ تعديل ملف CLI إلى إزالة التحذير.
php.iniأو تجاوز المجموعة/الموقع المناسب، وليس فقط ملف CLI.في تثبيت نموذجي لنظامي ديبيان أو أوبونتو:
sudo nano /etc/php/7.4/fpm/php.iniيجد:
memory_limit = 128Mوقم بتغييره إلى:
memory_limit = 512Mاستخدم إصدار PHP المثبت لديك في المسار. ثم أعد تشغيل خدمة FPM الصحيحة وخادم الويب الخاص بك إذا لزم الأمر.
sudo systemctl restart php7.4-fpm
sudo systemctl reload nginxبالنسبة لـ Apache مع proxy_fcgiإعداد FPM آخر، أعد تشغيل PHP-FPM وأعد تحميل Apache بدلاً من ذلك.
تُشير ownCloud أيضًا إلى أن PHP-FPM لا يستخدم إعدادات PHP من ملف .htaccess. إذا كنت تعتمد على تجاوزات لكل دليل مع FPM، فاستخدم آلية تكوين PHP/FPM المدعومة لبيئتك، مثل ملف .config php.iniأو تكوين مجموعة الخوادم المناسب .user.ini.
إذا كان برنامج Apache يقوم بتحميل PHP مباشرةً كوحدة نمطية، فقم بتحرير الملف الخاص بـ Apache:
sudo nano /etc/php/7.4/apache2/php.iniتعيين:
memory_limit = 512Mثم أعد تشغيل أباتشي:
sudo systemctl restart apache2لا تقم بنسخ رقم الإصدار آليًا. تحقق من الإصدار الذي تم تحميله فعليًا بواسطة Apache. غالبًا ما تحتفظ الأنظمة التي تمت ترقيتها عبر عدة إصدارات من PHP بمجلدات متعددة ضمن /etc/php/.
معيار النتيجة بسيط: بعد إعادة التشغيل، يجب أن يُظهر وقت تشغيل PHP المُتاح للويب القيمة الجديدة. إذا استمر في إظهار 128 ميجابايت، فهذا يعني أن طبقة تكوين أخرى تتجاوز تعديلك.
يتم تشغيل تحذير الويب الخاص بالمسؤول بواسطة وقت تشغيل الويب، ولكن occمهام cron تستخدم PHP CLI. تشير وثائق ownCloud إلى ذلك بشكل صريح.
يحرر:
sudo nano /etc/php/7.4/cli/php.iniتعيين:
memory_limit = 512Mثم تحقق من:
php -r 'echo ini_get("memory_limit"), PHP_EOL;'لا تحتاج إلى إعادة تشغيل الخدمة لـ PHP عبر واجهة سطر الأوامر، لأن كل استدعاء لواجهة سطر الأوامر يبدأ عملية جديدة. ولكن إذا كانت مهمة cron الخاصة بك تستدعي صراحةً ملف PHP تنفيذيًا آخر، فتحقق من هذا الملف تحديدًا بدلًا من افتراض /usr/bin/phpأنه الملف المستخدم.
توصي منصة ownCloud بتشغيلها occكمستخدم HTTP، عادةً www-dataعلى أنظمة Debian/Ubuntu. كما تحذر وثائقها الرسمية (occ)occ من ضرورة استخدام نفس إصدار PHP المستخدم في خادم الويب عند تثبيت إصدارات متعددة.
OWNCLOUD_MEMORY_LIMIT=512Mفي بيئة الحاوية وأعد إنشاء الخدمة بحيث يتم تحديث تكوين PHP الذي تم إنشاؤه.بالنسبة لصورة Docker الرسمية الخاصة بـ ownCloud، استخدم متغير البيئة الموثق:
environment:
OWNCLOUD_MEMORY_LIMIT: 512Mثم أعد إنشاء الخدمة:
docker compose up -dلا تُجرِ الإصلاح الأساسي بالتعديل php.iniداخل حاوية مؤقتة. قد يؤدي إعادة إنشاء الحاوية إلى فقدان هذه التغييرات. تُحدد وثائق بيئة دوكر الرسمية لـ ownCloud OWNCLOUD_MEMORY_LIMIT=512Mهذا الإعداد الافتراضي وتوصي بالاحتفاظ به.
إذا كان مضيف Docker نفسه يعاني من حد أقصى صارم للذاكرة، فقم أيضًا بفحص قيود الحاوية:
docker statsلا يمنح حدّ 512 ميجابايت في لغة PHP الحاويةَ 512 ميجابايت من الذاكرة الحرة تلقائيًا، بل يسمح فقط لطلب PHP واحد باستهلاك هذا القدر. ولا تزال الحاوية والمضيف بحاجة إلى ذاكرة كافية لجميع عمليات PHP المتزامنة والخدمات الأخرى.
بعد إعادة تشغيل الخدمة المعنية، أعد التحقق من صفحة phpinfo المؤقتة أو نظرة عامة على لوحة تحكم ownCloud. ثم قم بإزالة صفحة phpinfo.
إذا قمت بتغيير PHP-FPM، فتحقق مما يلي:
sudo systemctl status php7.4-fpm
sudo systemctl status nginxإذا قمت بتغيير Apache:
sudo systemctl status apache2قم بتحديث صفحة إدارة ownCloud. سيختفي التحذير إذا كان ownCloud يعمل الآن بالحد المتوقع على الأقل.
يجري:
free -h
ps aux | grep php-fpm
vmstat 1يُعدّ حدّ استخدام ذاكرة PHP memory_limitحدًا أقصى لكل برنامج نصي. فهو ليس حجزًا للذاكرة، ولا يُعادل مقدار ذاكرة الوصول العشوائي (RAM) التي يحتاجها الخادم. فإذا كان لديك 20 برنامج PHP عامل، ومنحتَ كل طلب إذنًا باستخدام كمية كبيرة جدًا من الذاكرة، فقد يتجاوز الحدّ الأقصى النظري لذاكرة الوصول العشوائي للجهاز بكثير.
تُقدّم وثائق ضبط أداء ownCloud نفس التحذير العام لعمليات خادم الويب: قلّل عدد العمليات بحيث يبقى إجمالي استخدام الذاكرة أقل من ذاكرة الوصول العشوائي (RAM) المتاحة، وإلا سيبدأ النظام في استخدام الذاكرة الافتراضية (swap) وسيتراجع الأداء. راجع إرشادات ضبط أداء ownCloud Classic .
إذا اختفى تحذير 512 ميجابايت وكانت العمليات العادية سليمة، فلا يوجد سبب لزيادة الحد لمجرد جعل الرقم أكبر.
يُعدّ تحذير إزالة التوصية وانهيار النظام بسبب استنفاد الذاكرة مشكلتين مختلفتين. إذا احتوت السجلات على رسائل مثل:
PHP Fatal error: Allowed memory size of ... bytes exhaustedحدد العملية التي تُسبب ذلك. قد يكون لعمليات المسح الكبيرة، ومهام التشفير، وعمليات التخزين الخارجي، ومعالجة الصور، أو تطبيقات الطرف الثالث، أنماط استخدام ذاكرة مختلفة تمامًا.
راجع سجلات ownCloud وسجل أخطاء خادم الويب/PHP. يُنشئ تثبيت ownCloud القياسي سجله الخاص في مجلد البيانات المُكوّن، والذي يكون عادةً في مجلد data/owncloud.log. تجنب اعتبار "زيادة الحجم إلى 1 جيجابايت" الخطوة التالية التلقائية. تأكد أولاً مما إذا كانت العملية نفسها تصل إلى الحد الأقصى بشكل متكرر.
إذا كانت إحدى المهام الإدارية المعروفة تحتاج بشكل مشروع إلى المزيد من الذاكرة، فإن تجاوز سطر الأوامر المستهدف قد يكون أكثر أمانًا من منح كل طلب ويب حدًا كبيرًا بشكل عام:
php -d memory_limit=1G occ <command>استخدم هذا الخيار فقط عندما تكون على دراية بسلوك الأوامر والذاكرة. فهو لا يُصلح طلبات الويب التي تُنفذ عبر PHP-FPM أو Apache.
| الأعراض | السبب المحتمل | الفحص التالي |
|---|---|---|
php -rيُظهر 512 ميجابايت، بينما لا يزال ownCloud يُظهر 128 ميجابايت | لقد قمت بتغيير لغة PHP الخاصة بواجهة سطر الأوامر فقط | تحقق من معلومات PHP في المتصفح وملف التكوين المحمل. |
| يُظهر ملف FPM حجم 512 ميجابايت، بينما لا يزال المتصفح يُظهر 128 ميجابايت. | يقوم Pool .user.iniأو ملف INI آخر بتجاوزه | افحص قيم phpinfo "local" و "master" وملفات INI الإضافية التي تم تحليلها. |
| لا تتغير القيمة إلا بعد إعادة التشغيل | لم تتم إعادة تشغيل الخدمة الصحيحة | أعد تشغيل PHP-FPM أو Apache بشكل صريح بعد التعديل. |
| تعود قيمة Docker إلى الإعداد القديم بعد إعادة الإنشاء | لقد قمت بالتعديل داخل الحاوية | قم بتعيينها OWNCLOUD_MEMORY_LIMITفي Compose أو بيئة النشر. |
| يختفي التحذير لكن الخادم يبدأ بالتبديل | تجاوزت عمليات PHP المتزامنة ذاكرة المضيف | قلل عدد العمال، أو حسّن عبء العمل، أو أضف ذاكرة الوصول العشوائي (RAM). |
memory_limit، upload_max_filesizeوحل post_max_sizeمشاكل مختلفة. زيادة ذاكرة PHP لا تسمح تلقائيًا للمستخدمين بتحميل ملفات أكبر. تشير ملاحظات تكوين ownCloud 10.16 بشكل منفصل إلى أنه post_max_sizeيجب ضبطها على 512 ميجابايت على الأقل كحد أدنى موثق، وتوضح أن حدود التحميل تحتاج إلى إعدادات خاصة بها.
إذا كانت الأعراض الفعلية هي "فشل عمليات التحميل الكبيرة"، فافحص upload_max_filesizeحدود post_max_sizeحجم البيانات في خادم الوكيل/خادم الويب، ومهلات التحميل، وسعة القرص المؤقت. لا تستخدم قيمة أعلى memory_limitكبديل لهذه الضوابط.
memory_limitعلى الأقل 512M.occكان cron يستخدم حدًا أدنى.OWNCLOUD_MEMORY_LIMIT=512Mفي بيئة النشر.الحل الأمثل لمشكلة "حد ذاكرة PHP أقل من القيمة الموصى بها" في ownCloud 10 هو ضبط وقت تشغيل PHP الذي يُشغّل ownCloud على استخدام حد 512 ميجابايت أو أعلى، ثم التحقق من هذه النتيجة باستخدام نفس وقت التشغيل. أما السبب الأكثر شيوعًا للمشكلة فهو التعديل /etc/php/.../cli/php.iniأثناء تشغيل ownCloud عبر PHP-FPM أو Apache باستخدام ملف تهيئة مختلف.
توقف بمجرد اختفاء التحذير، وعودة العمليات الروتينية إلى وضعها الطبيعي، وتوفر مساحة كافية في ذاكرة الخادم. إذا استمر استهلاك PHP لـ 512 ميجابايت أثناء عملية معينة، فانتقل من "زيادة الحد الأقصى" إلى تشخيص عبء العمل: افحص الأمر الذي فشل، والتطبيقات، والسجلات، والتزامن، وذاكرة الوصول العشوائي الفعلية. قد يكون من المناسب زيادة الحد الأقصى، ولكن فقط عندما يبرر عبء العمل ذلك، وعندما يكون الخادم قادرًا على دعمه بأمان.
قارن بين 10 أدوات مسح الشبكة المحلية (Ping) لاكتشاف الشبكات المحلية بسرعة، وإجراء مسح شامل للأنظمة الأساسية المختلفة، وإدارة عناوين IP. تعرّف على ما يمكن أن يكشفه لك المسح وما لا يمكنه كشفه.
قارن بين ست أدوات لإدارة الشبكة لمراقبة الأداء، بما في ذلك تغطية SNMP، ورسم الخرائط، والتنبيهات، ونماذج النشر، والمفاضلات المتعلقة بالتكلفة.
قارن بين أفضل برامج تحليل شبكة Wi-Fi لأنظمة Windows و iPhone و Android، بما في ذلك أدوات ازدحام القنوات وتغطية الإشارة والخرائط الحرارية واستكشاف أخطاء الشبكة وإصلاحها.
قارن بين سبعة برامج مراقبة زمن الاستجابة المجانية والمفتوحة المصدر، بدءًا من مجموعات الشبكة الكاملة وحتى مجسات زمن الاستجابة المركزة، واختر البرنامج المناسب من حيث التوافر وفقدان الحزم والسجل.
تعرف على معنى جودة الخدمة في الشبكات، وكيف تحدد علامات DSCP وقوائم انتظار حركة المرور أولويات تطبيقات الصوت والفيديو والأعمال، وما لا تستطيع جودة الخدمة إصلاحه.
قم ببناء نظام مراقبة شبكة عملي مع تغطية واضحة للأجهزة، ومقاييس أداء مفيدة، وتنبيهات قابلة للتنفيذ، ومقارنة بين SolarWinds NPM وPRTG وOpManager.
قارن بين برامج خوادم SFTP الموثوقة لأنظمة ويندوز ولينكس، بما في ذلك OpenSSH وBitvise وSolarWinds وSFTPGo. اعثر على الخيار الأمثل الذي يلبي احتياجاتك الأمنية واحتياجات نقل الملفات.
قارن بين سبع أدوات لإدارة عناوين IP لاكتشاف الشبكات الفرعية، وتنسيق DNS وDHCP، وجرد الشبكة، وIPAM مفتوح المصدر.
قارن بين أدوات فحص الشبكة لاكتشاف الأجهزة بسرعة، وعمليات فحص IP عبر الأنظمة الأساسية، وإدارة عناوين IP للمؤسسات، مع إرشادات حول مطابقة كل خيار مع شبكتك.
استخدم خيار --traceroute في Nmap لرسم خرائط القفزات إلى مضيف مصرح به، وفهم مخرجات القفزة وRTT، واستكشاف الأخطاء وإصلاحها في الاستجابات المفقودة دون الإفراط في المسح.
