- Konu sahibi
- #1
İşlemciyi hangi sürecin tükettiğini bulmak için önce
SSH ile sunucuya bağlandıktan sonra şu komutu çalıştırın:
Daha kullanışlı bir arayüz kuruluysa
Bu araç kurulu değilse yalnızca bu nedenle paket yüklemek zorunda değilsiniz;
Örneğin
Çıktıda şu bilgileri birlikte değerlendirin:
Buradaki
Yalnızca süreç adına bakarak işlem yapmayın. Aynı ad birden fazla uygulama tarafından kullanılabilir; ayrıca bir süreci sonlandırmak, ona bağlı isteği veya işi yarıda bırakabilir. Önce komut satırını, sahibini ve üst süreci doğrulayın.
Bir uygulama birden fazla iş parçacığı kullanıyorsa toplam CPU yükünün hangi iş parçacığından geldiğini görmek için PID’yi
Bu görünümde her satır bir iş parçacığını gösterir. Bir iş parçacığı sürekli olarak üst sırada kalıyorsa uygulama içinde belirli bir görev, sorgu, döngü veya istek yoğunluğu araştırılmalıdır. İş parçacığı adını ve kimliğini daha ayrıntılı görmek için şu komut da kullanılabilir:
Birden fazla süreç benzer CPU tüketiyorsa sorun tek bir PID’den çok ortak bir kaynaktan doğabilir. Örneğin aynı web uygulamasına gelen yoğun istekler, eşzamanlı PHP çalışanları veya bir zamanlanmış görevin çok sayıda kopyası toplam kullanımı yükseltebilir. Bu durumda süreçleri tek tek sonlandırmadan önce ortak üst süreci, servis günlüklerini ve o anda çalışan görevleri kontrol edin.
Aşağıdaki kısa ayrım, hangi yöne ilerleyeceğinizi belirler:
Tablodaki değerler teşhis yönünü gösterir; tek başına kesin neden kanıtlamaz. Örneğin yüksek CPU kullanan bir PHP süreci, kök nedenin PHP kodu olduğunu kanıtlamaz; aynı süreç yoğun bir veritabanı sonucunu işliyor, bozuk bir istemci isteğini tekrar ediyor veya normal bir yedekleme görevini yürütüyor olabilir.
Anlık
Bu komut CPU’ya göre sıralanmış ilk süreçleri gösterir. Komutu birkaç kez, örneğin 10-15 saniye arayla çalıştırın. Aynı PID sürekli üst sıralarda kalıyorsa kalıcı bir yükten şüphelenebilirsiniz. Her seferinde farklı kısa ömürlü süreçler görünüyorsa yoğunluk bir görev kuyruğu, web istekleri veya zamanlanmış işlemler nedeniyle oluşuyor olabilir.
Daha düzenli örnekleme için
Burada
Süreç beklenen bir görevse, örneğin yedekleme, rapor üretimi veya toplu veri işleme, CPU kullanımını hemen kesmek yerine görevin ilerleyip ilerlemediğini ve ne kadar süreceğinin öngörülebilir olup olmadığını kontrol edin. Süreç bir servis tarafından yönetiliyorsa doğrudan PID öldürmek yerine ilgili servis yapılandırmasını ve günlüklerini incelemek daha doğru olur.
Süreç beklenmeyen bir komutsa önce şu bilgileri kaydedin:
Ardından sürecin kapanıp kapanmadığını kontrol edin:
Süreç kapanmıyorsa zorlayıcı sonlandırma sinyali kullanılabilir; ancak bu yöntem açık dosyaların, geçici verilerin veya devam eden işlemlerin düzgün kapanmadan bırakılmasına neden olabilir:
top veya htop ile anlık sıralamayı görün; ardından yüksek görünen PID’yi ps, çalışan komut satırını ve gerekirse iş parçacığı kullanımını gösteren araçlarla doğrulayın. Aynı süreç birkaç dakika boyunca yüksek kalıyorsa bunun gerçekten CPU tüketimi olduğunu, tek seferlik kısa bir sıçrama olmadığını kontrol edin. Sonraki işlem; sürecin ne yaptığına, hangi kullanıcıya ait olduğuna ve bunun beklenen bir iş mi yoksa anormal bir durum mu olduğuna göre belirlenir.Önce CPU tüketen süreci canlı olarak görün
SSH ile sunucuya bağlandıktan sonra şu komutu çalıştırın:
Bash:
toptop açıldığında süreçler genellikle CPU kullanımına göre sıralanır. Sıralama farklıysa büyük P tuşuna basarak CPU kullanımına göre sıralayın. Üst bölümdeki us, sy, wa ve st değerleri de sorunun türünü anlamaya yardımcı olur:- us: Kullanıcı süreçlerinin CPU kullanımını gösterir.
- sy: Çekirdek ve sistem işlemlerinin CPU payıdır.
- wa: İşlemlerin disk veya benzeri G/Ç işlemlerini beklediği süreyi gösterir.
- st: Sanal sunucuda fiziksel işlemcinin başka sanal makineler tarafından kullanılması nedeniyle beklenen zamanı gösterir.
PID, USER, %CPU, %MEM ve COMMAND sütunlarını not edin. PID sürecin kimliğidir; sonraki kontrollerde bu numarayı kullanacaksınız. %CPU değerinin kısa süreli olarak yükselmesi tek başına arıza kanıtı değildir. Değer birkaç yenileme boyunca yüksek kalıyor ve aynı PID üst sıralarda görünüyorsa incelemeye bu süreçten devam edin.Daha kullanışlı bir arayüz kuruluysa
htop da çalıştırılabilir:
Bash:
htopBu araç kurulu değilse yalnızca bu nedenle paket yüklemek zorunda değilsiniz;
top ve ps temel tanılama için yeterlidir. Üretim sunucusunda tanılama amacıyla rastgele paket yüklemek yerine mevcut araçlarla ilerlemek daha güvenlidir.PID’nin hangi programa ait olduğunu doğrulayın
Örneğin
top çıktısında yüksek CPU kullanan PID’nin 2481 olduğunu varsayalım. Sürecin tam komutunu, sahibini ve çalışma durumunu görmek için şu komutu çalıştırın:
Bash:
ps -p 2481 -o pid,ppid,user,%cpu,%mem,etime,stat,argsÇıktıda şu bilgileri birlikte değerlendirin:
- USER: Süreci hangi kullanıcı hesabının başlattığını gösterir.
- PPID: Üst sürecin kimliğidir. Süreci hangi servis veya uygulamanın başlattığını anlamak için kullanılır.
- ETIME: Sürecin ne kadar süredir çalıştığını gösterir.
- STAT: Sürecin çalışma durumunu gösterir.
- ARGS: Çalıştırılan komutun ve parametrelerin daha ayrıntılı görünümüdür.
PPID değerini ayrıca inceleyin:
Bash:
ps -p 1,2481 -o pid,ppid,user,stat,argsBuradaki
1 yerine, gerektiğinde PPID sütununda gördüğünüz üst süreç kimliğini yazın. Böylece yüksek CPU kullanan sürecin bir web sunucusu işçisi, PHP işlemi, veritabanı sorgusu, zamanlanmış görev veya doğrudan çalıştırılmış bir komut olup olmadığını ayırt edebilirsiniz.Yalnızca süreç adına bakarak işlem yapmayın. Aynı ad birden fazla uygulama tarafından kullanılabilir; ayrıca bir süreci sonlandırmak, ona bağlı isteği veya işi yarıda bırakabilir. Önce komut satırını, sahibini ve üst süreci doğrulayın.
Yüksek kullanımın tek bir süreçten mi geldiğini ayırın
Bir uygulama birden fazla iş parçacığı kullanıyorsa toplam CPU yükünün hangi iş parçacığından geldiğini görmek için PID’yi
-H seçeneğiyle izleyin:
Bash:
top -H -p 2481Bu görünümde her satır bir iş parçacığını gösterir. Bir iş parçacığı sürekli olarak üst sırada kalıyorsa uygulama içinde belirli bir görev, sorgu, döngü veya istek yoğunluğu araştırılmalıdır. İş parçacığı adını ve kimliğini daha ayrıntılı görmek için şu komut da kullanılabilir:
Bash:
ps -L -p 2481 -o pid,tid,psr,stat,%cpu,etime,commBirden fazla süreç benzer CPU tüketiyorsa sorun tek bir PID’den çok ortak bir kaynaktan doğabilir. Örneğin aynı web uygulamasına gelen yoğun istekler, eşzamanlı PHP çalışanları veya bir zamanlanmış görevin çok sayıda kopyası toplam kullanımı yükseltebilir. Bu durumda süreçleri tek tek sonlandırmadan önce ortak üst süreci, servis günlüklerini ve o anda çalışan görevleri kontrol edin.
Aşağıdaki kısa ayrım, hangi yöne ilerleyeceğinizi belirler:
| Gözlenen durum | Olası anlamı | Sonraki kontrol |
|---|---|---|
| Tek PID sürekli yüksek | Belirli bir uygulama veya görev CPU tüketiyor olabilir. | Tam komut, üst süreç, günlükler ve iş parçacıkları incelenir. |
| Aynı servise ait çok sayıda PID yüksek | Yoğun trafik, paralel çalışan görev veya yanlış yapılandırma olabilir. | Servis yapılandırması, istek yoğunluğu ve süreçlerin başlangıç zamanı karşılaştırılır. |
| CPU değil, wa yüksek | Sorun doğrudan CPU kapasitesinden çok disk veya G/Ç beklemesi olabilir. | Disk gecikmesi, disk kullanımı ve ilgili süreçlerin bekleme durumu incelenir. |
| st yüksek | Sanal makine fiziksel CPU’ya erişmek için bekliyor olabilir. | Sanal sunucu sağlayıcısının CPU paylaşımı ve komşu yükü hakkında bilgi istenir. |
Kullanımın anlık mı sürekli mi olduğunu ölçün
Anlık
top ekranı yerine belirli aralıklarla süreçleri listelemek için şu komutu kullanabilirsiniz:
Bash:
ps -eo pid,ppid,user,%cpu,%mem,etime,stat,args --sort=-%cpu | head -n 15Bu komut CPU’ya göre sıralanmış ilk süreçleri gösterir. Komutu birkaç kez, örneğin 10-15 saniye arayla çalıştırın. Aynı PID sürekli üst sıralarda kalıyorsa kalıcı bir yükten şüphelenebilirsiniz. Her seferinde farklı kısa ömürlü süreçler görünüyorsa yoğunluk bir görev kuyruğu, web istekleri veya zamanlanmış işlemler nedeniyle oluşuyor olabilir.
Daha düzenli örnekleme için
pidstat kuruluysa şu komut kullanılabilir:
Bash:
pidstat -u -p ALL 1 5Burada
1 bir saniyelik aralığı, 5 ise beş örneği ifade eder. Çıktıda aynı PID’nin kullanıcı ve sistem CPU değerlerini karşılaştırın. Kullanıcı CPU’su yüksekse süreç kendi kodunu çalıştırıyor olabilir; sistem CPU’su yüksekse yoğun sistem çağrıları veya çekirdek işlemleri söz konusu olabilir. Bu ayrım kök nedeni tek başına belirlemez, ancak incelemenin uygulama koduna mı yoksa sistem davranışına mı yöneltileceğini gösterir.Süreci bulduktan sonra güvenli sonraki adım
Süreç beklenen bir görevse, örneğin yedekleme, rapor üretimi veya toplu veri işleme, CPU kullanımını hemen kesmek yerine görevin ilerleyip ilerlemediğini ve ne kadar süreceğinin öngörülebilir olup olmadığını kontrol edin. Süreç bir servis tarafından yönetiliyorsa doğrudan PID öldürmek yerine ilgili servis yapılandırmasını ve günlüklerini incelemek daha doğru olur.
Süreç beklenmeyen bir komutsa önce şu bilgileri kaydedin:
- PID, PPID ve kullanıcı adı
- Tam komut satırı
- İlk ve son gözlem zamanı
- Yaklaşık CPU yüzdesi ve süreç sayısı
- İlgili servis veya uygulama günlüklerindeki aynı zaman aralığı
Bash:
kill 2481Ardından sürecin kapanıp kapanmadığını kontrol edin:
Bash:
ps -p 2481 -o pid,stat,etime,argsSüreç kapanmıyorsa zorlayıcı sonlandırma sinyali kullanılabilir; ancak bu yöntem açık dosyaların, geçici verilerin veya devam eden işlemlerin düzgün kapanmadan bırakılmasına neden olabilir:
Bash:
kill -9 2481kill -9 kalıcı çözüm değildir. Süreç bir servis tarafından yeniden başlatılıyorsa aynı PID veya farklı bir PID ile tekrar oluşabilir. Bu durumda servis yöneticisinin durumu, zamanlanmış görevler, uygulama günlükleri ve süreci başlatan üst süreç incelenmelidir. Sanal sunucuda st değeri yüksekse işletim sistemi içinden süreci sonlandırmak fiziksel CPU erişimi sorununu çözmez; sağlayıcıya PID bilgisiyle birlikte gözlem zamanını, st değerini ve sunucunun bulunduğu sanal kaynak planını iletmek gerekir.