ലിനക്സ് സെർവറിൽ "htop" കമാൻഡ് ഉപയോഗിച്ച് CPU-യും RAM-ഉം അധികം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റുകൾ കണ്ടെത്തുന്നത് എങ്ങനെ

ലിനക്സ് സെർവറിൽ htop കമാൻഡ് CPU (പ്രോസസ്സർ) ഉം RAM (മെമ്മറി) ഉം അതിവേഗം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റുകൾ യഥാർത്ഥ സമയത്ത് കണ്ടെത്താൻ ഉപയോഗിക്കുന്ന ഏറ്റവും പ്രായോഗികമായ നിരീക്ഷണ ഉപകരണങ്ങളിലൊന്നാണ്. htop ഇന്റർഫേസിൽ CPU%, MEM%, PID, USER, TIME+ എന്നിങ്ങനെ പല കോളങ്ങളുടെയും വിവരങ്ങൾ പരിശോധിച്ച് ഏത് PHP, Python, Node.js, ക്രോൺ ജോബ്, ഡാറ്റാബേസ് അല്ലെങ്കിൽ സിസ്റ്റം പ്രോസസ് സെർവറെ തളർത്തുകയാണ് എന്ന് മനസ്സിലാക്കാം. തുടർന്ന് ആ പ്രോസസിന്റെ ഉടമ, ഫയൽ പാത്ത്, പ്രവർത്തന ലക്ഷ്യം എന്നിവ പരിശോധിച്ച് സുരക്ഷിതമായി ഇടപെടാം.

പങ്കിടുന്ന ഹോസ്റ്റിംഗ്, VPS, VDS, ഡെഡിക്കേറ്റഡ് സെർവർ എന്നിവയിൽ വ്യത്യാസമില്ലാതെ, അനിയന്ത്രിതമായി പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റുകളാണ് പലപ്പോഴും എതെങ്കിലും അപ്രതീക്ഷിതമായ സ്ലോഡൗണുകൾക്ക് കാരണമെന്ന്. ഉദാഹരണത്തിന്, തെറ്റായ ഒരു WordPress പ്ലഗിൻ, അനന്ത ലൂപിൽ പെട്ട ഒരു PHP ഫയൽ, ഭാരമുള്ള ക്രോൺ ജോബ്, ഒപ്റ്റിമൈസ് ചെയ്യാത്ത ഡാറ്റാബേസ് ക്വറി, അല്ലെങ്കിൽ ഹാക്ക് ചെയ്ത വെബ് ഫയൽ മിനിറ്റുകൾക്കുള്ളിൽ CPU ഉപയോഗം 100% വരെ ഉയർത്തിയേക്കാം. RAM ഉപയോഗം കൂടിയാൽ സർവിസുകൾ തടസ്സപ്പെടുകയും MySQL കണക്ഷനുകൾ വീഴും, വെബ്‌സൈറ്റുകൾ 503 പിഴവ് നൽകും, ലിനക്സ് ഓർമ്മയില്ലായ്മ (OOM Killer) ചില പ്രോസസുകൾ അവസാനിപ്പിക്കും.

ഈ ഗൈഡിൽ htop ഇൻസ്റ്റാളേഷൻ മുതൽ സ്ക്രീൻ വായിക്കൽ, CPU-യും RAM-ഉം അധികം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റുകൾ തിരിച്ചറിയൽ, PID വഴി ഫയൽ പാത്ത് കണ്ടെത്തൽ, പ്രോസസിൽ സുരക്ഷിതമായി ഇടപെടൽ എന്നിവ വിശദീകരിക്കുകയാണ്. കൂടാതെ സുരക്ഷാ സംശയം, ക്രോൺ പരിശോധിക്കൽ, ലോഗ് വിശകലനം, വീണ്ടും സംഭവിക്കാതിരിക്കാനുള്ള ഓപ്റ്റിമൈസേഷൻ നിർദ്ദേശങ്ങളും ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. നിങ്ങളുടെ സെർവറിൽ സ്ഥിരമായി റിസോഴ്‌സ് ലിമിറ്റ് പ്രശ്നങ്ങൾ ഉണ്ടാകുന്നുവെങ്കിൽ, ഇൻഫ്രാസ്ട്രക്ചർ പരിഗണിക്കാൻ VPS സർവർ പാക്കേജുകൾ ഉം ഉയർന്ന പ്രവർത്തനക്ഷമതയുള്ള വെബ് ഹോസ്റ്റിങ് ഉം പരിശോധിക്കുക.

htop എന്താണ്? എന്തുകൊണ്ട് top കമാൻഡ്‌ക്കാൾ ഉത്തമം?

htop ഒരു ലിനക്സ് ടെർമിനൽ ഉപകരണം ആണ്, സിസ്റ്റത്തിൽ പ്രവർത്തിക്കുന്ന പ്രോസസ്സുകൾ ഇന്ററാക്ടീവ് ആയി കാണാനും നിയന്ത്രിക്കാനും സഹായിക്കുന്നു. പരമ്പരാഗത top കമാൻഡിനോട് സമാനമാണ്, പക്ഷെ കൂടുതൽ വായനാസഹജമായ ഇന്റർഫേസ്, നിറം ഉപയോഗിച്ച് റിസോഴ്‌സ് സ്റ്റാറ്റസ് കാണിക്കൽ, എളുപ്പത്തിൽ ക്രമീകരിക്കൽ, തിരയൽ, ഫിൽറ്റർ ചെയ്യൽ, പ്രോസസ് മാനേജ്മെന്റ് തുടങ്ങിയ നിർവാഹക സൗകര്യങ്ങൾ നൽകുന്നു. അതിനാൽ ലൈവ് സെർവറിൽ ത്വരിത പരിശോധന നടത്തുമ്പോൾ htop നാല് out of five സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർ ആദ്യം നോക്കുന്ന ടൂൾ ആണ്.

htop ഉപയോഗിച്ച് നിങ്ങൾക്ക് തൽക്ഷണികമായി കാണാൻ കഴിയുന്നത്:

• ഓരോ പ്രോസസ്സിന്റെയും CPU ശതമാനം
• ഓരോ പ്രോസസ്സിന്റെയും RAM ശതമാനം കൂടാതെ മെമ്മറി ഉപയോഗം
• പ്രോസസ് ഐഡി (PID) നമ്പർ
• പ്രോസസ് പ്രവർത്തിപ്പിക്കുന്ന യൂസർ
• കമാൻഡ് ലൈൻ അല്ലെങ്കിൽ സ്ക്രിപ്റ്റ് നാമം
• പ്രോസസ് പ്രവർത്തിച്ച സമയം, പ്രാഥമികതാ മൂല്യം
• ലോഡ് ഏവറേജ്, മൊത്തം RAM, സ്വാപ്പ്, CPU കോർ ഉപയോഗം

