دستورات پرکاربرد لینوکس برای مدیر سایت؛ چک لیست هر هفته

وقتی سایت کند می شه یا از دسترس خارج می شه، بیشتر وقت ها با چند دستور ساده می شه علت رو پیدا کرد. دستورات پرکاربرد لینوکس برای مدیر سایت چهار سؤال رو جواب می دن: دیسک پر شده؟ چه پردازشی منابع رو می خوره؟ لاگ چی می گه؟ شبکه سالمه؟ اینجا همین دستورها رو به ترتیب اولویت می بینی تا دقیقاً از جایی شروع کنی که لازمه.

مشتری ها معمولاً با این جمله به پشتیبانی می رسن: «سایتم کند شده، از کجا شروع کنم؟». جواب ما همیشه یه چیزه: حدس نزن، اول از سرور بپرس و جوابش رو بخون. همه دستورهای این چک لیست فقط اطلاعات نشون می دن و چیزی رو تغییر نمی دن، به جز جاهایی که صراحتاً هشدار می دیم. خروجی بعضی دستورها بین اوبونتو و آلمالینوکس کمی فرق داره و ما فقط به تفاوت های مهم اشاره می کنیم. اگه هنوز بین توزیع ها مردد هستی، Ubuntu یا Debian برای سرور؛ کدام را انتخاب کنیم؟ کمکت می کنه.

ده ثانیه اول: سه تا از دستورات پرکاربرد لینوکس که قبل از هر کاری می زنی (اولویت ۱)

این سه دستور مثل چراغ های داشبورد ماشینن. نمی گن مشکل دقیقاً چیه، فقط نشون می دن کدوم بخش رو باید دقیق تر ببینی.

uptime
df -h
free -h

uptime نشون می ده سرور چند وقته بالاست و load average چقدره. اگه چند دقیقه پیش ری استارت شده، همین خودش سرنخه: شاید سرور بالا اومده ولی یه سرویس بعدش بالا نیومده. سه عدد load average مربوط به یک، پنج و پانزده دقیقه اخیره. برای تفسیرش تعداد هسته های CPU رو با nproc ببین. اگه load مدام بیشتر از تعداد هسته ها باشه، کارها توی صف منتظر می مونن. یادت باشه load روی لینوکس پردازش های منتظر دیسک رو هم می شماره، پس load بالا همیشه مشکل CPU نیست.

df -h درصد پر بودن دیسک رو می ده و free -h وضعیت RAM و swap رو. به ستون available نگاه کن، نه free. لینوکس حافظه خالی رو برای کش استفاده می کنه و کم بودن free به تنهایی ترسناک نیست.

دیسک پر شده؟ سایت بی صدا از کار می افته (اولویت ۱)

پر شدن دیسک از آزاردهنده ترین خرابی هاست، چون خطای واضحی نمی ده. دیتابیس نمی تونه بنویسه، سشن ها ساخته نمی شن و کاربر فقط می بینه «یه چیزی درست کار نمی کنه». df مثل نگاه کردن به کل انباره که می گه «۹۵٪ پره». du مثل گشتن بین قفسه هاست تا بفهمی کدوم قفسه رو کارتن های خالی پر کرده.

کدوم پوشه سنگینه؟

برو توی مسیر مشکوک، مثلاً /var یا مسیر سایت، و بزن:

cd /var
sudo du -sh * | sort -h

آخر لیست، بزرگ ترین پوشه هاست. هر بار یه سطح پایین تر برو تا به مقصر برسی. معمولاً مقصر یکی از اینهاست: لاگ های چرخش نشده، بکاپ های قدیمی، کش یا فایل های موقت آپلود. اگه ncdu نصب باشه، همین کار رو با یه محیط تعاملی راحت تر انجام می ده.

یه نکته: * فایل های مخفی (اونایی که با نقطه شروع می شن) رو نشون نمی ده. پس اگه جمع اعداد با df نمی خونه، این رو هم در نظر بگیر.

فقط حجم نیست، inode هم هست

گاهی df -h می گه فضا هست، ولی فایل جدید ساخته نمی شه. این بار df -i رو بزن:

df -i

اگه IUse% نزدیک صد درصده، یعنی تعداد فایل ها از سقف رد شده، نه حجمشون. معمولاً کش یا سشن های قدیمی این بلا رو سر دیسک می یارن.

لاگ رو پاک کردی ولی فضا آزاد نشد

