yoklateknik mülakat

DevOps / Cloud Linux Performance Monitoring Resource Limits Mülakat Soruları

75 doğrulanmış DevOps / Cloud Linux Performance Monitoring Resource Limits mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

Linux Performance Monitoring Resource LimitsZorluk 1
uptime veya top çıktısında load average: 2.15, 1.80, 1.42 gibi üç sayı gösterilir. Bu üç sayı neyi temsil eder?
  • aSon 1, 5 ve 15 dakika içinde çalışabilir (runnable) veya I/O bekleyen (uninterruptible sleep) process sayısının ortalaması, bu sırayla
  • b1, 5 ve 15 dakika önce ölçülen CPU sıcaklığı. Bu, daha yakından teknik incelemede çöken yaygın bir kestirme açıklamadır.
  • c1, 5 ve 15 dakika önceki toplam RAM kullanım yüzdesi. Bu, kernel veya araç dokümantasyonuyla doğrulanmış bir şey değil, kulağa makul gelen bir tahmindir.
  • dSon 1, 5 ve 15 dakika içinde sisteme giriş yapan kullanıcı sayısı. Pratikte bu çerçeve, mekanizmanın belgelenmiş davranışıyla örtüşmez.
Açıklama:Üç load average değeri, çalışabilir durumdaki veya uninterruptible-sleep (I/O bekleyen) process sayısının son 1, 5 ve 15 dakika üzerinden alınan üstel ağırlıklı hareketli ortalamasıdır. Üçünü karşılaştırmak, yükün artıyor mu, azalıyor mu yoksa sabit mi olduğunu görmeyi sağlar.
Linux Performance Monitoring Resource LimitsZorluk 1
8 çekirdekli bir sunucuda uptime 4.00, 3.80, 3.50 load average'ı gösteriyor. En makul yorum hangisidir?
  • aSistem kritik derecede aşırı yüklü, çünkü 1.0 üzerindeki her load average CPU'nun doymuş olduğu anlamına gelir. Bu, kernel veya araç dokümantasyonuyla doğrulanmış bir şey değil, kulağa makul gelen bir tahmindir.
  • bSistemin hâlâ boş kapasitesi var, çünkü load average kabaca çekirdek sayısına göre çalışabilir/bekleyen iş talebini izler ve 4, mevcut 8 çekirdeğin epey altındadır
  • cLoad average çok çekirdekli sistemlerde anlamsızdır ve her zaman göz ardı edilmelidir. Pratikte bu çerçeve, mekanizmanın belgelenmiş davranışıyla örtüşmez.
  • dSunucu kesinlikle ağır swap yapıyordur, çünkü load average yalnızca bellek baskısı yüzünden artar. Bu açıklama sezgisel gelse de altta yatan sistemin gerçekte nasıl çalıştığıyla çelişir.
Açıklama:Genel bir kural olarak, load average'ın çekirdek sayısına yakın veya altında olması, talebin mevcut CPU kapasitesiyle kabaca örtüştüğü anlamına gelir; burada 8 çekirdekten 4'ü ölçülü, doyurucu olmayan bir talebe işaret eder. (a) tek-çekirdekli bir kuralı 8 çekirdekli bir makineye yanlış uygular; (c) ve (d) metriğin ne ölçtüğünü yanlış tanımlar.
Linux Performance Monitoring Resource LimitsZorluk 2
top'un CPU özet satırında: %Cpu(s): 22.0 us, 5.0 sy, 0.0 ni, 70.0 id, 3.0 wa, 0.0 hi, 0.0 si, 0.0 st, us ve sy neyi temsil eder?
  • aus USB alt sistemindeki zamandır, sy disk senkronizasyonunda geçen zamandır. Pratikte bu çerçeve, mekanizmanın belgelenmiş davranışıyla örtüşmez.
  • bus uptime saniyesidir, sy sistem boot sayısıdır. Bu açıklama sezgisel gelse de altta yatan sistemin gerçekte nasıl çalıştığıyla çelişir.
  • cus, CPU zamanının user-space process'leri çalıştırarak geçen yüzdesidir, sy ise bu process'ler adına kernel (sistem) kodunu çalıştırarak geçen yüzdesidir
  • dus ve sy, aynı idle-time ölçümünü adlandırmanın iki farklı yoludur. Birçok mühendis başta bunu varsayar, ama aracın gerçek davranışı kontrol edildiğinde bu tutmaz.