പ്രത്യേകിച്ച് ഒരു ഹോസ്റ്റിംഗ് പരിതസ്ഥിതിയിൽ ഒരേ സെർവറിൽ നിരവധി സൈറ്റുകൾ, യൂസറുകൾ അല്ലെങ്കിൽ സർവിസുകൾ പ്രവർത്തിക്കുമ്പോൾ മൊത്തം റിസോഴ്‌സ് ഉപയോഗം മാത്രം കാണുന്നത് മതിയാകില്ല. പ്രശ്നം ഏത് യൂസറിന്റേയും വെബ്‌സൈറ്റിന്റേയും ക്രോൺ ജോബിന്റേയും അല്ലെങ്കിൽ സ്ക്രിപ്റ്റ് ഫയലിന്റേയും ഒപ്പമാണ് എന്ന് കണ്ടെത്തേണ്ടതാണ്. ലിനക്സ് സെർവറിൽ htop ഈ കാര്യത്തിൽ വേഗത്തിലുള്ള പ്രാഥമിക പരിശോധനയ്ക്ക് സഹായകമാണ്.

htop ഇൻസ്റ്റാളേഷൻ: ഡിസ്‌ട്രിബ്യൂഷൻ അനുസരിച്ച് കമാൻഡുകൾ

പല ആധുനിക ലിനക്സ് ഡിസ്‌ട്രിബ്യൂഷനുകളിൽ htop ഡിഫോൾട്ട് ആയി ഉണ്ടാകാതെ ഇരിക്കാം. റൂട്ട് അല്ലെങ്കിൽ സുദോ അധികാരമുള്ളവർക്ക് അതിവേഗം ഇൻസ്റ്റാൾ ചെയ്യാനാകും. ഇൻസ്റ്റാളേഷൻ മുമ്പ് പാക്കേജ് ലിസ്റ്റ് അപ്ഡേറ്റ് ചെയ്യുന്നത് പ്രത്യേകിച്ച് പുതിയ സെർവറുകളിൽ പിഴവ് സാധ്യത കുറയ്ക്കുന്നു.

Ubuntu, Debian സെർവറുകളിൽ htop ഇൻസ്റ്റാളേഷൻ

Ubuntu / Debian അടിസ്ഥാനത്തിലുള്ള സെർവറുകളിൽ താഴെ കാണുന്ന കമാൻഡുകൾ ഉപയോഗിക്കാം:

sudo apt update

sudo apt install htop -y

ഇൻസ്റ്റാളേഷനു ശേഷം htop കമാൻഡ് ടൈപ്പ് ചെയ്ത് ടൂൾ ആരംഭിക്കാം. sudo അധികാരം ഇല്ലെങ്കിൽ, ഹോസ്റ്റിംഗ് ദാതാവിനോട് സഹായം അഭ്യർത്ഥിക്കേണ്ടി വരാം. VPS ഉപയോഗിച്ചാൽ സാധാരണയായി റൂട്ട് ആക്‌സസ് ലഭ്യമാണ്.

AlmaLinux, Rocky Linux, CentOS, RHEL ഇൻസ്റ്റാളേഷൻ

RHEL അടിസ്ഥാനത്തിലുള്ള സിസ്റ്റങ്ങളിൽ പാക്കേജ് മാനേജർ dnf അല്ലെങ്കിൽ yum ആകാം:

sudo dnf install htop -y

പഴയ CentOS പതിപ്പുകളിൽ EPEL റെപ്പോസിറ്ററി ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതുണ്ട്:

sudo yum install epel-release -y

sudo yum install htop -y

ഇൻസ്റ്റാളേഷൻ വിജയിച്ചാൽ, ടെർമിനലിൽ htop ടൈപ്പ് ചെയ്യുമ്പോൾ നിറമുള്ള നിരീക്ഷണ സ്ക്രീൻ തുറക്കും. സിസ്റ്റം മാനേജ്മെന്റിൽ പുതിയത് ആണെങ്കിൽ ലിനക്സ് കമാന്‍ഡ് ഗൈഡ് ഉള്ളടക്കം പ്രായോഗിക തുടക്കം നൽകും.

htop സ്ക്രീൻ വായിക്കൽ: ഓരോ കോളത്തിന്റെ അർത്ഥം

htop തുറന്നപ്പോൾ മുകളിൽ CPU കോറുകൾ, RAM, സ്വാപ്പ്, ടാസ്‌കുകളുടെ എണ്ണം, ത്രെഡ്‌സ്, ലോഡ് ഏവറേജും അപ്ടൈം വിവരങ്ങളും കാണാം. താഴെ പ്രവർത്തിക്കുന്ന പ്രോസസ്സുകളുടെ പട്ടിക കാണിക്കും. പ്രശ്നം കണ്ടെത്തുമ്പോൾ പ്രധാനമായി ഉപയോഗിക്കുന്ന കോളങ്ങൾ താഴെപ്പറയുന്നവയാണ്.

ഒരു തൽക്ഷണ CPU usage spike എന്നും പ്രശ്നമല്ല എന്നതാണ് ശ്രദ്ധിക്കേണ്ടത്. ഉദാഹരണത്തിന് ബാക്കപ്പ്, കാഷെ ക്ലിയർ, ട്രാഫിക് വർധന എന്നിവ സമയത്ത് CPU usage താൽക്കാലികമായി ഉയരാം. പ്രശ്നം ദീർഘകാലം ഉയർന്ന CPU അല്ലെങ്കിൽ RAM ഉപയോഗം, ലോഡ് ഏവറേജ് കോർ എണ്ണം കവിഞ്ഞ് ഉയരുന്നത്, വെബ് സർവിസുകൾ പ്രതികരിക്കാതിരിക്കുക എന്നിവയാണ്.

CPU അധികം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റുകൾ htop ഉപയോഗിച്ച് കണ്ടെത്തൽ