این رو زیاد از مشتری ها می شنویم. یه لاگ چند گیگی رو rm می کنی، ولی df همون عدد قبلی رو نشون می ده. دلیلش اینه که یه پردازش هنوز اون فایل رو باز نگه داشته. با این دستور پیداش کن:

sudo lsof | grep deleted

راه حلش ری استارت همون سرویسه، نه حذف دوباره فایل. جزئیاتش رو توی سوالات متداول پایین مقاله گفتیم.

پردازش ها: کی منابع رو می بلعه؟ (اولویت ۲)

وقتی uptime load بالا نشون داد، وقتشه مقصر رو پیدا کنی.

top

توی top دکمه P رو بزن تا بر اساس CPU مرتب بشه و M رو برای مرتب سازی بر اساس حافظه. ستون %CPU سهم پردازنده رو نشون می ده، %MEM سهم RAM رو و COMMAND اسم برنامه رو. با q خارج شو. اگه htop نصب باشه، همین اطلاعات رو رنگی تر و خواناتر می بینی.

برای یه خروجی ثابت که بشه کپیش کرد:

ps aux --sort=-%mem | head -n 6

اگه سرویس اصلی (مثلاً nginx یا php-fpm) اصلاً بالا نیست، وضعیتش رو بپرس:

systemctl status nginx

برای اپلیکیشن های خودت هم که با systemd اجرا می شن، ساخت سرویس systemd برای اپلیکیشن؛ از فایل unit تا ری استارت خودکار نشون می ده چطور بعد از هر کرش خودشون بالا بیان.

هشدار: با دیدن یه پردازش پرمصرف، سریع kill -9 نزن. اول kill PID معمولی رو امتحان کن تا برنامه فرصت داشته باشه تمیز بسته بشه. برای php-fpm هم بهتره کل سرویس رو با systemctl restart ری استارت کنی، نه اینکه پردازش های فرزندش رو یکی یکی بکشی. دیتابیس رو هم بی دلیل نکش و اول لاگش رو ببین. اگه ریشه مشکل یه کوئری سنگین MySQL به نظر می رسه، کوئری کند در MySQL؛ از slow query log تا ایندکس درست رو بخون.

اول لاگ رو بخون، بعد حدس بزن (اولویت ۱)

خیلی از مشکل ها توی لاگ دقیقاً نوشته شده و کسی نخونده. آخرین خط های خطای وب سرور رو ببین:

sudo tail -n 100 /var/log/nginx/error.log

مسیر لاگ به نرم افزار و توزیع بستگی داره. آپاچی روی اوبونتو معمولاً /var/log/apache2/error.log داره و روی آلمالینوکس /var/log/httpd/error_log. لاگ php-fpm هم بسته به نسخه فرق می کنه. اگه فایل پیدا نشد، تنظیمات همون سرویس رو نگاه کن.

برای دیدن زنده لاگ، همزمان با باز کردن صفحه سایت:

sudo tail -f /var/log/nginx/error.log

با Ctrl+C خارج شو. روی فایل های بزرگ هم cat نزن، چون ترمینالت پر می شه و پیدا کردن چیزی سخته.

لاگ سرویس هایی که با systemd اجرا می شن توی journal هم هست:

sudo journalctl -u nginx --since "1 hour ago"
sudo journalctl -p err -b

دستور اول لاگ یه سرویس رو برای یک ساعت اخیر می ده و دومی فقط خطاهای بعد از آخرین بوت رو. اگه سرویسی بی دلیل افتاده، چک کن لینوکس به خاطر کمبود حافظه نکشته باشدش:

sudo dmesg -T | grep -i "killed process"

ترافیک ناگهانی بالا رفته؟

اگه فکر می کنی یه ربات یا اسکنر داره به سایت فشار می ده، پرتکرارترین IP ها رو از لاگ دسترسی بیرون بکش:

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head

یه استثنا هست: اگه سایتت پشت CDN یا پروکسی باشه، ستون اول لاگ ممکنه IP همون پروکسی باشه، نه بازدیدکننده واقعی. پس قبل از بلاک کردن چیزی مطمئن شو. ساعت اوج ترافیک رو هم در نظر بگیر. افزایش ناگهانی درخواست ها توی ساعت شلوغ لزوماً حمله نیست.

سرور سالمه ولی از بیرون دیده نمی شه (اولویت ۲)

اول ببین سرویس روی پورت درست گوش می ده:

sudo ss -tulpn

