લિનક્સ સર્વર પર htop કમાન્ડ એક પ્રેક્ટિકલ ટૂલ છે જે CPU અને RAMનું વધારે વપરાશ કરતી સ્ક્રિપ્ટ્સને રિયલ ટાઈમમાં ઓળખવામાં મદદ કરે છે. htopની સ્ક્રીનમાં CPU%, MEM%, PID, USER, TIME+ અને COMMAND કૉલમ્સ જોવી અને સમજવી સરળ છે, જેથી તમે જાણી શકો કે કઈ PHP, Python, Node.js, cron, ડેટાબેઝ કે સિસ્ટમ પ્રોસેસ સર્વરને ભારે બનાવી રહી છે; ત્યારબાદ તે પ્રોસેસનું માલિક કોણ છે, ફાઈલ પાથ શું છે અને તેનો ઉપયોગ શે માટે થાય છે તે તપાસીને સુરક્ષિત રીતે હસ્તક્ષેપ કરી શકો છો.
ચાહક હોસ્ટિંગ, VPS, VDS કે ડેડિકેટેડ સર્વર હોય, અચાનક ધીમી પડવાની મોટાભાગની સમસ્યા અયોગ્ય રીતે ચાલતી સ્ક્રિપ્ટ્સના કારણે થાય છે. ઉદાહરણ તરીકે, ખોટા વર્ડપ્રેસ પ્લગઇન, અનંત લૂપમાં ફસાયેલું PHP ફાઈલ, ભારે ચાલતી cron ટાસ્ક, ઓપ્ટિમાઇઝ ન થયેલી ડેટાબેઝ ક્વેરી કે કોઈ હેક થયેલી વેબ ફાઈલ થોડા મિનિટમાં CPU વપરાશ 100% સુધી લઈ જઈ શકે છે. જ્યારે RAMનું વપરાશ વધે છે, ત્યારે સર્વિસીસ સ્લો થઈ શકે છે, MySQL કનેક્શન્સ ડ્રોપ થઈ શકે છે, વેબસાઇટ્સ 503 એરર આપી શકે છે કે લિનક્સ કર્નલ OOM Killer દ્વારા કેટલાક પ્રોસેસીસ બંધ કરવામાં આવી શકે છે.
આ માર્ગદર્શિકામાં htop ઇન્સ્ટોલ કરવાથી શરૂ કરીને સ્ક્રીન કેવી રીતે વાંચવી, CPU અને RAM વધારે વપરાતી સ્ક્રિપ્ટ્સ કેવી રીતે ઓળખવી, PID પરથી ફાઈલ પાથ કેવી રીતે શોધવો અને પ્રોસેસમાં સુરક્ષિત રીતે હસ્તક્ષેપ કેવી રીતે કરવો તે તમામ પગલાંવાર સમજાવાશે. સાથે જ સુરક્ષા સંશય, cron ચકાસણી, લોગ વિશ્લેષણ અને ફરી આવી સમસ્યા ન થાય તે માટેના પ્રાયોગિક સુધારા સૂચવશે. જો તમારું સર્વર વારંવાર રિસોર્સ લિમિટ સમસ્યાઓનો સામનો કરે છે, તો VPS સર્વર પેકેટ અને ઉચ્ચ પ્રદર્શનવાળું વેબ હોસ્ટિંગ પેજો જોઈને તમારી ઇન્ફ્રાસ્ટ્રક્ચર વધુ સારી રીતે પસંદ કરી શકો છો.
htop શું છે અને top કમાન્ડ કરતા કેમ વધુ ઉપયોગી છે?
htop એ લિનક્સ સિસ્ટમ પર ચાલતા પ્રોસેસીસને ઈન્ટરેક્ટિવ રીતે મોનિટર કરવા માટેનો ટર્મિનલ ટૂલ છે. તે પરંપરાગત top કમાન્ડ જેવું છે, પણ વધુ વાચનીય ઈન્ટરફેસ, રંગીન રિસોર્સ દશકો, સરળ સોર્ટિંગ, શોધ, ફિલ્ટર અને પ્રોસેસ મેનેજમેન્ટ ફીચર્સ પ્રદાન કરે છે. આથી ખાસ કરીને લાઇવ સર્વર પર ઝડપી નિદાન માટે htop ઘણી સિસ્ટમ એડમિનિસ્ટ્રેટર્સની પહેલી પસંદગિ હોય છે.
htop સાથે તમે તાત્કાલિક આ માહિતી જોઈ શકો છો:
- દરેક પ્રોસેસનું CPU વપરાશ ટકા
- દરેક પ્રોસેસનું RAM વપરાશ ટકા અને મેમરી માત્રા
- પ્રોસેસનું PID નંબર
- પ્રોસેસ ચલાવનાર યુઝર
- કમાન્ડ લાઈન અથવા સ્ક્રિપ્ટનું નામ
- ચાલવાની સમયગાળા અને પ્રાથમિકતા મૂલ્ય
- લોડ એવરેજ, કુલ RAM, સ્વેપ અને CPU કોર ઉપયોગ
ખાસ કરીને હોસ્ટિંગ પર્યાવરણમાં જ્યાં એક સર્વર પર અનેક સાઇટ્સ, યુઝર્સ અથવા સર્વિસેસ એકસાથે ચાલે છે, ત્યાં ફક્ત કુલ રિસોર્સ વપરાશ જોવો પૂરતો નથી. સમસ્યા કયા યુઝર, કયા વેબસાઇટ, કયા ક્રોન ટાસ્ક કે કયા સ્ક્રિપ્ટ ફાઈલ સાથે સંબંધિત છે તે શોધવું જરૂરી છે. લિનક્સ સર્વર ઉપર htop કમાન્ડ આ માટે ઝડપી પ્રાથમિક નિદાન આપે છે.
htop ઇન્સ્ટોલેશન: ડિસ્ટ્રો અનુસાર કમાન્ડ્સ
ઘણાં આધુનિક લિનક્સ ડિસ્ટ્રોની સાથે htop પ્રી-ઇન્સ્ટોલ ન હોય શકે. જો તમારી પાસે root કે sudo અધિકાર હોય તો તમે થોડા સેકંડમાં તેને ઇન્સ્ટોલ કરી શકો છો. ઇન્સ્ટોલ કરતા પહેલાં પેકેજ લિસ્ટ અપડેટ કરવી ખાસ કરીને નવી સર્વર પર ભૂલ થવાની શક્યતા ઘટાડે છે.
Ubuntu અને Debian સર્વરો પર htop ઇન્સ્ટોલ કરવા
Ubuntu કે Debian આધારિત સર્વર પર આ કમાન્ડ્સ ચાલાવો:
sudo apt update
sudo apt install htop -y
ઇન્સ્ટોલ થયા પછી htop લખીને ટૂલ ચાલુ કરી શકો છો. જો sudo અધિકાર ન હોય તો હોસ્ટિંગ પ્રોવાઇડર પાસેથી મદદ લેવી પડે. મેનેજેબલ VPS હોય તો root એક્સેસ સામાન્ય રીતે તમારી પાસે હોય છે.
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, સ્વેપ, ટાસ્ક સંખ્યા, થ્રેડ સંખ્યા, લોડ એવરેજ અને અપટાઇમ માહિતી હોય છે. નીચે ભાગમાં ચાલતા પ્રોસેસીસની યાદી હોય છે. નિદાનમાં સૌથી વધુ ઉપયોગી કૉલમ્સ નીચે મુજબ છે.
| કૉલમ | અર્થ | ક્યારે શંકા કરવી? |
|---|---|---|
| PID | પ્રોસેસનું અનન્ય ઓળખ નંબર. | ફાઈલ પાથ અને કનેક્શન્સ તપાસવા માટે જરૂરી. |
| USER | પ્રોસેસ ચલાવનાર લિનક્સ યુઝર. | અનપેક્ષિત યુઝર હેઠળ ચાલતો પ્રોસેસ જોઈને ચકાસવું. |
| CPU% | પ્રોસેસનું તાત્કાલિક CPU વપરાશ. | દીર્ઘ સમય 80-100% વચ્ચે રહેતો પ્રોસેસ તપાસવો. |
| MEM% | પ્રોસેસ દ્વારા વપરાતી કુલ RAMની ટકાવારી. | એક જ સ્ક્રિપ્ટ 20% કે તેથી વધુ RAM લઇ રહ્યો હોય તો જોખમ. |
| TIME+ | પ્રોસેસે કુલ ઉપયોગ કર્યો CPU સમય. | લાંબા સમયથી ચાલતો અને વધારે રિસોર્સ વપરતો પ્રોસેસ દર્શાવે. |
| COMMAND | ચાલતી કમાન્ડ, સર્વિસ કે સ્ક્રિપ્ટનું નામ. | php, python, node, perl, bash, java જેવા પ્રોસેસમાં ફાઈલ પાથ તપાસવો. |
આમાં એક મહત્વપૂર્ણ વાત એ છે કે CPUમાં તાત્કાલિક વધારાને હંમેશા સમસ્યા માનવી નહીં. જેમ કે બેકઅપ, ઈમેજ ઓપ્ટિમાઇઝેશન, કેશ ક્લીનિંગ કે ટ્રાફિક વધ્યા સમયે થોડીકવાર CPU usage વધી શકે. ખરાબી ત્યારે થાય છે, જ્યારે એક જ પ્રોસેસ મિનિટો સુધી ઊંચું CPU કે RAM વાપરે, લોડ એવરેજ કોર સંખ્યાના ઘણાં ઉપર જાય અને વેબ સર્વિસીસ ધીમી કે અપ્રતિસાદી થાય.
CPU વધારે વપરાતા સ્ક્રિપ્ટ્સ htop થી શોધવા
CPU પર ભારે પ્રેશર નાખતી સ્ક્રિપ્ટ શોધવા માટે htop સ્ક્રીન પર F6 દબાવીને સૉર્ટિંગ સેટ કરી શકો કે સીધા CPU% કૉલમ પર ક્લિક કરી શકો. જો તમારા ટર્મિનલમાં માઉસ સપોર્ટ છે તો ક્લિક કરવું જ પૂરતું છે. ટોચે દેખાવતી પ્રોસેસીસ સૌથી વધુ CPU વાપરે છે.
પગલું 1: CPU% પ્રમાણે સૉર્ટ કરો
htopમાં ચાલતી પ્રોસેસીસને CPU વપરાશ પ્રમાણે સૉર્ટ કરો. ઉદાહરણ તરીકે php-fpm, php, python3, node, java, mysqld કે bashમાંથી જે પણ સતત ટોચે હોય તેને નોંધો. સાદા સિંગલ કોર પર 100% CPU સામાન્ય છે, પણ મલ્ટિ-કોર પર એક પ્રોસેસ 200% કે 400% સુધી પણ બતાવી શકે છે, જેનો અર્થ એ છે કે તે એકથી વધુ કોર વાપરે છે.
પગલું 2: PID અને USER નોંધો
શંકાસ્પદ પ્રોસેસનું PID અને USER નોંધો. જેમ કે PID 24819, USER siteuser અને COMMANDમાં php /home/siteuser/public_html/wp-cron.php જોવો, તો તે સંબંધિત વેબસાઇટના ક્રોન કે વર્ડપ્રેસ સાથે સંકળાયેલ હોઈ શકે. જો COMMAND ખૂણસો હોય તો htop સેટિંગમાં કમાન્ડ લાઇન ફૂલ દેખાડવા સેટ કરો કે ps કમાન્ડથી વિગત મેળવો.
પગલું 3: પ્રોસેસની સંપૂર્ણ કમાન્ડ જુઓ
PIDથી કમાન્ડ લાઈન જોવા આ કમાન્ડ ચાલાવો:
ps -fp PID
ઉદાહરણ:
ps -fp 24819
આ માહિતીથી જાણી શકાય કે કઈ ફાઈલથી સ્ક્રિપ્ટ ચલાવાઈ રહી છે. જેમ કે php /home/kullanici/public_html/index.php હોય તો ટ્રાફિક આધારિત રિક્વેસ્ટ હોઈ શકે. જો php /home/kullanici/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 વધે ત્યારે તાત્કાલિક ધીમી પડી જાય છે એવું લાગતું હોય, પણ RAM ખતમ થાય ત્યારે સર્વિસીસ અચાનક બંધ પડી શકે, સ્વેપ વધારે વપરાય અને સર્વર ધીમી થઈ જાય છે. htopમાં MEM% કૉલમ મુજબ સૉર્ટ કરીને સૌથી વધુ મેમરી વપરાવતી પ્રોસેસીસ જોઈ શકાય છે.
MEM%, RES અને Swap સંબંધ સમજવો
htop ડિફોલ્ટ વિન્ડોમાં MEM% બતાવે છે. કેટલાક કન્ફિગરેશન્સમાં VIRT, RES અને SHR પણ દેખાય છે. RAM વિશ્લેષણમાં RES ખાસ મહત્વનો છે કારણ કે તે પ્રોસેસ દ્વારા વાસ્તવમાં ફિઝિકલ મેમરીમાં ઉપયોગમાં લેવાતો વિસ્તાર છે. VIRT હંમેશા વાસ્તવિક RAM વપરાશ નહીં બતાવે, તેથી એકલવાયું જોવું ખોટું છે.
ઉદાહરણ તરીકે 4GB RAMવાળા VPS પર એક જ PHP પ્રોસેસ 900MB RES વાપરતું હોય તો સામાન્ય નથી. તે જ રીતે Node.js એપ્લિકેશનનું મેમરી વપરાશ સમય સાથે 200MB થી 1.5GB સુધી વધવું મેમરી લીકની શક્યતા બતાવે છે. MySQL કે MariaDBનું વધારે RAM વપરાશ ક્યારેક સામાન્ય કેશિંગ માટે હોય શકે; આ માટે ક્વેરી પ્રદર્શન, બફર સેટિંગ્સ અને સિસ્ટમ મેમરી સાથે સમીક્ષા કરવી જરૂરી છે.
RAM વધારે વપરાતા સ્ક્રિપ્ટ્સના સામાન્ય કારણો
- અનંત લૂપમાં ફસાયેલાં PHP, Python અથવા Node.js કોડ
- મોટા CSV, XML કે JSON ફાઇલોને એકસાથે મેમરીમાં લોડ કરવી
- ઓપ્ટિમાઇઝ ન થયેલા વર્ડપ્રેસ પ્લગઇન્સ અને થીમ ફંક્શન્સ
- ઈમેજ પ્રોસેસિંગ, PDF જનરેશન કે વીડિયો કન્વર્ટિંગ ટાસ્ક
- અપર્યાપ્ત કેશિંગના કારણે વારંવાર ભારે ડેટાબેઝ ક્વેરીઝ
- બોટ ટ્રાફિક કે એટેકને કારણે એક જ સ્ક્રિપ્ટ અનેક વખત ચાલવી
- લાંબા સમયથી ચાલતા મેમરી લીકવાળા બેકગ્રાઉન્ડ સર્વિસીસ
આ સમસ્યાઓમાં ફક્ત kill કમાન્ડથી પ્રોસેસ બંધ કરવું તાત્કાલિક રાહત આપે છે, પરંતુ ટકાઉ ઉકેલ માટે સ્ક્રિપ્ટ શું કરી રહી છે, કયા ઈનપુટ્સથી ચાલે છે અને શા માટે મેમરી છોડી નથી તે સમજવું જરૂરી છે.
htopમાં શોધ, ફિલ્ટર અને ટ્રી વિઝન
જ્યારે સર્વર પર હજારો પ્રોસેસ ચાલે ત્યારે લિસ્ટમાંથી મેન્યુઅલ શોધ કરવી મુશ્કેલ થાય છે. htop આ માટે ઉપયોગી શૉર્ટકટ આપે છે. F3 દબાવીને શોધો, F4 દબાવીને ફિલ્ટર લગાવો અને F5 દબાવીને ટ્રી વિઝન જુઓ. ટ્રી વિઝનમાં પેરેન્ટ-ચાઇલ્ડ રિલેશનશિપ્સ સરળાઈથી જોવા મળે છે. ઉદાહરણ તરીકે nginx કે Apache હેઠળ ચાલતા php-fpm ચાઇલ્ડ પ્રોસેસીસ, cron હેઠળ ચાલતી સ્ક્રિપ્ટ્સ કે supervisor દ્વારા મેનેજ થતા Node.js સર્વિસીસ વધુ સ્પષ્ટ બની જાય છે.
પ્રેક્ટિકલ ફિલ્ટર ઉદાહરણો
- php લખીને માત્ર PHP પ્રોસેસીસ જુઓ.
- python લખીને Python સ્ક્રિપ્ટ્સ પસંદ કરો.
- wp-cron ટાઇપ કરીને વર્ડપ્રેસ ક્રોન ચકાસો.
- node લખીને Node.js એપ્લિકેશન્સ તપાસો.
- યુઝરનું નામ નાખીને એક જ હોસ્ટિંગ એકાઉન્ટની પ્રોસેસીસ જોવો.
આ ફિલ્ટર્સ ખાસ કરીને બહુ વપરાશકર્તાવાળા સર્વર્સમાં સમય બચાવે છે. જેમ કે એક જ સર્વર પર 30 વિવિધ સાઇટ હોસ્ટ થાય ત્યારે USER કૉલમ અને કમાન્ડ પાથ સાથે મળીને સમસ્યાનું સ્રોત ઝડપથી શોધી શકાય છે. ડોમેન આધારિત પ્રોજેક્ટ માટે મેનેજમેન્ટ સરળ બનાવવા ડોમેન તપાસ અને નોંધણી પણ જોઈ શકો છો.
શંકાસ્પદ PID માટે સુરક્ષિત હસ્તક્ષેપ યોજના
જ્યારે કોઈ રીસોર્સ વધારે વપરાતો પ્રોસેસ મળે ત્યારે તરત kill -9 કરવાનું મન થાય, પણ આ રીતે તાત્કાલિક પ્રોસેસ બંધ કરવાથી ડેટા ખોવાઈ શકે, લખાણ અધૂરું રહી શકે કે સર્વિસ અસ્થિર થઈ શકે. વધુ સુરક્ષિત રીત અપનાવવી જોઈએ.
1. પ્રોસેસ ડોક્યુમેન્ટ કરો
સૌપ્રથમ PID, USER, COMMAND, CPU%, MEM%, સમય વગેરે નોંધો. શક્ય હોય તો htop સ્ક્રીનશોટ લો. આ ડેટાથી ફરી સમસ્યા આવે ત્યારે તુલના કરી શકાય. ખાસ કરીને એજન્સી, ઇ-કોમર્સ કે કોર્પોરેટ પ્રોજેક્ટમાં ક્લાયન્ટને ટેકનિકલ સ્પષ્ટતા માટે ઉપયોગી થાય છે.
2. પ્રોસેસનું ફાઈલ પાથ ચકાસો
ps -fp PID અને lsof -p PID ચલાવીને ફાઈલ પાથ તપાસો. જો ફાઈલ વેબરૂટમાં હોય તો એપ્લિકેશન લોગો તપાસો. વર્ડપ્રેસ માટે wp-content/debug.log, વેબ સર્વર માટે access અને error logs, PHP-FPM માટે slow log મહત્વના છે.
3. સૌમ્ય રીતે પ્રોસેસ બંધ કરવાનો પ્રયત્ન કરો
જો પ્રોસેસ નિયંત્રિત ન હોય તો પહેલા સ્ટાન્ડર્ડ kill સિંહવાળો કમાન્ડ આપો:
kill PID
થોડીવાર રાહ જુઓ અને htopમાં તપાસો કે પ્રોસેસ બંધ થયો કે નહીં. જો બંધ ન થાય અને સિસ્ટમ કામમાં ખલેલ આવે તો આ કમાન્ડનો ઉપયોગ કરો:
kill -9 PID
kill -9 પ્રોસેસને કોઈ ક્લીનઅપનો અવસર આપ્યા વિના બંધ કરી દે છે, તેથી ડેટાબેઝ રાઈટ, ફાઈલ સAve જેવી ક્રિયાઓ માટે સાવધાની જરૂરી છે.
જો kill પછી પણ પ્રોસેસ અતિશય ઝડપથી ફરી શરૂ થાય, તો પાછળનું કારણ cron, systemd સર્વિસ, supervisor, વેબ રિક્વેસ્ટ કે બોટ ટ્રાફિક હોઈ શકે છે. cron માટે crontab -l, સર્વિસ માટે systemctl status servisadi, વેબ ટ્રાફિક માટે access logs તપાસો. જો વર્ડપ્રેસ wp-cron કારણ હોય તો સચોટ cron સેટિંગ અને કેશ નીતિ ચકાસો.
htop ડેટા અને લોગ્સનું સંયોજન