CPU-ഉം അധികം ഉപയോഗിക്കുന്ന പ്രോസസ്സുകൾ htop സ്ക്രീനിൽ F6 അമർത്തി ക്രമീകരണ സെക്ഷൻ തിരഞ്ഞെടുക്കുക അല്ലെങ്കിൽ CPU% കോളം പ്രകാരം ക്രമീകരിക്കുക. ചില ടർമിനലുകളിൽ മൗസ് ഉപയോഗിച്ച് CPU% തലക്കെട്ടിൽ ക്ലിക്ക് ചെയ്താലും മതി. ടേബിളിൽ മുകളിൽ കാണുന്ന പ്രോസസ്സുകൾ ഏറ്റവും കൂടുതൽ CPU ഉപയോഗിക്കുന്നവയാണ്.

പടി 1: CPU% പ്രകാരം ക്രമീകരിക്കുക

htop പ്രവർത്തിക്കുമ്പോൾ പ്രോസസ്സുകൾ CPU ഉപയോഗം അനുസരിച്ച് ക്രമീകരിക്കുക. ഉദാഹരണത്തിന് php-fpm, php, python3, node, java, mysqld, bash മുതലായ പ്രോസസ്സുകളിൽ ഏതെങ്കിലും ഒരാൾ സ്ഥിരമായി മുകളിൽ നിൽക്കുകയാണെങ്കിൽ അത് ശ്രദ്ധിക്കുക. ഒറ്റ കോർ സിസ്റ്റങ്ങളിൽ 100% സാധാരണ പരമാവധി ആണ്, എന്നാൽ മൾട്ടികോർ സിസ്റ്റങ്ങളിൽ 200% അല്ലെങ്കിൽ 400% വരെ കാണാം, ഇത് ഒരേ സമയം ഒന്നിലധികം കോർ ഉപയോഗിക്കുന്നതിന്റെ സൂചനയാണ്.

പടി 2: PID, USER വിവരങ്ങൾ കുറിക്കുക

സംശയാസ്പദമായ പ്രോസസിന്റെ PID, USER വിവരങ്ങൾ രേഖപ്പെടുത്തുക. ഉദാഹരണത്തിന് PID 24819, USER siteuser, COMMAND php /home/siteuser/public_html/wp-cron.php ആണെങ്കിൽ പ്രശ്നം ആ വെബ് സൈറ്റിലെ ക്രോൺ ജോബ് അല്ലെങ്കിൽ WordPress പ്രവർത്തനവുമായി ബന്ധപ്പെട്ടിരിക്കും. COMMAND കോളത്തിൽ കമാൻഡ് മുഴുവൻ കാണാൻ htop സെറ്റിംഗ്സിൽ മാറ്റം വരുത്താം അല്ലെങ്കിൽ ps കമാൻഡ് ഉപയോഗിച്ച് വിശദാംശങ്ങൾ എടുക്കാം.

പടി 3: പ്രോസസിന്റെ കമാൻഡ് വിശദമായി കാണുക

PID വഴി കമാൻഡ് ലൈൻ കാണാൻ:

ps -fp PID

ഉദാഹരണം:

ps -fp 24819

ഇത് സാധാരണയായി സ്ക്രിപ്റ്റ് പ്രവർത്തിക്കുന്ന ഫയൽ പാത്ത് കാണിക്കും. ഉദാ: php /home/user/public_html/index.php എന്നെങ്കിൽ അത് വെബ് റിക്വസ്റ്റ് ആകാം. php /home/user/public_html/wp-content/plugins/unknown-plugin/task.php ആണെങ്കിൽ പ്ലഗിൻ പ്രശ്നം ആകാം.

പടി 4: ഫയൽ പാത്തും തുറന്ന ഫയലുകളും പരിശോധിക്കുക

ഒരു പ്രോസസ്സ് തുറന്നിരിക്കുന്ന ഫയലുകൾ കാണാൻ lsof ഉപകരണം ഉപയോഗിക്കുക:

lsof -p PID

ഈ കമാൻഡ് പ്രോസസ്സ് തുറന്നിരിക്കുന്ന ഫയലുകൾ, ലൈബ്രറികൾ, ലോഗുകൾ, നെറ്റ്‌വർക്ക് കണക്ഷനുകൾ എന്നിവ കാണിക്കും. വെബ് ഹോസ്റ്റിംഗ് പരിതസ്ഥിതിയിൽ ഇത് ഏത് സൈറ്റ് ഡിറക്റ്ററിയിൽ പ്രവർത്തിക്കുന്നുവെന്ന് കണ്ടെത്താൻ സഹായിക്കുന്നു. ഉദാഹരണത്തിന് /home/example/public_html/wp-content/uploads-ൽ അനധികൃത PHP ഫയൽ കാണുന്നുവെങ്കിൽ സുരക്ഷാ പ്രശ്നം ഉണ്ടാകാം. അത്തരം ഘട്ടത്തിൽ പ്രോസസ്സ് കൊല്ലുന്നതിൽ മാത്രം പരിമിതപ്പെടരുത്; ഫയൽ ക്ലീൻ, പാസ്‌വേഡ് മാറ്റം, പ്ലഗിൻ അപ്ഡേറ്റ്, സുരക്ഷാ സ്കാൻ എന്നിവ നിർബന്ധമാണ്. SSL സേർട്ടിഫിക്കേറ്റ് ക്രമീകരണങ്ങൾക്ക് SSL സർട്ടിഫിക്കറ്റുകൾക്കുള്ള പരിഹാരങ്ങൾ കാണുക.

RAM അധികം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റുകൾ htop ഉപയോഗിച്ച് കണ്ടെത്തൽ

RAM പ്രശ്നങ്ങൾ CPU പ്രശ്നങ്ങളെക്കാൾ സൂക്ഷ്മമായി മാറും. CPU usage ഉയർന്നാൽ തൽക്ഷണ സ്ലോഡൗൺ അനുഭവപ്പെടും; RAM പൂർണ്ണമായാൽ സർവിസുകൾ അപ്രതീക്ഷിതമായി അടയ്ക്കപ്പെടും, സ്വാപ്പ് കൂടുതൽ ഉപയോഗിക്കും, സെർവർ മുഴുവനും മന്ദഗതിയിലാകും. htop-ൽ MEM% അനുസരിച്ച് ക്രമീകരിച്ച് കൂടുതൽ മെമ്മറി ഉപയോഗിക്കുന്ന പ്രോസസ്സുകൾ കണ്ടെത്താം.

MEM%, RES, സ്വാപ്പ് ബന്ധം മനസ്സിലാക്കുക