باید پورت های ۸۰ و ۴۴۳ برای وب سرور و پورت SSH رو ببینی. بعد روی خود سرور سایت رو تست کن:

curl -I http://127.0.0.1

اگه اینجا جواب می ده ولی از بیرون باز نمی شه، مشکل بین سرور و دنیای بیرونه: فایروال، DNS یا مسیر شبکه. وضعیت فایروال رو با sudo ufw status (اوبونتو) یا sudo firewall-cmd --list-all (آلمالینوکس) ببین. اگه با SSH وصلی، قبل از تغییر هر قانونی مطمئن شو پورت SSH بازه، وگرنه خودت از سرور بیرون می مونی.

برای DNS و دامنه:

dig +short example.ir

اگه تازه دامنه .ir رو به سرور جدید وصل کردی، یادت باشه تغییر نیم سرور یا رکورد ممکنه کمی طول بکشه تا همه جا بشینه. برای دیدن مسیر شبکه تا مقصد هم mtr یا traceroute کمک می کنه.

ارتباط سرور با سرویس های بیرونی

اگه سایتت از درگاه پرداخت یا سرویس پیامک استفاده می کنه، گاهی مشکل از اتصال خروجی خود سرور به اونهاست. این رو مستقیم از سرور تست کن:

curl -m 10 -I https://example.com

-m 10 یعنی بعد از ده ثانیه منصرف شو. فقط ping کافی نیست، چون بعضی مسیرها ICMP رو می بندن در حالی که HTTPS کار می کنه. محدودیت های اینترنت بین الملل هم گاهی باعث می شه سرویس خارجی از سرور ایران کند یا قطع باشه. پس تایم اوت از یه آدرس خارجی لزوماً یعنی سرورت خراب شده، نه.

چک لیست یه صفحه ای دستورات پرکاربرد لینوکس

اگه بخوای این مقاله رو توی یه یادداشت خلاصه کنی، همینه:

سوالات متداول

چرا بعد از حذف فایل لاگ بزرگ، df هنوز فضای پر نشون می ده؟

چون یه پردازش هنوز فایل حذف شده رو باز نگه داشته و لینوکس تا وقتی اون پردازش بسته نشه، فضاش رو آزاد نمی کنه. با sudo lsof | grep deleted اون پردازش رو پیدا کن و سرویسش رو ری استارت کن، مثلاً با systemctl restart nginx. دفعه بعد برای لاگ های فعال بهتره فایل رو خالی کنی (truncate -s 0) یا logrotate بذاری، نه اینکه پاکش کنی.

load average چه عددی خوبه؟

عدد ثابتی وجود نداره و باید با تعداد هسته های CPU مقایسه بشه. اگه load مدام از تعداد هسته ها بیشتر باشه، یعنی کارها توی صف می مونن. یه جهش کوتاه معمولاً مشکلی نیست، ولی اگه عدد پانزده دقیقه اخیر هم بالا باشه، فشار پایداره.

روی هاست اشتراکی هم می شه این دستورها رو زد؟

معمولاً نه. هاست اشتراکی دسترسی SSH کامل و دسترسی به سطح سیستم نمی ده و برای دیدن لاگ ها و مصرف منابع باید سراغ ابزارهای پنل مدیریت هاست بری. این دستورها به درد سرور مجازی یا اختصاصی می خورن، چون کنترل کامل داری. اگه به این سطح دسترسی نیاز داری، میزبانی وب و سرور مجازی ایران رو ببین.

از کجا بفهمم سرور ری استارت شده یا RAM تموم شده؟

اول uptime رو بزن تا ببینی سرور ری استارت شده یا نه. اگه سرور بالا بوده ولی یه سرویس افتاده، sudo dmesg -T | grep -i "killed process" رو بزن. اگه خروجی داد، سیستم برای آزاد کردن حافظه اون برنامه رو کشته.

یه عادت کوچیک برای هفته های بعد

لازم نیست همه این دستورها رو حفظ کنی. فقط همین ترتیب رو یاد بگیر: دیسک، پردازش، لاگ، شبکه. کم کم جواب ها سریع تر پیدا می شن و خوندن جای حدس زدن رو می گیره. اگه نمی خوای هر بار خودت چک کنی، مانیتورینگ و پایداری کمک می کنه زودتر هشدار بگیری. و قبل از هر تغییر جدی روی سرور، یه نگاه به بکاپ خودکار سرور مجازی؛ چه چیزی، کجا و هر چند وقت یک بار؟ بنداز.