Cara Mengesan Skrip Yang Guna CPU & RAM Berlebihan di Linux Server dengan htop

Di server Linux, perintah htop adalah salah satu alat pemantauan paling praktikal untuk mengenal pasti skrip yang menggunakan CPU dan RAM secara berlebihan secara langsung. Dengan memerhati paparan htop pada kolum CPU%, MEM%, PID, USER, TIME+ dan COMMAND, anda boleh kenal pasti proses PHP, Python, Node.js, cron, pangkalan data atau sistem yang memberatkan server; kemudian semak pemilik proses, laluan fail dan tujuan proses sebelum mengambil tindakan dengan selamat.

Masalah kelambatan mendadak di shared hosting, VPS, VDS atau dedicated server biasanya berpunca dari skrip yang berjalan tanpa kawalan. Contohnya plugin WordPress yang bermasalah, skrip PHP masuk infinite loop, cron job berat, kueri database tidak dioptimumkan, atau fail web yang telah digodam boleh menaikkan penggunaan CPU sehingga hampir 100% dalam beberapa minit. Apabila penggunaan RAM meningkat, servis boleh tergantung, sambungan MySQL terputus, laman web beri ralat 503, atau kernel Linux bertindak dengan OOM Killer untuk tamatkan proses-proses tertentu.

Panduan ini akan menerangkan langkah demi langkah dari pemasangan htop, cara membaca paparan, mengenal pasti skrip yang membebankan CPU dan RAM, mencari laluan fail melalui PID, dan menanganinya dengan selamat. Kami juga akan sentuh isu keselamatan, semakan cron, analisis log, serta cadangan optimisasi agar masalah tidak berulang. Jika server anda sering hadapi masalah sumber, semak pilihan infrastruktur di Pakej pelayan VPS dan Web hosting berprestasi tinggi.

Apa Itu htop dan Kenapa Lebih Praktikal daripada top?

htop ialah alat terminal interaktif untuk memantau proses di Linux. Ia mirip dengan perintah top klasik tetapi menawarkan paparan lebih mudah dibaca, indikator berwarna, pilihan penyusunan, carian, penapisan dan pengurusan proses yang lebih intuitif. Sebab itu, htop kerap menjadi pilihan utama sysadmin untuk diagnosis pantas di server sebenar.

Dengan htop, anda boleh pantau secara langsung:

• Penggunaan CPU setiap proses
• Penggunaan RAM & jumlah memori setiap proses
• Nombor PID proses
• Pengguna Linux yang menjalankan proses
• Nama skrip atau baris arahan proses
• Tempoh proses berjalan & nilai keutamaan
• Load average, RAM total, swap & penggunaan CPU core

Bagi hosting yang mengendalikan banyak laman, pengguna atau servis dalam satu server, melihat jumlah penggunaan saja tidak mencukupi. Anda perlu tahu proses mana, pengguna mana, laman mana, cron job atau skrip mana yang sebenarnya bermasalah. htop membantu diagnosis awal dengan pantas di Linux server.

Pemasangan htop: Arahan Mengikut Distro

htop mungkin tidak tersedia secara default di kebanyakan distro Linux moden. Jika anda ada akses root atau sudo, anda boleh pasang dalam beberapa saat. Pastikan kemaskini senarai pakej sebelum pasang, terutamanya di server baru bagi mengurangkan risiko error.

Pemasangan htop di Ubuntu dan Debian

Untuk server berasaskan Ubuntu/Debian, gunakan:

sudo apt update

sudo apt install htop -y

Selepas pemasangan, taip htop untuk mulakan aplikasi. Jika tiada akses sudo, minta bantuan provider hosting. Dengan VPS yang boleh diurus, akses root biasanya milik anda.

Pemasangan di AlmaLinux, Rocky Linux, CentOS dan RHEL

Sistem RHEL biasanya guna dnf atau yum mengikut versi:

sudo dnf install htop -y

Bagi CentOS lama, aktifkan EPEL repo:

sudo yum install epel-release -y

sudo yum install htop -y

Jika berjaya, taip htop di terminal untuk buka paparan berwarna. Untuk asas pengurusan server, rujuk panduan arahan Linux untuk panduan command line yang praktikal.

Cara Membaca Paparan htop: Maksud Setiap Kolum

Pada paparan htop, bahagian atas menunjukkan CPU core, RAM, swap, jumlah task, thread, load average dan uptime. Bahagian bawah menyenaraikan proses aktif. Kawasan utama untuk diagnosis adalah seperti berikut.

Perlu diingat, lonjakan CPU sebentar tidak semestinya masalah. Misalnya backup, optimasi gambar, pembersihan cache atau trafik tinggi boleh sebabkan CPU naik seketika. Masalah timbul bila proses yang sama gunakan CPU/RAM tinggi berpanjangan, load average melampaui bilangan core dan servis web gagal respons.