htop ഡിഫോൾട്ട് വ്യൂയിൽ MEM% കാണിക്കുന്നു. ചില സജ്ജീകരണങ്ങളിൽ VIRT, RES, SHR കോളങ്ങളും കാണാം. RAM വിശകലനത്തിൽ RES (Resident memory) ഏറ്റവും പ്രധാനപ്പെട്ടതാണ്, കാരണം പ്രോസസ്സ് യഥാർത്ഥ ഫിസിക്കൽ മെമ്മറിയിൽ ഉപയോഗിക്കുന്ന ഓർമ്മയുടെ അളവാണ് ഇത്. VIRT (വിർച്ച്വൽ മെമ്മറി) എല്ലാ സമയത്തും യഥാർത്ഥ RAM ഉപയോഗം അല്ല, അതുകൊണ്ട് മാത്രം വിശ്വസിക്കരുത്.

ഉദാഹരണം: 4 GB RAM ഉള്ള VPS-ൽ ഒരൊറ്റ PHP പ്രോസസ്സ് 900 MB RES ഉപയോഗിക്കുന്നത് സാധാരണ അല്ല. അതുപോലെ Node.js ആപ്പിന്റെ മെമ്മറി ഉപയോഗം 200 MB-ൽ നിന്ന് 1.5 GB വരെ വർധിക്കുന്നത് മെമ്മറി ലീക്കിന്റെ സൂചനയാകാം. MySQL/MariaDB-യിൽ ഉയർന്ന RAM ഉപയോഗം ചിലപ്പോൾ സാധാരണ കാഷെ പ്രവർത്തനമായിരിക്കാം; ആ സമയത്ത് ക്വറി പെർഫോർമൻസ്, ബഫർ സജ്ജീകരണങ്ങൾ, മൊത്തം സിസ്റ്റം മെമ്മറി എന്നിവ കൂടി വിലയിരുത്തണം.

RAM അധികം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റുകളുടെ സാധാരണ കാരണം

• അനന്ത ലൂപിൽ പെട്ട PHP, Python, Node.js കോഡുകൾ
• വലുതായ CSV, XML, JSON ഫയലുകൾ ഒരുതവണയിൽ മെമ്മറിയിൽ ലോഡ് ചെയ്യുന്നത്
• ഒപ്റ്റിമൈസ് ചെയ്യാത്ത WordPress പ്ലഗിനുകളും തീം ഫങ്ഷനുകളും
• ഇമേജ് പ്രോസസിംഗും PDF നിർമ്മാണവും വീഡിയോ കോൺവെർഷനും
• അപര്യാപ്ത കാഷെ ഉപയോഗം മൂലം ആവർത്തിക്കുന്ന ഭാരമുള്ള ക്വറികൾ
• ബോട്ട് ട്രാഫിക് അല്ലെങ്കിൽ അക്രമണങ്ങൾ കൊണ്ട് ഒരേ സ്ക്രിപ്റ്റ് പലതവണ പ്രവർത്തിക്കൽ
• മെമ്മറി ലീക്ക് ഉണ്ടാകുന്ന ദീർഘകാല ബാക്ക്ഗ്രൗണ്ട് സർവീസുകൾ

ഇത്തരത്തിലുള്ള പ്രശ്നങ്ങളിൽ kill കമാൻഡ് ഉപയോഗിച്ച് പ്രോസസ്സ് നിർത്തുന്നത് താൽക്കാലിക പരിഹാരമാകും. സ്ഥിരമായ പരിഹാരത്തിന് സ്ക്രിപ്റ്റ് എന്താണ് ചെയ്യുന്നത്, എന്ത് ഇൻപുട്ടുകൾ കൊണ്ട് പ്രവർത്തിക്കുന്നു, എന്തുകൊണ്ട് മെമ്മറി വിട്ടൊഴിയുന്നില്ല എന്നിവ വിശകലനം ചെയ്യണം.

htop-ൽ തിരയൽ, ഫിൽറ്റർ, ട്രീ വ്യൂ ഉപയോഗിക്കൽ

സെർവറിൽ നൂറുകണക്കിന് പ്രോസസ്സുകൾ പ്രവർത്തിച്ചാൽ ലിസ്റ്റിൽ മാനുവൽ തിരയൽ ബുദ്ധിമുട്ടാകും. htop ഈ സാഹചര്യത്തിൽ പ്രായോഗിക കീസൂചികൾ നൽകുന്നു. F3 അമർത്തി തിരയാം, F4 ഉപയോഗിച്ച് ഫിൽറ്റർ ചെയ്യാം, F5 അമർത്തി ട്രീ വ്യൂയ്ക്ക് മാറാം. ട്രീ വ്യൂ പാരന്റ്-ചൈൽഡ് ബന്ധം കാണാൻ ഉത്തമമാണ്. ഉദാഹരണത്തിന് nginx അല്ലെങ്കിൽ Apache കീഴിൽ പ്രവർത്തിക്കുന്ന php-fpm ചൈൽഡ് പ്രോസസ്സുകൾ, ക്രോൺ കീഴിൽ പ്രവർത്തിക്കുന്ന സ്ക്രിപ്റ്റുകൾ, supervisor നിയന്ത്രിക്കുന്ന Node.js സർവിസുകൾ എന്നിവ കാണാൻ സഹായിക്കും.

പ്രായോഗിക ഫിൽറ്റർ ഉദാഹരണങ്ങൾ

• php ടൈപ്പ് ചെയ്ത് PHP പ്രോസസ്സുകൾ മാത്രം കാണുക.
• python ടൈപ്പ് ചെയ്ത് Python സ്ക്രിപ്റ്റുകൾ വേർതിരിക്കുക.
• wp-cron ടൈപ്പ് ചെയ്ത് WordPress ക്രോൺ പ്രവർത്തനം പരിശോധിക്കുക.
• node ടൈപ്പ് ചെയ്ത് Node.js ആപ്പുകൾ പരിശോധിക്കുക.
• ഒരു പ്രത്യേക യൂസർനാമം ഫിൽറ്റർ ചെയ്ത് ആ ഹോസ്റ്റിംഗ് അക്കൗണ്ടിന്റെ പ്രോസസ്സുകൾ മാത്രം കാണുക.

ഈ ഫിൽറ്ററുകൾ പ്രത്യേകിച്ച് മൾട്ടി യൂസർ സെർവറുകളിൽ സമയം ലാഭിക്കും. ഉദാഹരണത്തിന് ഒരേ സെർവറിൽ 30 സൈറ്റുകളാണെങ്കിൽ USER കോളവും കമാൻഡ് പാത്തും ചേർന്ന് പ്രശ്നം ഏത് അക്കൗണ്ടിൽ നിന്നാണെന്ന് എളുപ്പത്തിൽ കണ്ടെത്താം. ഡൊമെയിൻ അടിസ്ഥാന പ്രോജക്റ്റുകൾക്ക് മാനേജ്മെന്റ് ലളിതമാക്കാൻ ഡൊമെയ്ൻ പരിശോധനം و രജിസ്റ്റർ സന്ദർശിക്കാം.

