البحث في الموقع

تتراكم البرامج والملفات الخاصة بالمستخدمين مع الزمن ضمن أي نظام تشغيل وحتى عندما يقوم المستخدم بإزالة بعض البرامج فقد تبقى عدة ملفات عالقة للأبد ضمن ملفات نظام التشغيل. يمكن للمستخدم الذي يمتلك مساحات تخزينية تفوق التيرا بايت Tera Byte أن يتجاهل هذه التراكمات، أما المستخدم الذي يمتلك قرصًا صلبًا من نوع SSD والذي يكون عادة بسعات منخفضة فقد يضطر إلى إزالة هذه التراكمات بشكل دوري. يتضمن هذا المقال أبسط الطرق الذي يستطيع المستخدم تنفيذها لتحرير المساحة ضمن توزيعة أوبونتو Ubuntu ويجب على المستخدم مراقبة المساحة الحرة ضمن جهازه باستمرار ليختار الوقت المناسب لتحرير المساحة. فحص المساحة الحرة ضمن توزيعة أوبونتو يستطيع المستخدم التحقق من المساحة الحرة المتبقية على حاسبه الشخصي باستخدام أداة تحليل استخدام القرص Disk Usage Analyzer المتاحة بشكل افتراضي ضمن توزيعة أوبونتو. يمكن البحث عن هذه الأداة ضمن القائمة الرئيسية وبعد تشغيلها يظهر القرص الصلب والمساحة الحرة المتبقية. يستطيع المستخدم البدء بتحرير المساحة عندما تبلغ المساحة المتبقية من القرص الحد الذي يراه مناسبًا ويمكن بعد الانتهاء من عملية التحرير إعادة تفقد المساحة باستخدام نفس الأداة. تحرير مساحة القرص ضمن توزيعتي أوبونتو و لينكس مينت توجد عدة طرق لتحرير مساحة القرص الصلب ضمن توزيعة أوبونتو أو أنظمة التشغيل المبنية على أوبونتو. منها ما يكون عن طريق تنفيذ الأوامر النصية ومنها ما يكون متاحًا باستخدام أدوات ذات واجهات رسومية. تجدر الإشارة إلى أنه من الأفضل أن يتجنب المستخدم العادي تنفيذ بعض العمليات التي لا يتقنها بشكل جيد تجنبًا لأية ضرر يمكن أن يصيب الحاسب. يتم الاعتماد على نسخة أوبنتو 16.04 في هذا المقال ولكن تبقى الخطوات ذاتها من أجل أوبونتو 18.04 وإصدارات أوبونتو المختلفة كما تنطبق هذه التعليمات على الأنظمة المعتمدة على أوبونتو مثل مينت وغيرها. 1. التخلص من الحزم غير المستخدمة قد تحتاج حزمة ما يقوم المستخدم بتثبيتها إلى تثبيت مجموعة من الحزم الضرورية لعملها، تظهر مشكلة عندما يتم إزالة هذه الحزمة دون أن تتم إزالة الحزم المرتبطة بها مما يؤدي إلى تراكمها واستهلاكها لمساحة تخزينية دون جدوى. وجدنا في [نضع هنا رابط المقالة رقم 7](رابط المقالة رقم 7) أنه يمكن استخدام الأمر apt-get الذي يستخدم لتثبيت الحزم من أجل إزالة الرزم عن طريق الأمر autoremove والذي يزيل هذه الرزم العالقة كما أنه يزيل أي نسخ قديمة من نواة نظام التشغيل لينكس والتي يمكن أن تصبح بلا فائدة بعد ترقية النظام. يتم ذلك عبر تنفيذ الأمر التالي في موجه الأوامر وبالطبع فإننا نحتاج إلى صلاحيات مناسبة لتنفيذ عمليات الحذف هذه: sudo apt-get autoremove يظهر الشكل أدناه أنه سيتم تحرير مساحة تعادل 300 ميغابايت من القرص الصلب بعد نجاح تنفيذ هذه العملية ويمكن أن تكون هذه المساحة أكبر وذلك تبعا لطريقة استخدام الحاسب والفترة الزمنية المنقضية منذ آخر عملية تحرير مساحة تم تنفيذها. 2. إزالة التطبيقات غير الضرورية توجد العديد من التطبيقات الموجودة بشكل افتراضي ضمن توزيعة أوبونتو، وقد تمر سنين دون أن يستخدمها أحد وخصوصًا الألعاب وبعض التطبيقات الإضافية وبالتالي يمكن إزالتها. كما ينطبق ذلك على بعض التطبيقات التي ثبّتها المستخدم واستخدمها مرة واحدة ونسي استخدامها أو أنه لم يعد بحاجتها لذلك يجب إزالة هذه التطبيقات إما بالاعتماد على مركز البرمجيات Software Center أو باستخدام موجه الأوامر وتنفيذ الأمر التالي: sudo apt-get remove package-name1 package-name2 3. تنظيف الذاكرة المخبئية Cache الخاصة بالأداة APT تستخدم توزيعة أوبونتو الأداة APT من أجل تثبيت وإدارة وإزالة الحزم البرمجية. تحتفظ هذه الأداة بنسخة من الحزم البرمجية التي تم تحميلها وتثبيتها مسبقًا حتى بعد أن تتم إزالة هذه الحزم البرمجية من النظام. يتم تخزين هذه الحزم ضمن المسار ‎/var/cache/apt/archives. يزداد حجم هذا المجلّد مع الزمن ويمكن التحقق من حجمه عبر تنفيذ الأمر: sudo du -sh /var/cahce/apt يظهر الشكل أنه تم إشغال حوالي 500 ميغابايت من القرص في المجلّد السابق ويجب تحرير هذه المساحة. يمكن تحرير هذه المساحة بطريقتين، إما عن طريق إزالة الرزم التي أصبحت قديمة جدًا والتي لا يمكن إعادة استخدامها بعد اعتماد تحديث ما مما يجعلها بلا قيمة ويتم ذلك بتنفيذ الأمر: sudo apt-get autoclean أو عبر حذف كامل هذه المساحة التخزينية مما يوفر الكثير من المساحة ولكنه قد يجبر المستخدم على تنزيل بعض الحزم البرمجية في حال احتاجها مرة ثانية في حال لم تكن هذه الحزم قديمة ويتم ذلك بتنفيذ الأمر: sudo apt-get clean 4. تفريغ ملفات السجلات ملاحظة: هذه الخطوة تتطلب معرفة متقدمة. تتضمن جميع توزيعات لينكس آليات تسجيل لحفظ جميع العمليات والقيم التي تتغير ضمن النظام. نجد سجلًا خاصًا بنواة نظام التشغيل وسجلًا خاصًا برسائل النظام وسجلًا يحتوي على الأخطاء الخاصة بجميع الخدمات التي تعمل ضمن نظام لينكس سواء كانت من ضمن نظام التشغيل أو أن المستخدم ثبتها على النظام. يزداد حجم هذه السجلات بسرعة كبيرة، إذ تسجّل هذه القيم دون توقف مما يجعل حجم هذه السجلات كبيرًا ويمكن الاطلاع على هذا الحجم عن طريق تنفيذ: journalctl --disk-usage تجدر الإشارة إلى أنه على عكس الحزم فلا يجب حذف جميع السجلات ويجب الاحتفاظ ببعضها لذلك من الشائع أن يحتفظ المستخدم بالسجلات التي لم يمض عليها زمن طويل، يتم تنفيذ الأمر أدناه لإزالة السجلات التي تتضمن المعطيات المتعلقة بالأداء منذ أكثر من ثلاث أيام: sudo journalctl --vacuum-time=3d يظهر الخرج أدناه بعد تنفيذ الأمر السابق: abhishek@itsfoss:~$ journalctl --disk-usage Archived and active journals take up 1.8G in the file system. abhishek@itsfoss:~$ sudo journalctl --vacuum-time=3d Vacuuming done, freed 1.7G of archived journals from /var/log/journal/1b9ab93094fa2984beba73fd3c48a39c 5. إزالة النسخ القديمة من التطبيقات المثبّتة باستخدام مدير الحزم Snap ملاحظة: هذه الخطوة تتطلب معرفة متقدمة. يتيح مدير الحزم Snap الكثير من التطبيقات التي تفيد المستخدمين ولهذا يكون لها شعبية كبيرة مقارنة بمدراء الحزم التقليديين، تكمن المشكلة الأساسية أنّ الحزم المثبّتة عن طريق مدير الحزم Snap تكون أكبر حجمًا من غيرها ومما يزيد من حجم المشكلة أن مدير الحزم Snap يحتفظ بنسختين على الأقل من نفس الحزمة التي يتم تثبيتها وذلك في حال رغب المستخدم العودة إلى نسخة أقدم من نفس الحزمة، نستعرض المساحة التي تستهلكها هذه الأداة عبر تنفيذ الأمر التالي ويظهر الخرج المبين أدناه بعد تنفيذها du -h /var/lib/snapd/snaps 4.0K /var/lib/snapd/snaps/partial 5.6G /var/lib/snapd/snaps نلاحظ أن المساحة المشغولة وصلت إلى خمسة غيغابايت وهذه المساحة كبيرة نسبيًا. مع تفاقم هذه المشكلة عمد أحد المطورين العاملين ضمن فريق تطوير مدير حزم Snap وهو آلان بوب إلى تطوير سكربت Script بسيط يزيل النسخ القديمة من التطبيقات المثبّتة باستخدام مدير الحزم Snap. ننشئ ملف نص برمجي ونضع فيه المحتوى التالي: #!/bin/bash # Removes old revisions of snaps # CLOSE ALL SNAPS BEFORE RUNNING THIS set -eu snap list --all | awk '/disabled/{print $1, $3}' | while read snapname revision; do snap remove "$snapname" --revision="$revision" done يجب إضافة الصلاحيات التنفيذية المناسبة لملف النص البرمجي السابق وتشغيله مع صلاحيات مدير باستخدام sudo. يتم تحرير المساحة المحجوزة التي يمكن تحريرها ونستعرض المساحة بنفس الطريقة السابقة ليكون الخرج بالشكل التالي: du -h /var/lib/snapd/snaps 4.0K /var/lib/snapd/snaps/partial 2.5G /var/lib/snapd/snaps فصلنا أكثر عن هذه الخطوة في مقال مسح حزم Snap المعطلة لتحرير المساحة في لينكس. 6. إزالة الذاكرة الوسيطة الخاصة بالصور المصغّرة thumbnail ملاحظة: هذه الخطوة تتطلب معرفة متقدمة. تنشئ توزيعة أوبونتو صور مُصغَّرة خاصة بالعرض ويخزنها في مجلّد مخفي ضمن المساحة التخزينية الخاصة بالمستخدم وهو ‎~/.cache/thumbnails. يزداد عدد هذه المصغّرات مع الزمن وبالتالي يزداد حجمها مع العلم بأن بعض هذه المصغرات تعود لصور لم تعد موجودة ولهذا يجب إزالتها. يمكن التحقق من حجم الذاكرة الوسيطة الخاصة بالمصغرات عبر تنفيذ الأمر التالي: du -sh ~/.cache/thumbnails يبين الشكل التالي نتيجة تنفيذ هذا الأمر: يفضل تحرير هذه المساحة كل بضعة أشهر ويمكن ذلك بتنفيذ الأمر التالي: rm -rf ~/.cache/thumbnails/* 7. إيجاد وحذف الملفات المتكررة يمكن أن تتكرر الملفات دون إدراك المستخدم وفي حال كانت هذه الملفات ذات حجوم كبيرة كملفات الفيديو أو الصور عالية الدقة فسوف يستهلك ذلك مساحة كبيرة ولهذا يمكن البحث عن هذه الملفات المكررة وإزالتها. يمكن تنفيذ ذلك باستخدام الأداة ذات الواجهات الرسومية FSlint أو باستخدام الأداة FDUPES التي تعمل ضمن موجه الأوامر والتي يبين الشكل أدناه مثالًا على عملها. يمكن للخبراء تنفيذ بعض الخطوات الإضافية لتحرير المزيد من المساحة، ولا يعني ربط الخطوات التالية بالخبراء أن المستخدم العادي لا يجب أن يحاول تنفيذ هذه الخطوات ولكن من الأفضل أن يكون حذرًا وأن يحتفظ بنسخة احتياطية لملفاته المهمة. 8. إزالة نوى لينكس القديمة التي تم تثبيتها بشكل يدوي ملاحظة: هذه الخطوة تتطلب خبرة متقدمة. ناقشنا في الخطوة رقم 1 السابقة استخدام أمر لإزالة نواة نظام لينكس القديمة ولكن يجب الانتباه أنّ هذا الأمر لا يزيل نواة لينكس التي يثبتها المستخدم بشكل يدوي وإنما فقط يزيل ما ثبّته النظام تلقائيًا. تحرر عملية الإزالة هذه الكثير من المساحة وللتحقق من وجود هذه النوى على الجهاز يمكن تنفيذ الأمر التالي: sudo dpkg --list 'linux-image*' لا تختلف إزالة نواة نظام التشغيل عن إزالة أية حزمة برمجية، فبعد أن يظهر الأمر السابق النوى المتاحة يتم تسجيل رقم الإصدار VERSION الذي يجب إزالته وننفذ الأمر التالي: sudo apt-get remove linux-image-VERSION يوصي الخبراء أن يحافظ المستخدم على نسختين أو ثلاث من نوى نظم التشغيل ومن ضمنه أحدث نسخة للنواة مما يتيح العودة إلى نسخة أقدم من النواة في حال ظهور مشكلة ضمن النواة الجديدة. 9. إزالة الحزم اليتيمة ملاحظة: هذه الخطوة تتطلب خبرة متقدمة. نعرّف الحزم اليتيمة على أنّها الحزم التي يتم تثبيتها ضمن النظام لكونها متطلّبًا لحزمة أساسية أخرى وقد حذف المستخدم هذه الخدمة الأساسية وبقيت الحزمة اليتيمة ضمن النظام. وجدنا في الخطوة رقم 1 أنه يمكن تنفيذ أمر لإزالة هذه الحزم ولكن تكمن المشكلة الأساسية إذا ثبت المستخدم هذه الحزم المكمّلة لحزمة ما بشكل يدوي وبالتالي لن يستطيع الأمر السابق إزالتها لأنه لا يستطيع الجزم بأن المستخدم ثبت هذه الحزمة لحاجته لها أم أنها كانت متطلّبًا لحزمة أخرى فيضطر إلى تجاوزها. يجب أن يبحث المستخدم عن هذه الحزم بشكل يدوي ولكن لحسن الحظ توجد عدة أدوات منها ما يمتلك واجهات رسومية مثل gtkorphan والتي تساعد في العثور على الحزم اليتيمة. يتم تثبيت هذه الأداة بتنفيذ الأمر التالي: sudo apt-get install gtkorphan يبين الشكل التالي الواجهة الأساسية للأداة وتجدر الإشارة إلى أنّ المستخدم لا يحتاج لهذه الأداة فعليًا إلا إذا كان بحاجة كل المساحة التخزينية المتاحة لسبب ما. ملاحظة: قد لا تكون الحزمة gtkorphan متوفرة أثناء قراءة المقال، لذا يمكنك استعمال البديل المناسب والمريح لك، مثل deborphan وغيرها. 10. استخدام الأدوات ذات الواجهات الرسومية لتحرير المساحة في أوبونتو توجد عدة سكربتات تستخدم لتحرير المساحة ضمن توزيعة أوبونتو وقد تم ذكر البعض منها كما توجد المزيد منها ما لم تشمله هذا المقال. يصبح تذكر الأوامر صعبًا لدى بعض المستخدمين ولهذا يمكن استخدام الأدوات ذات الواجهات الرسومية وتعد الأداة Stacer واحدة من أهم هذه الأدوات والتي تتسم بسهولة الاستخدام. الخاتمة تضمنت المقالة بعض الخطوات الأساسية لتحرير المساحة ضمن توزيعة أوبونتو والأنظمة المعتمدة عليها، حيث أنّ بعض هذه الخطوات بسيطة ويجب على جميع المستخدمين تنفيذها بشكل دوري ومنها ما يتطلب أنْ يكون المستخدم خبيرًا ويمكن تجنبها لوقت الحاجة الفعلية للمساحة ويترك تقدير ذلك للمستخدم وحاجته الفعلية للمساحة. ترجمة وبتصرف للمقال ‎7 Simple Ways to Free Up Space on Ubuntu and Linux Mint لصاحبه Abhishek Prakash. اقرأ أيضًا التعرف على اختناقات الأداء في نظام لينكس باستخدام الأدوات مفتوحة المصدر كيفية تثبيت التطبيقات في لينكس كيف تفهم هيكلية نظام الملفات في لنكس