Cara Kesan Skrip Guna CPU Berlebihan dengan htop

Untuk kenal pasti skrip yang guna CPU berlebihan, susun proses mengikut CPU% (guna F6 atau klik pada CPU% jika mouse support ada). Proses paling atas adalah yang sedang gunakan CPU terbanyak.

Langkah 1: Susun Mengikut CPU%

Pada htop, susun proses ikut CPU%. Jika php-fpm, php, python3, node, java, mysqld atau bash sering muncul di atas, catat proses tersebut. Di server multi-core, satu proses boleh capai 200% atau 400% CPU (menunjukkan ia guna banyak core).

Langkah 2: Catat PID dan USER

Ambil nota PID dan USER proses yang mencurigakan. Contoh: PID 24819, USER siteuser, COMMAND php /home/siteuser/public_html/wp-cron.php menunjukkan kemungkinan masalah pada cron WordPress di laman itu. Jika COMMAND terlalu pendek, aktifkan paparan penuh atau guna ps untuk lihat details.

Langkah 3: Lihat Arahan Sebenar Proses

Untuk lihat arahan penuh dari PID, gunakan:

ps -fp PID

Contoh:

ps -fp 24819

Output biasanya akan tunjuk laluan fail skrip. Jika arahan seperti php /home/kullanici/public_html/index.php, ia mungkin permintaan web biasa. Jika php /home/kullanici/public_html/wp-content/plugins/plugin-tak-dikenali/task.php, mungkin plugin bermasalah.

Langkah 4: Semak Laluan Fail & Fail Terbuka

Untuk semak fail yang digunakan proses, gunakan lsof:

lsof -p PID

Komut ini tunjuk fail terbuka, library, log dan sambungan network oleh proses. Di hosting, output ini bantu kenal pasti folder laman aktif. Jika ada fail PHP pelik dalam /home/example/public_html/wp-content/uploads, ini mungkin tanda kompromi keselamatan. Jangan sekadar tamatkan proses; lakukan pembersihan fail, tukar password, kemaskini plugin dan scan keselamatan. Untuk konfigurasi SSL, rujuk Penyelesaian sijil SSL.

Kesan Skrip Guna RAM Berlebihan dengan htop

Masalah RAM selalunya lebih tersembunyi dari CPU. Jika CPU naik, terasa kelambatan; bila RAM habis, servis boleh tutup tiba-tiba, swap digunakan secara intensif dan server jadi perlahan. Susun proses mengikut MEM% untuk kenal pasti proses guna RAM terbanyak.

Fahami Hubungan MEM%, RES & Swap

htop tunjuk MEM% secara default. Kadang-kadang VIRT, RES dan SHR juga dipaparkan. RES sangat penting kerana ia tunjuk penggunaan RAM fizikal sebenar oleh proses. VIRT hanya tunjuk memori maya yang diperuntukkan, tak semestinya digunakan.

Contohnya di VPS 4 GB RAM, jika proses PHP guna 900 MB RES, itu tidak normal. Node.js yang naik dari 200 MB ke 1.5 GB boleh jadi memory leak. Untuk MySQL/MariaDB, RAM tinggi kadang-kadang normal untuk cache; semak jenis kueri, buffer dan kapasiti RAM keseluruhan.

Punca Umum Skrip Guna RAM Berlebihan

• Kod PHP, Python atau Node.js masuk infinite loop
• Import fail CSV, XML, JSON besar terus ke RAM
• Plugin WordPress/tema tidak dioptimumkan
• Proses gambar, PDF, atau video conversion
• Kueri berat berulang kerana cache kurang
• Bot/suspek trafik jalankan skrip sama berulang kali
• Servis background lama ada memory leak

Tamatkan proses dengan kill hanya beri kelegaan sementara. Penyelesaian kekal memerlukan analisis apa skrip buat, input yang mencetuskan dan kenapa memori tidak dibersihkan.

Carian, Penapisan & Paparan Pokok di htop

Dengan ratusan proses berjalan, carian manual jadi sukar. htop menawarkan shortcut praktikal: F3 untuk cari, F4 untuk tapis, F5 untuk paparan pokok (tree view). Tree view penting untuk lihat hubungan parent-child. Contohnya, php-fpm child di bawah nginx/apache, skrip cron dipanggil, atau servis Node.js di bawah supervisor lebih jelas dilihat.

Contoh Penapisan Praktikal

• Tulis "php" untuk hanya lihat proses PHP
• "python" untuk skrip Python
• "wp-cron" untuk pantau cron WordPress
• "node" untuk aplikasi Node.js
• Tapis nama pengguna untuk lihat proses akaun hosting tertentu