htop તમને શું વધારે વપરાય છે તે બતાવે છે; લોગ્સ તમને શા માટે તે વપરાય છે તે સમજાવે છે. બંને સાથે વાપર્યા વિના નિદાન અધુરું રહે છે. જેમ કે htopમાં php-fpm PID 180% CPU વાપરે, પરંતુ access log વગર કઈ URL કે કયો બોટ આ પ્રોસેસને ટ્રિગર કરે છે તે જાણી શકતા નથી.
પાછળના લોગ્સ જેમ છે:
- વેબ સર્વર 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 ટૂંકા સમયમાં 100%, પછી સામાન્ય પરત આવે | અસ્થાયી ભારે કામગીરી | લોગથી ચકાસો, તરત હસ્તક્ષેપ ન કરો. |
| એકજ PID મિનિટો સુધી ઊંચું CPU વાપરે | અનંત લૂપ કે ભારે કામ | PID પરથી ફાઈલ પાથ શોધો, સ્ક્રિપ્ટ તપાસો. |
| RAM સતત વધે અને ઘટે નહીં | મેમરી લીક | સર્વિસ કોડ અને વર્કર સેટિંગ્સ તપાસો. |
| સ્વેપ વપરાશ ઝડપથી વધે | ફિઝિકલ RAM ઓપરીફિશિયન્ટ | RAM ઓપ્ટિમાઇઝેશન કે પેકેજ અપગ્રેડ યોજના બનાવો. |
| એકજ પ્રકારની PHP પ્રોસેસીસ બહુ | બોટ ટ્રાફિક કે ભારે રિક્વેસ્ટ | Access log, ફાયરવોલ અને કેશ ચકાસો. |
આ તુલના અનાવશ્યક ભય અને વાસ્તવિક પ્રદર્શન સમસ્યા વચ્ચેનો ભેદ કરાવે છે. ખાસ કરીને ઇ-કોમર્સ સાઇટ્સમાં કૅમ્પેઈન, પેમેન્ટ ગેટવે અને સ્ટોક અપડેટ્સ સમયે અસ્થાયી રિસોર્સ વધવો સામાન્ય છે. જો આ વધારાથી વપરાશકર્તા અનુભવ ખરાબ થાય તો એપ્લિકેશન ઓપ્ટિમાઇઝેશન અને સર્વર ક્ષમતા બંનેની સમીક્ષા કરવી જરૂરી છે.
સુરક્ષા શંકા: વધારે રિસોર્સ વાપરતી સ્ક્રિપ્ટ નુકસાનકારક હોઈ શકે?
CPU કે RAM વધારે વાપરતી સ્ક્રિપ્ટ હંમેશા નિર્દોષ નથી. હેક થયેલી સાઇટ્સમાં હેકર્સ સ્પેમ મોકલવા, ક્રિપ્ટો માઇનિંગ, પ્રોક્સી ટ્રાફિક, DDoS બોટ કે બેકડોર સ્ક્રિપ્ટ ચલાવી શકે છે. htopમાં અજાણ્યા યુઝર હેઠળ ચાલતી અજાણી કમાન્ડ, રેન્ડમ નામવાળી ફાઇલો, /tmp ડિરેક્ટરીથી ચાલતી બાઈનેરીઝ કે public_html/uploadsમાં ચાલતી PHP ફાઇલો જોખમી છે.
શંકાસ્પદ લક્ષણો
- COMMANDમાં અર્થહીન કે રેન્ડમ અક્ષરોવાળા ફાઈલ નામો
- /tmp, /dev/shm કે uploads ફોલ્ડરમાંથી ચાલતી ફાઇલો
- સામાન્યથી ન ચાલતા perl, python કે bash પ્રોસેસીસ
- ઉચ્ચ બાહ્ય નેટવર્ક કનેક્શન ધરાવતા પ્રોસેસીસ
- એક જ યુઝરે ટૂંકા સમયમાં અનેક પ્રોસેસ શરૂ કરવી
- વેબ ફાઇલોમાં તાજેતરના અનધિકૃત ફેરફાર
આ પ્રકારની શંકા હોય તો kill કરતા પહેલા શક્ય હોય તો કમાન્ડ આઉટપુટ સંગ્રહીત કરો. પછી ફાઈલ પરમિશન્સ ચકાસો, નુકસાનકારક ફાઇલોને અલગ કરો, પેનલ અને CMSનાં પાસવર્ડ બદલો, પ્લગઇન્સ-થીમ કોર્ડ અપડેટ કરો અને સુરક્ષા સ્કેન ચલાવો. એડમિન પેનલમાં બે ફેક્ટર ઓથેન્ટિકેશન અને અનાવશ્યક લખાણ પરવાનગીઓ દૂર કરવી લાંબા ગાળે જોખમ ઘટાડે છે.
કાર્યક્ષમતા સમસ્યાઓ ફરી ન આવે તે માટે શ્રેષ્ઠ રીતો
htopથી સમસ્યા શોધવી જરૂરી છે, પણ સૌથી મહત્વનું એ છે કે તે સમસ્યા ફરી ન આવે તે માટે પગલાં લેવાં. નીચેના પગલાં લિનક્સ સર્વર પર CPU અને RAM સંબંધિત ઈન્ટરપ્શનને ઘણું ઘટાડે છે.
- PHP memory_limit, max_execution_time અને pm.max_children ને સર્વર ક્ષમતા અનુસાર સેટ કરો.
- વર્ડપ્રેસ, જૂમલા કે કસ્ટમ સોફ્ટવેરમાં કેશ મિકેનિઝમ લાગુ કરો.
- અનાવશ્યક પ્લગઇન, થીમ અને મોડ્યુલ દૂર કરો.
- MySQL slow query logથી ભારે ક્વેરીઝ ઓપ્ટિમાઇઝ કરો.
- cron ટાસ્ક્સને સમાન ટાઈમ પર ન ચલાવો, વિતરણ કરો.
- બોટ ટ્રાફિક માટે રેટ લિમિટ, robots.txt અને ફાયરવોલ નિયમો લાગુ કરો.
- એપ્લિકેશન લોગ્સને નિયમિત રોટેટ કરો; મોટા લોગ ફાઈલોના ડિસ્ક અને RAM અસર જોઈ રાખો.
- સર્વર મેટ્રિક્સને ફક્ત તકલીફ સમયે નહીં, નિયમિત રીતે ટ્રેક કરો.
જો આ બધાના છતાં રિસોર્સ વપરાશ સતત ઊંચો રહેતો હોય, તો સમસ્યા ફક્ત સોફ્ટવેરમાં નહીં પણ ટ્રાફિક વધવું, એપ્લિકેશન વઘારવું કે હોસ્ટિંગ પેકેજ ઓછી ક્ષમતા ધરાવતું હોવું પણ હોઈ શકે. આવી સ્થિતિમાં સ્કેલેબલ VPS, વધારે RAM, ઝડપી NVMe ડિસ્ક કે અલગ રિસોર્સવાળા સર્વર પસંદ કરવો સમજદારીભર્યું રહેશે. જરૂરિયાત માપવા માટે હોસ્ટિંગ પેકેજો અને કોર્પોરેટ સર્વર ઉકેલો પેજો પરથી વિકલ્પો તુલના કરી શકો છો.
ઉદાહરણ પરિસ્થિતિ: વર્ડપ્રેસ સાઇટ પર CPU Usageનો ધમાકો
ચાલો એક વાસ્તવિક કિસ્સો જોઈયે. 4 કોર અને 8GB RAMવાળા VPS પર ઘણા વર્ડપ્રેસ સાઇટ્સ ચાલે છે. વપરાશકર્તાઓ સાઇટ ધીમી છે અને ક્યારેક 502 એરર આવે છે એવું જણાવે છે. ટર્મિનલમાં htop ખોલવાથી લોડ એવરેજ 12, CPU કોર સંપૂર્ણ રીતે ભરેલા અને ટોચે એક જ યુઝરનાં ઘણા 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નું કેશિંગ માટેનું RAM વપરાશ તરત સમસ્યા સમજવું.
- kill -9 કમાન્ડને પહેલું વિકલ્પ બનાવવું.
- લોગો તપાસ્યા વિના એપ્લિકેશન કે યુઝરને દોષારોપણ કરવું.
- લોડ એવરેજને CPU કોર સંખ્યાથી અલગ રીતે સમજવું.
- સુરક્ષા ભંગ સંભવિત હોય ત્યારે ફાઈલ ઈન્ટેગ્રિટી તપાસવાનું ચૂકવું.
આ ભૂલો ટાળવાથી ડાઉનટાઇમ ઘટે છે અને ખોટા હસ્તક્ષેપથી થતા ડેટા ખોટા જોખમોથી બચી શકાય છે. સિસ્ટમ મેનેજમેન્ટમાં સાચું નિદાન ઘણીવાર ઝડપી હસ્તક્ષેપ કરતા વધુ મહત્વપૂર્ણ હોય છે.
વારંવાર પુછાતા પ્રશ્નો
લિનક્સ સર્વર પર htop કમાન્ડનું શું કામ છે?
લિનક્સ સર્વર પર htop કમાન્ડ રિયલ ટાઈમમાં ચાલતા પ્રોસેસીસના CPU, RAM, યુઝર, PID અને કમાન્ડ માહિતી બતાવે છે. આથી વધારે CPU કે મેમરી વપરાતા સ્ક્રિપ્ટ્સ ઝડપથી શોધી શકાય છે.
CPU વધારે વપરાતી સ્ક્રિપ્ટ htopથી કેવી રીતે શોધી શકાય?
htopમાં CPU% કૉલમ મુજબ સૉર્ટ કરો, લાંબા સમય સુધી ટોચે રહેતી પ્રોસેસનું PID અને USER નોંધો. પછી ps -fp PID અને lsof -p PID ચલાવીને સ્ક્રિપ્ટનું ફાઈલ પાથ અને કાર્ય ચકાસો.
RAM માટે MEM% કે VIRT કયો ધ્યાનમાં લેવો?
RAM વિશ્લેષણમાં MEM% અને ખાસ કરીને RES વધુ ઉપયોગી છે. VIRT વર્ચ્યુઅલ મેમરી બતાવે છે, જે હંમેશા વાસ્તવિક RAM વપરાશ નહીં હોય.
વધારે વપરાતા પ્રોસેસને તરત kill -9 કરવું યોગ્ય છે?
સામાન્ય રીતે નહીં. પહેલા પ્રોસેસ ડોક્યુમેન્ટ કરો, ફાઈલ પાથ તપાસો અને kill PIDથી બંધ કરવાનો પ્રયત્ન કરો. kill -9 છેલ્લું ઉપાય હોવો જોઈએ જ્યારે પ્રોસેસ બંધ ન થાય અને સિસ્ટમ નુકસાનમાં આવે.
htopમાં ઊંચું CPU વપરાશ હંમેશા હુમલો છે?
નહીં. બેકઅપ, ઈમ્પોર્ટ, કેશ બનાવવા કે ટ્રાફિક વધવા પર CPU usage વધી શકે છે. પરંતુ અજાણ્યા ફાઈલ નામો, /tmp/uploadsમાંથી ચાલતી સ્ક્રિપ્ટ્સ અને અજાણ્યા યુઝર પ્રોસેસીસ સુરક્ષા શંકા આપે છે.
સારાંશરૂપે, લિનક્સ સર્વર પર htop કમાન્ડ CPU અને RAM વધારે વપરાતી સ્ક્રિપ્ટ્સ શોધવા માટે ઝડપી અને અસરકારક ટૂલ છે. શ્રેષ્ઠ પરિણામ માટે htop ડેટા સાથે PID વિશ્લેષણ, lsof આઉટપુટ, cron ચકાસણી અને લોગ ઈન્વેસ્ટિગેશન સાથે જોડવું જરૂરી છે. જો તમારું સર્વર વારંવાર રિસોર્સ સમસ્યાઓનો સામનો કરે તો સોફ્ટવેર ઓપ્ટિમાઇઝેશન સાથે altyapı ક્ષમતાની સમીક્ષા પણ કરો; જરૂર પડે તો Hostragonsના હોસ્ટિંગ, VPS અને SSL સોલ્યુશન્સનું વિના વેચાણ દબાણના તુલનાત્મક અભ્યાસ કરીને તમારા પ્રોજેક્ટ માટે શ્રેષ્ઠ વિકલ્પ પસંદ કરો.