تغييرُ الحجم آمنٌ وممِلٌّ في العادة، ولهذا تفوت الخطوتان غيرُ الآليّتين. خذ لقطةً أوّلًا على كلّ حال — فتغييرُ الحجم من العمليّات القليلة التي تمسّ تخطيط القرص.
المعالج والذاكرة
غيّر الخطّة، وأعد التشغيل، وانتهى. فالنواةُ ترى الحجم الجديد عند الإقلاع ولا شيء داخل الجهاز يحتاج مسًّا.
nproc
free -hوالقرص يحتاج خطوتين أخريين
قرصٌ أكبر في لوحة المزوّد ليس نظامَ ملفّاتٍ أكبر. فعلى القسم أن ينمو في المساحة، ثمّ على نظام الملفّات أن ينمو في القسم. وحتى يتمّا يُظهر df الحجمَ القديم ولم يعطب شيء.
lsblk
growpart /dev/sda 1
resize2fs /dev/sda1 # ext4
# or
xfs_growfs / # xfsالأمر growpart يحرّك حدَّ القسم، وresize2fs أو xfs_growfs يخبر نظامَ الملفّات أن يستعمله. وكلاهما يمكن على نظام ملفّاتٍ مركَّبٍ عامل.
ثمّ البرمجيّاتُ التي قِيست للجهاز القديم
- max_children في PHP-FPM — مضبوطٌ على الذاكرة القديمة، فلا تُستعمَل الذاكرةُ الزائدة.
- innodb_buffer_pool_size — كذلك.
- أعدادُ العمّال في كلّ ما تشغّله سواهما.
ومضاعفةُ الجهاز بلا تغيير شيءٍ في داخله لا تُنتج تحسّنًا البتّة في العادة، ومن هنا تأتي عبارةُ «الترقيةُ لم تفعل شيئًا».
التصغير
أكثرُ المزوّدين لا يصغّرون قرصًا، ومن يفعل يشترط تصغيرَ نظام الملفّات أوّلًا — خارج الخدمة، وبخطرٍ حقيقيّ. فافترض أنّ تغيير الحجم في اتّجاهٍ واحد وقِس على ذلك.
خذ لقطةً قبل، وتحقّق بعدُ أنّ df وfree وnproc تُظهر جميعًا ما دفعت ثمنه. فعرضُ اللوحة للخطّة الجديدة ليس كاستعمال الجهاز لها.