സംശയാസ്പദ PID-യ്ക്കുള്ള സുരക്ഷിത ഇടപെടൽ പദ്ധതി

വലിയ റിസോഴ്‌സ് ഉപയോഗിക്കുന്ന പ്രോസസ്സ് കണ്ടാൽ ഉടൻ kill -9 കമാൻഡ് ഉപയോഗിക്കാനുണ്ടാകും. എന്നാൽ ഇത് ഡാറ്റ നഷ്ടം, അർദ്ധം പൂരിപ്പിച്ച ഫയൽ എഴുതൽ, സർവീസ് അസാധാരണത എന്നിവക്ക് കാരണമാകാം. കൂടുതൽ സുരക്ഷിതമായ നടപടിക്രമം സ്വീകരിക്കണം.

1. പ്രോസസ്സ് രേഖപ്പെടുത്തുക

PID, USER, COMMAND, CPU%, MEM%, സമയ വിവരങ്ങൾ കുറിക്കുക. സാധ്യമെങ്കിൽ htop സ്ക്രീൻഷോട്ട് എടുക്കുക. ഈ രേഖകൾ പുനരാവൃത്തി പ്രശ്നങ്ങളിൽ താരതമ്യം ചെയ്യാനും, ടെക്നിക്കൽ റിപ്പോർട്ട് നൽകാനും സഹായിക്കും.

2. പ്രോസസിന്റെ ഫയൽ പാത്ത് സ്ഥിരീകരിക്കുക

ps -fp PID, lsof -p PID ഉപയോഗിച്ച് ഫയൽ പാത്ത് പരിശോധിക്കുക. വെബ് റൂട്ടിൽ ആണെങ്കിൽ ആപ്ലിക്കേഷൻ ലോഗുകൾ (WordPress-ലെ wp-content/debug.log, വെബ് സെർവർ എക്സസ്/എറർ ലോഗുകൾ, PHP-FPM slow log) പരിശോധിക്കുക.

3. ആദ്യം സൗമ്യമായി പ്രോസസ്സ് അവസാനിപ്പിക്കുക

പ്രോസസ്സ് നിയന്ത്രിക്കാനാകാതെ പോയാൽ ആദ്യമായി സാധാരണ kill സിഗ്നൽ അയയ്ക്കുക:

kill PID

ചില സെക്കൻഡുകൾ കാത്തു നോക്കി പ്രോസസ് അവസാനിച്ചിട്ടുണ്ടോ എന്ന് htop-ൽ പരിശോധിക്കുക. അവസാനിക്കാത്ത പക്ഷം, സിസ്റ്റം ആരോഗ്യത്തിന് ഭീഷണിയുണ്ടെങ്കിൽ മാത്രമേ kill -9 ഉപയോഗിക്കേണ്ടതുള്ളൂ:

kill -9 PID

kill -9 സിഗ്നൽ പ്രോസസ്സ് ക്ലീൻ ചെയ്യാനുള്ള അവസരം നൽകാതെ അവസാനിപ്പിക്കുന്നു, അതിനാൽ ഡേറ്റാബേസ്, ഫയൽ എഴുതൽ, ബാക്കപ്പ് ജോലികൾക്കായി ശ്രദ്ധിക്കണം.

4. പ്രോസസ്സ് വീണ്ടും തുടങ്ങുന്നുവെങ്കിൽ കാരണം കണ്ടെത്തുക

ഒരു പ്രോസസ്സ് നിർത്തിയിട്ടും മിണ്ടാതെ വീണ്ടും തുടങ്ങുന്നുവെങ്കിൽ പിന്നിൽ ക്രോൺ, systemd സർവീസ്, supervisor, വെബ് റിക്വസ്റ്റ്, ബോട്ട് ട്രാഫിക് തുടങ്ങിയവ ഉണ്ടാകാം. ക്രോൺ ലിസ്റ്റ് പരിശോധിക്കാൻ:

crontab -l

സിസ്റ്റം സർവീസ് സ്റ്റാറ്റസ് പരിശോധിക്കാൻ:

systemctl status servicename

വെബ് ട്രാഫിക് പരിശോധിക്കാൻ access log ഉപയോഗിക്കുക. WordPress wp-cron പ്രശ്നം ആണെങ്കിൽ യഥാർത്ഥ ക്രോൺ ക്രമീകരണം, കാഷെ പോളിസി പരിശോധിക്കുക.

htop ഫലങ്ങൾ ലോഗുകളുമായി സംയോജനം ചെയ്യുക

htop എന്താണ് അധികം ഉപയോഗിക്കുന്നത് കാണിക്കുന്നു; ലോഗുകൾ എന്തുകൊണ്ടാണ് ഉപയോഗിക്കുന്നത് മനസ്സിലാക്കാൻ സഹായിക്കുന്നു. രണ്ടു ഡാറ്റയും ചേർത്ത് ഉപയോഗിക്കാത്ത പക്ഷം അർത്ഥം കുറവാകും. ഉദാഹരണത്തിന്, htop-ൽ php-fpm പ്രോസസ്സിന്റെ CPU 180% കാണാം; എന്നാൽ ആ പ്രോസസ്സിനെ ഏത് URL അല്ലെങ്കിൽ ഏത് ബോട്ട് പ്രവർത്തിപ്പിക്കുന്നുവെന്ന് access log ഇല്ലാതെ അറിയാനാകില്ല.

പരിശോധിക്കേണ്ട ലോഗുകൾ:

• വെബ് സെർവർ access log: കൂടുതൽ അഭ്യർത്ഥനകളുള്ള URL-കൾ കാണിക്കും.
• വെബ് സെർവർ error log: PHP പിശകുകൾ, ഫയൽ അനുമതികൾ, 500 പിഴവുകൾ.
• PHP-FPM slow log: മന്ദഗതിയിലുള്ള PHP സ്ക്രിപ്റ്റുകൾ.
• MySQL slow query log: ഭാരമുള്ള SQL ക്വറികൾ.
• Auth log / secure log: സംശയാസ്പദ ലോഗിൻ ശ്രമങ്ങൾ.
• Cron log: ക്രോൺ ജോബുകളുടെ പ്രവർത്തന സമയം.