مقدِّمةيُشكّل خادوم Nginx، السّريع والخفيف، بديلًا - في حالات عديدة - لخادوم Apache كثيرِ المُتطلّبات. كأيّ برنامج آخر، يحتاج Nginx إلى ضبطه من أجل الحصول على أداء أفضل. مُتطلَّبات الدّرسخادوم ويب Nginx مثُبَّت ومُعَدّ للعمل. فهم أساسيّات التّعامل مع Linux. ضبط متغيّرَيْ worker_processes و worker_connectionsأوّل متغيِّريْن يجب علينا ضبطُهما هما متغيّرا worker_processes و worker_connections. يجب أن نفهم ما الّذي يتحكّم فيه كل واحد من هذيْن المتغيّريْن، قبل الدّخول في تفاصيل إعداد كلّ واحد منهما. نبدأ بتعليمة worker_processes الّتي تُمثِّل العمود الفقري الصّلب بالنّسبة ل Nginx. تُعطي هذه التّعليمة عددَ العمليّات Processes الّتي يجب على Nginx إنشاؤُها بعد معرفته لعنوان IP والمنافِذ Ports الّتي سيشتغل عليها، وهيّ المسؤولة عن كل ما يُؤدّيه خادوم الويب. يُطلَق على كل واحدة من هذه العمليّات اسم Worker (العامِل). من المُستحسَن تشغيلُ عامل واحد على كل نواة Core من وحدة المُعالجة المركزيّة Central processing unit, CPU. لن ينتُج عن تشغيل أكثر من عامل على نواةٍ ضررٌ كبير على النِّظام لكنّه سيؤدّي إلى وجود العديد من العمليّات السّاكنة Idle processes غير الضّروريّة. ملحوظة: عمليّة ساكنة هي عمليّة لا تجد ما تفعله ولا تتولّى الإجابة عن أيّ طلب. يكفي، لمعرفة قيمة worker_processes الأمثل لإعدادك، إلقاءُ نظرة على عدد الأنويّة لديك. يُمكِنك عبر الأمر التّالي الحصول على هذه المعلومة: grep processor /proc/cpuinfo | wc -lفلنفترِض أنّ نتيجةَ تنفيذ الأمر هيّ 1. يعني هذا أنّه يوجد في النّظام لدينا نواةٌ واحدة. المُتغيّر الثّاني worker_connections يُعطي عددَ الاتّصالات الّتي يُمكن لعمليّات من نوع Worker الاستجابة لها في نفس الوقت. القيمة الافتراضيّة هي 768.في العادة، يُرسِل متصفّح الويب طلبيْن - على الأقل - في نفس الوقت إلى الخادوم، وهو ما يعني أنّ عدد العملاء الّذين يُمكِن الرّد عليهم في نفس الوقت يبلغ في أعلى تقدير نصفَ قيمةِ المُتغيِّر worker_connections. من أجل الرّفع من عدد العُملاء المُتّصلين في آنٍ معًا سنُعطي لهذا المُتغيِّر أعلى قيمة تسمح بها موارد الجهاز، والّتي يُمكِن معرفتها عن طريق الأمر: ulimit -nستتغيَّر النّتيجة حسب الجهاز والموارد المُتوفّرة له. نأخذ مثالًا بجهاز ذي إمكانيّات محدودة حيثُ تُساوي هذه القيمة 1024. نُحدِّث إعدادات Nginx عبر فتح ملفّ الإعداد nginx.conf وتحريره: sudo nano /etc/nginx/nginx.confنُعطي القيمة 1 لـ worker_processes والقيمة 1024 لـworker_connections: worker_processes 1; worker_connections 1024;يجب الانتباه هنا إلى أنّ عدد الاتّصالات الكلّي الّتي يقبله Nginx في نفس الوقت يُساوي جداءَ قيمتَيْ المُتغيّريْن worker_processes و worker_connections. أي، في حال التزمنا بالقاعدة السّابقة، عددَ الأنويّة مضروبًا بعدد الاتّصالات الّتي يُمكن لكل عامِل الاستجابة لها. في مثالنا هنا النّتيجة هيّ 1024 (حاصل ضرب 1024 ب 1). يوجد أيضًا مُتغيِّر keepalive_timeout والّذي يُمكن لقيمته أن تُقلِّلَ من عدد الاتّصالات الفعليّة (سنتطرّق لهذا المتغيِّر). الصُّّوَّانات Buffersيُمكِن أن ينتُج عن تعديل حجم الصِّوان (وهي منطقة تخزين مُؤقّت ضمن ذاكرة الوصول العشوائي RAM، تُستخدم لنقل البيانات بين العمليّات) تغيّرات مُعتبرة في الأداء. إذا كان حجم الصِّوان صغيرًا فإن Nginx سيحتاج إلى إنشاء ملفّ تخزين مؤقَّت Temporary file ممّا يُؤدّي إلى كثرة القراءة والكِتابة من القرص الصّلب. توجد بعض التّعليمات الّتي نحتاج لفهمها قبل إجراء أيّ تعديل. client_body_buffer_size: حجم صِوان العميل Client (وحدة الحجم في كامل ملف الإعداد هيّ البايت Byte، يُشير حرف K إلى كيلوبايت KB) أي حجم الجسم Body في طلب Http أثناء إجراء POST. تُستخدَم إجراءات POST أساسًا عند إرسال النّماذج client_header_buffer_size: مُشابهة للتّعليمة السّابقة، ولكن لحجم التّرويسة Header في طلب Http. حجم 1KB مناسِب - غالبًا - لهذه التّعليمة. client_max_body_size: الحجم الأقصى المسموح به لطلب العميل. إذا تجاوز طلب العميل هذا الحجم فإن خادوم ويب Nginx سيُجيب بخطأ 413 (محتوى الطّلب أكبر من المسموح به Request Entity Too Large). large_client_header_buffers: العدد الأعلى والحجم الأقصى للصُّوّان بالنّسبة للتّرويسات العريضة في طلب العميل. في حال كان سطر الطّلب أكبر من حجم الصِّوّان فإن خادوم الويب يُجيب بخطأ 414 (مسار URI للطّلب أطول من المسموح به Request URI too large). نفس الشّيء بالنّسبة للتّرويسة في الطّلب إذ لا يجوز أن تتجاوز حجم الصِّوان المسموح به في هذه التّعليمة وإلاّ فإنّ Nginx سيُجيب بخطأ 400 (طلب غير صالح Bad request). يُشير العدد في هذه التّعليمة إلى العدد الأعلى من الطّلبات ذات التّرويسة العريضة (أي ترويسة بحجم أكبر من المُحدَّد في client_header_buffer_size) المسموح بها. مثال على قِيّم للمتغيّرات السّابق ذكرها: client_body_buffer_size 10K; client_header_buffer_size 1k; client_max_body_size 8m; large_client_header_buffers 2 1k;المُهَل Timeoutsالمُهل هي مُتغيّرات أخرى تُوّثّر كثيرًا على أداء Nginx. تُحدّد تعليمتَا client_body_timeout و client_header_timeout المهلة الزّمنيّة (بالثّانيّة) الّتي ينتظرها الخادوم لتلقي محتوى أو ترويسة العميل على التّوالي بعدَ استلام الطّلب منه. إن لم يتلقَّ الخادوم واحدًا من الاثنيْن خلال هذه الفترة فسيُجيب بخطأ 408 (انتهَت مُهلة الطّلب Request time out). أمّا تعليمة keepalive_timeout فتُحدّد المهلة الزمنيّة لاتّصالات استمرار النّشاط Keep-alive connections. بعبارة أخرى، سيقطع Nginx الاتّصال بعد انقضاء هذه المُهلة بغض النّظر عمّا يُريد العميل. توجد أيضًا send_timeout والّتي تُعنى بالفترة الزّمنية بين عمليّتَيْ قراءة من طرف العميل. إنْ لم يُرسِل العميل أيّ طلب خلال هذه المهلة فسيقطع خادوم الويب الاتّصالَ به، دون اعتبار لقيمة التّعليمة السّابقة. مثال على قيّم لمتغيّرات المُهَل الزّمنيّة: client_body_timeout 12; client_header_timeout 12; keepalive_timeout 15; send_timeout 10; الضّغط Compression بواسطة Gzipيُمكِن لأداة الضّغط وفكّ الضّغط Gzip المُساعدة في تحسين أداء خادوم الويب عبر التّقليل من حجم البيانات المُتبادلة؛ لكن ينبغي الحذر من رفع قيمة مستوى الضّغط gzip_comp_level لمستوى عالٍ إذ يُمكن أن يُسبّب ذلك كثرة نشاط أنويّة المُعالج. لتفعيل الضّغط نُعطي القيمة on لتعليمة gzip. تعليمة gzip_min_length تُحدِّد الحجم الأدنى لتفعيل الضّغط، أي أنّ ملفًّا بحجم أقل من قيمة هذه التّعليمة لن يخضع للضّغط. يُمكِن تحديد صيّغ الملفّات الّتي يُطبَّق عليها الضّغط عبر التّعليمة gzip_type. توجد أيضًا تعليمة gzip_proxied لتعيين طريق التّعامل مع الطّلبات الواردة من عملاء يمرّون عبر وسيط Proxy. gzip on; gzip_comp_level 2; gzip_min_length 1000; gzip_proxied expired no-cache no-store private auth; gzip_types text/plain application/x-javascript text/xml text/css application/xml; التّخزين المؤقت للملفات السّاكنة  Static File Cachingيُساهم طلب التّخزين المُوقّت من جانب العميل (المُتصفِّح) في التّقليل من تبادل البيانات والحفاظ على موارد الخادوم. يجب إدراج هذه التّعليمة على مُستوى كُتلة الخادوم Server block ضمن الملف الافتراضي لإعداد كُتلة خادوم Nginx، كما في المثال أدناه. عمل التّعليمة يتمثّل في إخبار العميل بالاحتفاظ بنسخة من الملفّ وعدم تنزيلها من الخادوم طوال مدّة محدّدَة (365 يومًا في المثال). إن احتاج العميل لأحد هذه الملفّات خلال هذه المدّة فسيلجأ للنّسخة الموجودة لديه ولن يتبادل بيانات مع الخادوم. تُذكَر في التّعليمة أنواع الملفّات الّتي يُطلَب من العميل تخزينها (أساسًا صوّر وملفاّت تنسيق css وjs). location ~* .(jpg|jpeg|png|gif|ico|css|js)$ { expires 365d; } تعطيل حفظ السّجلّات Loggingيحتفظ Nginx في الإعددات الافتراضية بكلّ طلب يصل إلى الخادوم ضمن ملفّ للسّجلّات Logs. يُمكنك إيقاف هذه الخاصيّة إذا كنتَ تستخدِم أداةً لتحليل المواقع عن طريق إعطاء القيمة off للتّعليمة access_log كما هوّ موضَّح أدناه: access_log off;أعِد تشغيل خادوم الويب بعد حفظ ملفّ الإعداد حتى تُؤخذ التّعديلات في الحسبان: sudo service nginx restartخاتمةخادوم ويب مضبوط جيّدًا هو خادوم مُعد ومُهيَّأ ليتصرّف حسب نوعيّة الطّلبات الّتي ترده. ينبغي الانتباه إلى أنّه لا توجد قيمة مُثلى لا ينبغي المساسُ بها لأيّ من المتغيّرات والتّعليمات المذكورة في هذا الدّليل. يجب ضبط الإعدادات حسب كلّ حالة وما يُناسبها. إذا أردتَ الاستمرار في طريق التّحسين فيُمكنك تجربة التّوسّع الأفقي Horizontal scaling وتوزيع الحِمل Load balancing. الإعدادات المذكورة في هذا الدّليل ليست سوى بداية في الطّريق إلى تحسينات أكبر. ترجمة – وبتصرّف – للمقال How To Optimize Nginx Configuration