Penapisan ini sangat berguna di server multi-user. Jika ada 30 laman dalam satu server, USER dan laluan skrip membantu kenal pasti punca masalah dengan cepat. Untuk urus domain dengan mudah, rujuk Semakan domain dan pendaftaran.

Langkah Selamat Tangani PID Mencurigakan

Ramai tergoda untuk guna kill -9 segera pada proses bermasalah. Namun, tindakan ini boleh sebabkan kehilangan data, proses menulis tergantung, atau servis jadi tidak konsisten. Ikuti pelan tindakan lebih selamat.

1. Catat Maklumat Proses

Catat PID, USER, COMMAND, CPU%, MEM% dan masa proses. Ambil screenshot htop jika boleh. Rekod ini berguna untuk analisa berulang atau laporan teknikal kepada klien.

2. Sahkan Laluan Fail Proses

Guna ps -fp PID dan lsof -p PID untuk sahkan laluan fail. Jika fail di web root, semak log aplikasi. WordPress: wp-content/debug.log, web server: access/error log, PHP-FPM: slow log.

3. Cuba Tamatkan Dengan Sopan Dahulu

Jika proses memang tidak terkawal, beri signal tamat standard:

kill PID

Tunggu beberapa saat & semak di htop sama ada proses tamat. Jika tidak dan server terjejas teruk, baru guna:

kill -9 PID

kill -9 tamatkan proses tanpa peluang cleanup; berhati-hati untuk proses database, penulisan fail atau backup.

4. Cari Punca Jika Proses Berulang

Jika proses muncul semula, semak cron, systemd, supervisor, trafik web atau bot. Cron: crontab -l, sistem servis: systemctl status nama-servis, trafik web: access log. Untuk WordPress wp-cron, semak konfigurasi cron sebenar & cache.

Gabungkan htop dengan Analisis Log

htop tunjuk siapa guna sumber; log pula tunjuk kenapa. Jika tidak digabungkan, diagnosis tidak lengkap. Misalnya, htop tunjuk php-fpm guna 180% CPU, tetapi tanpa access log anda tidak tahu URL atau bot mana cetus proses tersebut.

Semak log berikut:

• Access log web server: Tunjuk URL yang paling banyak permintaan
• Error log web server: Tunjuk error PHP, permission, error 500
• PHP-FPM slow log: Tunjuk fail/fungsi PHP perlahan
• MySQL slow query log: Kesan kueri SQL berat
• Auth/secure log: Kesan cubaan login mencurigakan
• Cron log: Tunjuk masa cron job dijalankan

Contohnya, jika PID tinggi CPU di htop sama waktu dengan ribuan permintaan ke /wp-admin/admin-ajax.php dalam access log, masalah mungkin plugin, bot trafik atau AJAX yang tidak dioptimumkan. Cari WAF, rate limit, cache & optimisasi plugin. Untuk panduan kelajuan laman, rujuk Pengoptimuman Kelajuan Laman Web.

Bezakan Beban Normal & Bermasalah

Tidak semua penggunaan sumber tinggi adalah krisis. Pertimbangkan spesifikasi server, tahap trafik, jenis aplikasi & waktu penyelenggaraan. Untuk VPS 2 core, load average 6-8 berpanjangan adalah bottleneck. Di dedicated 16 core, nilai sama mungkin normal. Load average mesti dibandingkan dengan jumlah core.

Perbandingan ini bantu elak panik berlebihan & fokus pada krisis sebenar. Di laman e-dagang, musim kempen, integrasi pembayaran & update stok boleh naikkan beban sementara. Jika pengalaman pengguna terjejas, optimisasi aplikasi & kapasiti server perlu dipertimbangkan bersama.

Risiko Keselamatan: Adakah Skrip Berat Berbahaya?

Skrip yang guna CPU/RAM berlebihan tidak selalu disebabkan bug. Laman yang dikompromi boleh jalankan spam, mining kripto, proxy, DDoS bot atau skrip pintu belakang. Dalam htop, proses dengan pengguna tidak dijangka, arahan pelik, fail random, proses dari /tmp atau uploads perlu diambil serius.

Tanda-tanda Mencurigakan

• Nama fail dalam COMMAND yang tidak masuk akal/random
• Proses berjalan dari /tmp, /dev/shm atau uploads
• Proses perl, python, bash yang tidak sepatutnya
• Proses buat sambungan network luar tidak dijangka
• Pada satu masa, pengguna sama mulakan banyak proses
• Ada perubahan fail web yang tidak sah

Sebelum tamatkan proses, ambil output komut sebagai bukti. Semak permission fail, asingkan fail berbahaya, tukar semua password panel & CMS, kemaskini plugin/tema/core & buat scan keselamatan. Guna 2FA di panel admin & buang permission menulis yang tidak diperlukan untuk jangka panjang.