ഉദാഹരണത്തിന് htop-ൽ ഉയർന്ന CPU ഉപയോഗമുള്ള PID-ക്ക് access log-ൽ /wp-admin/admin-ajax.php-യിലേക്ക് ആയിരക്കണക്കിന് അഭ്യർത്ഥനകൾ ലഭിച്ചാൽ, പ്രശ്നം പ്ലഗിൻ, ബോട്ട് ട്രാഫിക് അല്ലെങ്കിൽ തെറ്റായ AJAX പ്രവർത്തനം ആകാം. ഈ സാഹചര്യത്തിൽ WAF, റേറ്റ് ലിമിറ്റ്, കാഷെ, പ്ലഗിൻ ഒപ്റ്റിമൈസേഷൻ ഒരുമിച്ച് പരിഗണിക്കണം. വെബ്‌സൈറ്റ് പ്രകടനം മെച്ചപ്പെടുത്താൻ വെബ് സൈറ്റിന്റെ വേഗം ഒപ്റ്റിമൈസേഷൻ സഹായകമാണ്.

സാധാരണ ലോഡ്, പ്രശ്നമുണ്ടാകുന്ന ലോഡ് വേർതിരിക്കൽ

എല്ലാ ഉയർന്ന റിസോഴ്‌സ് ഉപയോഗവും പ്രതിസന്ധിയല്ല. സെർവർ ഹാർഡ്‌വെയർ, ട്രാഫിക്, ആപ്പ് തരം, പരിപാലന പ്രവർത്തനങ്ങൾ എന്നിവ പരിഗണിക്കണം. 2 കോർ ഉള്ള VPS-ൽ ലോഡ് ഏവറേജ് 6-8 ദീർഘകാലം നിലനിൽക്കുന്നത് ഗൗരവമായ പ്രശ്നമാണ്. 16 കോർ ഡെഡിക്കേറ്റഡ് സെർവറിൽ അത് സാധാരണ ആകാം. അതിനാൽ ലോഡ് ഏവറേജ് വിലയിരുത്തുമ്പോൾ കോർ എണ്ണം മനസ്സിലാക്കണം.

ഈ താരതമ്യം അനാവശ്യ ഭയവും യഥാർത്ഥ പ്രശ്നവും വേർതിരിക്കാൻ സഹായിക്കും. പ്രത്യേകിച്ച് ഇ-കൊമേഴ്‌സ് സൈറ്റുകളിൽ ക്യാമ്പെയ്ൻ കാലഘട്ടങ്ങളിൽ, പേയ്‌മെന്റ് ഇന്റഗ്രേഷൻ, സ്റ്റോക്ക് അപ്‌ഡേറ്റുകൾ എന്നിവ താൽക്കാലികമായി റിസോഴ്‌സ് ഉപയോഗം വർധിപ്പിക്കും. എന്നാൽ ഉപയോക്തൃ അനുഭവം തകർക്കുന്നുവെങ്കിൽ ആപ് ഒപ്റ്റിമൈസേഷനും സെർവർ ശേഷിയും ഒരുമിച്ചു വിലയിരുത്തണം.

സുരക്ഷാ സംശയം: റിസോഴ്‌സ് ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റ് ഹാനികരമായിരിക്കുമോ?

CPU അല്ലെങ്കിൽ RAM അധികം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റ് എപ്പോഴും സാധാരണ പിശക് അല്ലാതിരിക്കാം. ഹാക്ക് ചെയ്ത വെബ്‌സൈറ്റുകളിൽ ആക്രമകർ സ്‌പാം അയയ്ക്കൽ, ക്രിപ്റ്റോ മൈനിങ്, പ്രോക്സി ട്രാഫിക്, DDoS ബോട്ട്, ബാക്ക്ഡോർ സ്ക്രിപ്റ്റുകൾ പ്രവർത്തിപ്പിക്കാം. htop-ൽ അന്യമായ യൂസർ കീഴിൽ പ്രവർത്തിക്കുന്ന അപ്രത്യക്ഷ കമാൻഡുകൾ, അന്യനാമ ഫയലുകൾ, /tmp, public_html/uploads-ൽ പ്രവർത്തിക്കുന്ന PHP ഫയലുകൾ എന്നിവ സുരക്ഷാ അപകടം സൂചിപ്പിക്കുന്നു.

സന്ദേഹം തോന്നിക്കുന്ന ലക്ഷണങ്ങൾ

• COMMAND കോളത്തിൽ അർത്ഥരഹിതമായ, അന്യനാമ ഫയൽ നാമങ്ങൾ
• /tmp, /dev/shm, uploads ഫോളഡറുകളിൽ നിന്ന് പ്രവർത്തിക്കുന്ന ഫയലുകൾ
• സാധാരണയായി കാണാത്ത perl, python, bash പ്രോസസ്സുകൾ
• ഉയർന്ന എക്സ്റ്റർണൽ നെറ്റ്‌വർക്ക് കണക്ഷനുകൾ
• ഒരു യൂസർ വളരെ കുറച്ചു സമയത്തിനുള്ളിൽ നിരവധി പ്രോസസ്സുകൾ ആരംഭിക്കുന്നത്
• വെബ് ഫയലുകളിൽ അടുത്തിടെ അനധികൃത മാറ്റങ്ങൾ

ഇത്തരം സാഹചര്യത്തിൽ പ്രോസസ്സ് നിർത്തുന്നതിനു മുമ്പ് സാധ്യമായത്ര തെളിവുകൾ ശേഖരിക്കുക. ഫയൽ അനുമതികൾ പരിശോധിക്കുക, ഹാനികര ഫയലുകൾ ഐസൊലേറ്റ് ചെയ്യുക, പാനൽ, CMS പാസ്‌വേഡുകൾ മാറ്റുക, പ്ലഗിൻ-തീം കോർ ഫയലുകൾ അപ്ഡേറ്റ് ചെയ്യുക, സുരക്ഷാ സ്കാൻ നടത്തുക. അഡ്മിൻ പാനലുകളിൽ 2-ഫാക്ടർ ഓഥന്റിക്കേഷൻ പ്രയോജനം ചെയ്യും, അനാവശ്യ എഴുതൽ അനുമതികൾ നീക്കം ചെയ്യുന്നത് ഭാവിയിൽ അപകടം കുറയ്ക്കും.

പ്രകടന പ്രശ്നങ്ങൾ വീണ്ടും സംഭവിക്കാതിരിക്കാൻ മികച്ച മാർഗങ്ങൾ