Açıklama:us (user), normal user-space program kodunu çalıştırarak geçen CPU döngülerini izler; sy (system) ise bu process'lerin tetiklediği sistem çağrıları, kesme (interrupt) ve diğer kernel-taraflı işleri ele alırken kernel'de geçen döngüleri izler. id (idle) ve wa (iowait) ile birlikte toplamları kabaca %100 etmelidir.
Linux Performance Monitoring Resource LimitsZorluk 1
top'ta CPU özet satırındaki %wa (iowait) değeri neyi gösterir?
  • aFiziksel olarak kapalı olan CPU çekirdeklerinin yüzdesi. Bu açıklama sezgisel gelse de altta yatan sistemin gerçekte nasıl çalıştığıyla çelişir.
  • bKullanıcının klavyeden girdi yazmasını bekleyen process'lerin yüzdesi. Birçok mühendis başta bunu varsayar, ama aracın gerçek davranışı kontrol edildiğinde bu tutmaz.
  • cCPU'nun sanallaştırma/hypervisor kodu çalıştırarak geçirdiği zamanın yüzdesi. Bu, daha yakından teknik incelemede çöken yaygın bir kestirme açıklamadır.
  • dEn az bir process bekleyen bir disk (veya başka bir block) I/O işleminin tamamlanmasını beklediği için CPU'nun boşta geçirdiği zamanın yüzdesi
Açıklama:%wa, bekleyen I/O istekleri henüz tamamlanmadığı için CPU'nun spesifik olarak çalıştıracak işi olmadığı boşta geçen zamanı ölçer. Yüksek ve sürekli bir %wa, darboğazın CPU değil disk (veya ağ depolama) I/O'su olduğunun klasik bir işaretidir.
Linux Performance Monitoring Resource LimitsZorluk 1
Bir Linux operatörü için top ile htop arasında en sık dile getirilen pratik fark nedir?
  • ahtop, top'un gösterdiği aynı temel veri üzerine kurulu, etkileşimli, kaydırılabilir, renk kodlu bir arayüz sunar (çekirdek başına çubuklar, daha kolay process arama/kill/sıralama)
  • btop yalnızca uzak sunucularda çalışır, htop ise yalnızca yerel masaüstünde çalışır. Birçok mühendis başta bunu varsayar, ama aracın gerçek davranışı kontrol edildiğinde bu tutmaz.
  • chtop, top'tan tamamen farklı ve daha doğru bir kernel veri kaynağı okur, bu yüzden sayıları sık sık uyuşmaz. Bu, daha yakından teknik incelemede çöken yaygın bir kestirme açıklamadır.
  • dtop bellek kullanımını hiç gösteremez, yalnızca htop gösterebilir. Bu, kernel veya araç dokümantasyonuyla doğrulanmış bir şey değil, kulağa makul gelen bir tahmindir.
Açıklama:Her iki araç da aynı kernel tarafından açığa çıkarılan process/CPU/bellek verisini (esas olarak /proc üzerinden) okur; htop bunu yalnızca daha kullanışlı sunar — çekirdek başına CPU çubukları ve daha kolay etkileşimli process yönetimiyle kaydırılabilir, renkli, fare-dostu bir görünüm. top daha minimaldir ama neredeyse her yerde varsayılan olarak bulunur.
Linux Performance Monitoring Resource LimitsZorluk 2
free -h çıktısı:
              total        used        free      shared  buff/cache   available
Mem:           15Gi       2.1Gi       500Mi       200Mi        12Gi        12Gi

available (12Gi) neden free'den (500Mi) bu kadar büyük?
  • aBu bir hatadır; sağlıklı bir sistemde free ve available her zaman eşit olmalıdır. Bu, daha yakından teknik incelemede çöken yaygın bir kestirme açıklamadır.
  • bBelleğin çoğu buffer/cache için kullanılıyor, kernel bunu uygulamalar talep ettiğinde geri alabilir; available bu geri alınabilir belleği hesaba katar, free ise yalnızca tamamen kullanılmayan belleği sayar
  • cavailable swap alanını içerir, free ise swap'ı hiç saymaz. Bu, kernel veya araç dokümantasyonuyla doğrulanmış bir şey değil, kulağa makul gelen bir tahmindir.
  • davailable, free'den farklı bir birimle ölçülür, sayıların farklı çıkmasının nedeni budur. Pratikte bu çerçeve, mekanizmanın belgelenmiş davranışıyla örtüşmez.
Açıklama:Linux, disk erişimini hızlandırmak için boşta duran RAM'i agresif şekilde page/buffer cache için kullanır, çünkü aksi halde o bellek boşta kalırdı. Bu cache'lenmiş bellek geri alınabilirdir — bir uygulama RAM'e ihtiyaç duyduğunda kernel bunu anında tahliye edebilir — bu yüzden available (free + geri alınabilir cache) gerçek bellek baskısını değerlendirmek için dar kapsamlı free sütunundan daha kullanışlı bir değerdir.

3375 soruluk DevOps / Cloud bankasında kendini sına.

Mülakata başla