Amalan Terbaik Elak Masalah Berulang

Menemukan masalah dengan htop penting; yang lebih bernilai ialah mencegah berulang. Langkah berikut boleh kurangkan masalah CPU & RAM di Linux server:

• Set memory_limit, max_execution_time, pm.max_children PHP ikut kapasiti server
• Aktifkan cache di WordPress, Joomla, atau sistem custom
• Buang plugin, tema, modul yang tidak diperlukan
• Optimumkan kueri berat dengan MySQL slow query log
• Jangan jadualkan semua cron pada masa sama; jarakkan
• Guna rate limit, robots.txt, firewall untuk trafik bot
• Pusing log aplikasi secara berkala; awasi impak log besar pada disk/RAM
• Pantau metrik server secara konsisten, bukan hanya ketika krisis

Jika sudah optimum tetapi penggunaan sumber tetap tinggi, mungkin aplikasi berkembang, trafik naik atau pakej hosting tidak cukup. Pertimbangkan VPS scalable, tambah RAM, disk NVMe laju, atau server dengan sumber terasing. Bandingkan pilihan di Pakej Hosting dan penyelesaian pelayan korporat untuk analisa keperluan.

Contoh Senario: CPU Meletup di Laman WordPress

Contoh nyata: VPS 4 core/8 GB RAM, beberapa laman WordPress. Pengguna mengadu laman perlahan & kadang-kadang ralat 502. Buka htop: load average 12, semua core CPU penuh, banyak proses php-fpm bawah pengguna sama di barisan atas.

Guna F4 tapis nama pengguna. PID proses berat dicatat. ps -fp PID tunjuk worker php-fpm; lsof -p PID dedahkan akses ke /home/site/public_html/wp-content/plugins/example-importer/import.php. Access log tunjuk permintaan admin & panggilan AJAX berulang ke fail tersebut pada masa sama.

Penyelesaiannya: hentikan proses import, matikan scheduled plugin, pecahkan proses import data besar, reset max_execution_time PHP. Gantikan wp-cron dengan cron sistem. Load average turun dari 12 ke 1.8, CPU kembali normal, laman respons lebih pantas. Ini membuktikan htop paling efektif bila digabungkan dengan ps, lsof & analisis log.

Kesilapan Lazim Semasa Guna htop

• Tamatkan proses teratas tanpa siasat punca sebenar
• Salah anggap VIRT sebagai penggunaan RAM sebenar
• Anggap penggunaan RAM MySQL untuk cache sebagai masalah
• Guna kill -9 sebagai pilihan pertama
• Tuduh aplikasi/pengguna tanpa semak log
• Tak ambil kira bilangan CPU core semasa nilai load average
• Tidak semak integriti fail jika berlaku kompromi keselamatan

Elak kesilapan ini untuk kurangkan downtime & risiko kehilangan data akibat tindakan salah. Diagnosis tepat lebih bernilai dari tindakan terburu-buru.

Soalan Lazim

Apa kegunaan htop di server Linux?

htop memaparkan proses aktif dengan data CPU, RAM, pengguna, PID dan arahan secara langsung. Anda boleh kenal pasti skrip yang membebankan sumber dengan cepat.

Bagaimana kesan skrip guna CPU tinggi dengan htop?

Susun proses ikut CPU% di htop, catat PID & USER proses yang kekal di atas. Guna ps -fp PID dan lsof -p PID untuk sahkan laluan skrip & apa yang dijalankan.

Untuk analisis RAM, patut fokus MEM% atau VIRT?

Fokus pada MEM% dan terutamanya RES. VIRT tunjuk memori maya diperuntukkan, bukan penggunaan RAM fizikal sebenar.

Adakah selamat tamatkan proses berat dengan kill -9?

Tidak selalunya. Catat dulu maklumat proses, sahkan laluan fail, cuba tamatkan dengan kill biasa. kill -9 hanya jika proses tidak boleh ditamatkan dan server terjejas teruk.

Adakah penggunaan CPU tinggi di htop selalu tanda serangan?

Tidak semestinya. Proses backup, import, cache, trafik tinggi juga boleh naikkan CPU. Tetapi arahan/fail pelik, proses dari /tmp/uploads dan pengguna tidak dijangka perlu disiasat dari sudut keselamatan.

Kesimpulannya, htop ialah titik permulaan yang pantas dan efektif untuk kesan skrip yang guna CPU & RAM berlebihan di server Linux. Gabungkan analisis htop dengan PID, lsof, cron dan log untuk diagnosis lebih tepat. Jika masalah sumber berulang, optimisasi aplikasi dan infrastruktur perlu ditimbang bersama; bandingkan solusi hosting, VPS dan SSL Hostragons tanpa tekanan jualan untuk dapatkan struktur terbaik bagi projek anda.