htop ഉപയോഗിച്ച് പ്രശ്നം കണ്ടെത്തുന്നത് പ്രധാനമാണ്; പക്ഷെ അതേ പ്രശ്നം വീണ്ടും വരാതിരിക്കാൻ മുൻകരുതലുകൾ എടുക്കുന്നത് അത്യാവശ്യമാണ്. താഴെ പറയുന്ന മുൻകരുതലുകൾ ലിനക്സ് സെർവറുകളിൽ CPU, RAM ഉപയോഗം മൂലമുള്ള തടസ്സങ്ങൾ കുറയ്ക്കുന്നതിൽ സഹായിക്കും.

• PHP memory_limit, max_execution_time, pm.max_children എന്നിവ സെർവർ ശേഷിക്ക് അനുസരിച്ച് ക്രമീകരിക്കുക.
• WordPress, Joomla, അല്ലെങ്കിൽ കസ്റ്റം ആപ്പുകളിൽ കാഷെ സിസ്റ്റം ഉപയോഗിക്കുക.
• അനാവശ്യ പ്ലഗിനുകൾ, തീമുകൾ, മോഡ്യൂളുകൾ നീക്കം ചെയ്യുക.
• MySQL slow query log ഉപയോഗിച്ച് ഭാരമുള്ള ക്വറികൾ ഒപ്റ്റിമൈസ് ചെയ്യുക.
• ക്രോൺ ജോബുകൾ ഒരേ സമയത്ത് ഓടിക്കരുത്; ഇടവേളകളിൽ ക്രമീകരിക്കുക.
• ബോട്ട് ട്രാഫിക് തടയാൻ rate limit, robots.txt, ഫയർവാൾ നിയമങ്ങൾ നടപ്പിലാക്കുക.
• ആപ്ലിക്കേഷൻ ലോഗുകൾ നിത്യേന റൊട്ടേറ്റ് ചെയ്ത് വലുതാകാതിരിക്കുക, ഡിസ്‌കും RAM-ഉം ബാധ ചെക്ക് ചെയ്യുക.
• സെർവർ മീറ്റ്രിക്‌സ് ക്രമീകരിച്ച് സ്ഥിരമായി നിരീക്ഷിക്കുക.

ഓപ്റ്റിമൈസേഷനുകൾ ചെയ്തിട്ടും റിസോഴ്‌സ് ഉപയോഗം ഉയർന്നിരുന്നാൽ, പ്രശ്നം സോഫ്റ്റ്‌വെയർ മാത്രമല്ല ആകാം. ട്രാഫിക് വർധിച്ചിട്ടുണ്ടാകാം, ആപ്പ് വികസിച്ചിരിക്കാം, നിലവിലുള്ള ഹോസ്റ്റിംഗ് പ്ലാൻ അപര്യാപ്തമായിരിക്കാം. അപ്പോൾ സ്കെയിലബിൾ VPS, കൂടുതൽ RAM, വേഗതയേറിയ NVMe ഡിസ്ക്, ഐസൊലേറ്റ് ചെയ്ത സെർവർ എന്നിങ്ങനെ പരിഗണിക്കേണ്ടതുണ്ട്. ആവശ്യകത വിലയിരുത്താൻ ഹോസ്റ്റിംഗ് പാക്കേജുകൾ ഉം കോർപ്പറേറ്റ് സർവർ പരിഹാരങ്ങൾ ഉം പരിശോധിക്കുക.

ഉദാഹരണ സീനാരിയോ: WordPress സൈറ്റിൽ CPU usage പൊട്ടിപ്പ്

ഒരു യാഥാർത്ഥ്യ സംഭവാവലി നോക്കാം. 4 കോർ, 8 GB RAM ഉള്ള VPS-ൽ പല WordPress സൈറ്റുകൾ പ്രവർത്തിക്കുന്നു. യൂസറുകൾ സൈറ്റ് മന്ദഗതിയിലാണെന്ന്, ചിലപ്പോൾ 502 പിഴവുകൾ കാണുന്നുവെന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. ടെർമിനലിൽ htop തുറന്നപ്പോൾ ലോഡ് ഏവറേജ് 12, എല്ലാ CPU കോറുകളും മുഴുവനും തിരക്കിലാണ്, ഒരേ USER-യുടെ php-fpm പ്രോസസ്സുകൾ മുകളിൽ കാണുന്നു.

F4 ഉപയോഗിച്ച് യൂസർ ഫിൽട്ടർ ചെയ്ത് CPU ഉപയോഗിക്കുന്ന പ്രോസസ്സിൽ നിന്ന് PID നോട്ട് ചെയ്യുന്നു. ps -fp PID കമാൻഡ് ഫലം php-fpm വർക്കർ കാണിക്കുന്നു; lsof -p PID വഴി /home/site/public_html/wp-content/plugins/example-importer/import.php ഫയൽ ഉപയോഗത്തിൽ കാണുന്നു. Access log പരിശോധിക്കുമ്പോൾ അതേ സമയം ആ ഫയൽ പ്രവർത്തിപ്പിക്കുന്ന അഡ്മിൻ റിക്വസ്റ്റ്, തുടർന്നുള്ള AJAX അഭ്യർത്ഥനകൾ ഉണ്ടെന്ന് കണ്ടെത്തുന്നു.

പരിഹാരമായി ഇമ്പോർട്ട് പ്രവർത്തനം നിർത്തുന്നു, പ്ലഗിൻ ക്രോൺ ജോബ് അപ്രാപ്തമാക്കുന്നു, വലിയ ഡാറ്റാ ഇമ്പോർട്ട് ഭാഗങ്ങളായി വിഭജിക്കുന്നു, PHP max_execution_time പരിഷ്കരിക്കുന്നു. കൂടാതെ wp-cron ഒഴിവാക്കി സിസ്റ്റം ക്രോൺ ഉപയോഗിക്കുന്നു. ഫലം, ലോഡ് ഏവറേജ് 12-ൽ നിന്ന് 1.8 ആയി കുറയുന്നു, CPU ഉപയോഗം സാധാരണ നിലയിലേയ്ക്ക് മടങ്ങുന്നു, വെബ് പ്രതികരണ സമയം വളരെ മെച്ചപ്പെടുന്നു. ഈ ഉദാഹരണം കാണിക്കുന്നു htop ഒറ്റക്ക് അല്ല; ps, lsof, ലോഗ് വിശകലനത്തോടെ ചേർന്ന് ഉപയോഗിക്കുമ്പോൾ എത്ര ഫലപ്രദമാണെന്ന്.

htop ഉപയോഗത്തിൽ സാധാരണ പിഴവുകൾ

• മുകളിലുള്ള പ്രോസസ്സുകൾ മാത്രം കൊല്ലുകയും കാരണം അന്വേഷിക്കാതിരിക്കുക.
• VIRT മൂല്യം യഥാർത്ഥ RAM ഉപയോഗം എന്ന് തെറ്റിദ്ധരിക്കുക.
• MySQL കാഷെ ഉപയോഗത്തെ നേരിട്ട് പ്രശ്നമായി കരുതുക.
• kill -9 കമാൻഡ് ആദ്യം ഉപയോഗിക്കുക.
• ലോഗ് പരിശോധിക്കാതെ അപ്ലിക്കേഷൻ അല്ലെങ്കിൽ യൂസറെ കുറ്റവാളിയാക്കുക.
• ലോഡ് ഏവറേജ് CPU കോർ എണ്ണം പരിഗണിക്കാതെ വിലയിരുത്തുക.
• സുരക്ഷാ സംശയം ഉണ്ടെങ്കിൽ ഫയൽ ഇന്റഗ്രിറ്റി പരിശോധിക്കാതിരിക്കുക.

ഈ പിഴവുകൾ ഒഴിവാക്കുന്നത് ഡൗൺടൈം കുറയ്ക്കുകയും തെറ്റായ ഇടപെടൽ മൂലമുള്ള ഡാറ്റ നഷ്ടം തടയുകയും ചെയ്യും. സിസ്റ്റം മാനേജ്മെന്റ് ശരിയായ പരിശോധനയ്ക്ക് വേഗതയിലും മുൻഗണന നൽകണം.

സാധാരണ ചോദിച്ച ചോദ്യങ്ങൾ

Linux സെർവറിൽ htop കമാൻഡ് എന്തിനാണ്?

Linux സെർവറിൽ htop കമാൻഡ് പ്രവർത്തിക്കുന്ന പ്രോസസ്സുകളുടെ CPU, RAM, യൂസർ, PID, കമാൻഡ് വിവരങ്ങൾ യഥാർത്ഥ സമയത്ത് കാണിക്കുന്നു. ഇതിലൂടെ CPU അല്ലെങ്കിൽ മെമ്മറി അധികം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റുകൾ വേഗത്തിൽ കണ്ടെത്താം.

CPU അധികം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റ് htop-ൽ എങ്ങനെ കണ്ടെത്താം?

htop-ൽ CPU% കോളം അനുസരിച്ച് ക്രമീകരിച്ച്, ഉയർന്ന CPU ഉപയോഗമുള്ള പ്രോസസിന്റെ PID, USER കുറിക്കുക. തുടർന്ന് ps -fp PID, lsof -p PID കമാൻഡുകൾ ഉപയോഗിച്ച് സ്ക്രിപ്റ്റിന്റെ ഫയൽ പാത്തും പ്രവർത്തനം സ്ഥിരീകരിക്കുക.

RAM വിശകലനത്തിൽ MEM% മിക്കവാറും VIRT-നേക്കാൾ വിശ്വാസയോഗ്യമാണോ?

അതെ, MEM% പ്രത്യേകിച്ച് RES മൂല്യം യഥാർത്ഥ RAM ഉപയോഗം സൂചിപ്പിക്കുന്നു. VIRT വ്യത്യസ്തമായ വിർച്ച്വൽ മെമ്മറി അളവാണ്, എല്ലായ്പ്പോഴും യഥാർത്ഥ RAM ഉപയോഗം അല്ല.

രിസോഴ്‌സ് കൂടുതലുള്ള പ്രോസസ്സ് ഉടൻ kill -9 ഉപയോഗിച്ച് നിർത്തുന്നത് ശരിയോ?

അവശ്യമായില്ല. ആദ്യം പ്രോസസ്സ് രേഖപ്പെടുത്തുക, ഫയൽ പാത്ത് പരിശോധിക്കുക, സാധാരണ kill PID കമാൻഡ് പരീക്ഷിക്കുക. kill -9 അവസാന മാർഗമാണ്, പ്രോസസ്സ് നിയന്ത്രിക്കാത്തപ്പോൾ മാത്രമേ ഉപയോഗിക്കണം.

htop-ൽ ഉയർന്ന CPU ഉപയോഗം എപ്പോഴും സുരക്ഷാ പ്രശ്നമല്ലേ?

ഇല്ല. ബാക്കപ്പ്, ഇമ്പോർട്ട്, കാഷെ നിർമ്മാണം, ട്രാഫിക് വർധന എന്നിവ CPU usage വർധിപ്പിക്കും. എന്നാൽ അന്യമായ ഫയൽ നാമങ്ങൾ, /tmp/uploads-ൽ പ്രവർത്തനം, അന്യമായ യൂസർ പ്രോസസ്സ് തുടങ്ങിയവ സുരക്ഷാ സംശയം ഉളവാക്കും.

സംഗ്രഹിച്ച്, ലിനക്സ് സെർവറിൽ htop കമാൻഡ് CPU, RAM അധികം ഉപയോഗിക്കുന്ന സ്ക്രിപ്റ്റുകൾ കണ്ടെത്താൻ വേഗതയുള്ള, പ്രായോഗിക, ഫലപ്രദമായ ടൂൾ ആണ്. ഏറ്റവും ശരിയായ ഫലം ലഭിക്കാൻ htop ഡാറ്റ PID അനാലിസിസ്, lsof ഔട്ട്പുട്ട്, ക്രോൺ പരിശോധന, ലോഗ് വിശകലനത്തോടെ സംയോജിപ്പിക്കുക. നിങ്ങളുടെ സെർവറിൽ റിസോഴ്‌സ് പ്രശ്നങ്ങൾ ആവർത്തിക്കുന്നുവെങ്കിൽ സോഫ്റ്റ്‌വെയർ ഒപ്റ്റിമൈസേഷനും ഇൻഫ്രാസ്ട്രക്ചർ ശേഷിയും ഒരുമിച്ച് വിലയിരുത്തുക; ആവശ്യമെങ്കിൽ Hostragons ന്റെ ഹോസ്റ്റിംഗ്, VPS, SSL പരിഹാരങ്ങൾ വിലയിരുത്തി നിങ്ങളുടെ പ്രോജക്ടിന് അനുയോജ്യമായ പ്ലാൻ തിരഞ്ഞെടുക്കുക.