Bloga dön
·8 dk okuma·productdevbook

Yardımcı Süreçler macOS Bant Genişliği İzleyicilerini Neden Karıştırır

Yardımcı süreçler, kullanıcıya tek bir uygulama olarak görünen şeyi ağ panelinde onlarca satıra böler. Bu macOS'ta neden olur ve bunu nasıl doğru okursunuz.

  • macOS
  • Bandwidth
  • Network monitoring
  • Deep dive

Sessiz bir öğleden sonrası Activity Monitor'u açıyorsunuz, ağ baytlarına göre sıralıyorsunuz ve listenizin üst kısmı şöyle görünüyor: Google Chrome Helper (Renderer), Google Chrome Helper (GPU), Google Chrome Helper, Slack Helper, Slack Helper (Renderer), Slack Helper (GPU). "Chrome" veya "Slack" için bir satır yok — sadece her biri saniyede birkaç yüz kilobayt çeken bir konfeti yardımcı yığını. Aslında hangi uygulama konuşuyor? Bu kafa karışıklığı, mac helper processes bandwidth atfının macOS'ta bir ağ izleyicisi inşa etmenin en zor kısmı olmasının tüm nedenidir.

Bu yazı, uygulamaların ilk başta neden yardımcı doğurduğunu, çekirdeğin neden ağ kullanımını ayrı raporladığını ve bir araç size temiz bir uygulama başına sayı vermeye çalıştığında "katlama"nın ne anlama geldiğini açıklar.

Uygulamalar neden yardımcı süreçler doğurur

Modern macOS uygulamaları neredeyse hiç tek bir süreç olarak çalışmaz. Üç büyük neden var.

Sandbox ve ayrıcalık ayrımı

Apple'ın App Sandbox'ı süreç başına bir sınırdır. Güvenilmez HTML'i ayrıştıran veya JavaScript yürüten bir oluşturucu, mikrofon izninize sahip olan üst süreçten farklı bir hak setiyle çalışır. Oluşturucu kötü amaçlı bir sayfa tarafından tehlikeye atılırsa, patlama yarıçapı o süreçte durur — aniden ses kaydetmeye veya Belgeler klasörünüzü okumaya başlayamaz. Bu, hem Chrome hem de Safari'nin her sekme veya site için ayrı süreçlerle gönderilmesinin ve Slack, Discord ve Notion'un (hepsi Electron uygulaması) aynı deseni izlemesinin nedenidir.

Çökme yalıtımı

Chrome'da bir sekme bellekten çıkarsa veya bir JavaScript motoru hatasına çarparsa, tarayıcıdaki her sekmenin onunla birlikte ölmesini istemezsiniz. Yardımcı süreçler, tek bir kötü sayfanın o sekme için "Aw, Snap" ekranını gösterdiği ve başka hiçbir şey göstermediği anlamına gelir. Aynı mantık Slack'in bir kanalı oluşturması veya Discord'un bir sesli arama oluşturması için de geçerlidir.

Electron ve Chromium mimarisi

Uygulama Electron üzerine kurulmuşsa — Slack, Discord, VS Code, Notion, Linear, Figma desktop, 1Password 8, Microsoft Teams, Postman — Chromium'un çoklu süreç modelini bütünüyle miras alır. Bir "main" süreci, bir "GPU" süreci, bir "Network Service" süreci (genellikle Utility olarak adlandırılır) ve her tarayıcı penceresi veya önemli görünüm için bir oluşturucu süreç vardır. Oluşturucu kendisi bir soket açmaz. IPC üzerinden ağ hizmetiyle konuşur ve ağ hizmeti gerçek TCP el sıkışmasını yapar.

Bu son ayrıntı kulağa geldiğinden daha önemlidir.

mac helper processes bandwidth atfı neden zordur

macOS çekirdeği baytları, socket(2) ve sonra connect(2)/sendto(2)/recvfrom(2) çağıran PID'e atfeder. Çekirdek için doğru cevap bu — bir ürün olarak "Slack"ın ne anlama geldiği hakkında hiçbir fikri yoktur. Yalnızca PID 4711'in 34.117.x.x:443'e bir soket açtığını bilir.

Yani nettop'a veya lsof -i'ye veya ham proc_pidinfo API'sine "ağ baytlarını kim kullandı" diye sorduğunuzda, düz bir PID listesi alırsınız. Her PID'in bir süreç adı (diskteki yürütülebilir adı) vardır ve bu ad neredeyse her zaman şöyle bir şeydir:

  • Google Chrome Helper
  • Google Chrome Helper (GPU)
  • Google Chrome Helper (Renderer)
  • Google Chrome Helper (Plugin)
  • Slack Helper
  • Slack Helper (Renderer)
  • Slack Helper (GPU)
  • com.docker.backend

Saf bir izleyici — sadece çekirdeğin görünümünü ekrana boşaltan biri — size tam olarak bunu gösterir. "Chrome bu saatte ne kadar kullandı?" sorusunu yanıtlamak için zihinsel olarak toplamanız gereken yedi Chrome satırı görürsünüz. Daha kötüsü, oluşturucular kısa ömürlüdür. Bir sekmeyi kapatın, oluşturucu ölür. Yenisini açın, yeni PID ile yeni bir oluşturucu görünür. Bir saat boyunca toplayın ve cevap onlarca ölü PID arasında parçalanır. mac helper processes bandwidth atfının çekirdek zorluğu budur: çekirdeğin sunduğu birimler, bir insanın düşünmek istediği birimlere uymaz.

"Katlama"nın anlamı

Katlama, bir yardımcı sürece bakma — paket yolu, üst PID veya her ikisiyle — ve baytlarını ait olduğu kullanıcı tarafından görünür uygulamaya atfetme eylemidir. Doğru yapıldığında, on bir Chrome satırı görmeyi bırakır ve toplamla birlikte "Google Chrome" adlı bir satır görmeye başlarsınız.

Bunu yapmanın birkaç yolu var ve her birinin dengeleri var.

Paket yoluna göre

Her yardımcı, üst uygulamanın paketinin içinde yaşar. Chrome için, bu yol şuna benzer:

/Applications/Google Chrome.app/Contents/Frameworks/
  Google Chrome Framework.framework/Versions/.../Helpers/
  Google Chrome Helper.app/Contents/MacOS/Google Chrome Helper

Bir sürecin yürütülebilir yolu ağaçta daha yukarıda başka bir .app paketi içeriyorsa, dış paket neredeyse kesinlikle üst pakettir. Bu, PID değişiklikleri arasında hayatta kaldığı için en güvenilir katlama sinyalidir — yeni bir Chrome sekmesi açın, yeni oluşturucunun yolu hâlâ Google Chrome.app altındadır.

Üst PID'e göre

/Applications'ta yaşayan veya paket tanımlayıcısı "gerçek" bir uygulamayla eşleşen bir üst PID'e ulaşana kadar süreç ağacında yukarı yürüyebilirsiniz. Bu çalışır ancak daha kırılgandır — launchd yetim süreçleri yeniden ebeveynler ve bazı yardımcılar üst tarafından doğrudan değil, XPC hizmetleri tarafından başlatılır.

Paket tanımlayıcı önekine göre

Slack'in paket kimliği com.tinyspeck.slackmacgap'tir. Yardımcının paket kimliği com.tinyspeck.slackmacgap.helper veya com.tinyspeck.slackmacgap.helper.renderer'dır. Yüklü uygulamalar tablosuna karşı bir önek eşleşmesi çoğu durumu yakalar. Bu, Apple'ın bazı kullanıcıya yönelik raporlar için dahili olarak kullandığı tekniktir.

Pratikte iyi bir izleyici üç sinyali de kullanır ve biri eksik olduğunda zarif bir şekilde geri çekilir.

ova'yı eylemde görün

Bir bakışta görülebilir bir menü çubuğu bant genişliği izleyicisi — yerel, imzalanmış, ~3 MB.

Download for macOS

Electron özel durumu

Electron uygulamaları kendi paragrafını hak eder çünkü bu kadar yaygındırlar. Slack Helper (Renderer) adlı bir Electron yardımcısı aslında soket açmaz — Electron sürümüne bağlı olarak genellikle Slack Helper (sonek yok) veya Slack Helper (Plugin) olarak adlandırılan ağ hizmetidir. Oluşturucu, Chromium'un Mojo IPC veriyolu üzerinden ağ hizmetiyle konuşur.

Yani çıplak Slack Helper'da hiç trafik görüyorsanız, bu bir hata değil — mimaridir. Oluşturucu isteği yapıyor, ancak çekirdek I/O'yu yapan ağ hizmetini görüyor. Kullanıcı perspektifinden her ikisi de "Slack" altında katlanmalıdır. Hata ayıklama perspektifinden, bunu bilmek oluşturucunun neden parlamadığını merak ettiğinizde size bir öğleden sonra kazandırır.

Aynısı Chrome'un kendisi için de geçerlidir: son Chrome derlemelerinde, neredeyse tüm ağ trafiği sekme başına oluşturuculardan değil, Google Chrome Helper (Plugin) veya ağ hizmeti yardımcısından gelir.

Basit toplamlara neden güvenemezsiniz

Yardımcıları anladıktan sonra, birkaç yaygın soru daha kolay yanıtlanır hale gelir.

"Chrome kullanımım neden düşük görünüyor?" Çünkü baytlar bir düzine yardımcı arasında dağıtılır ve izleyiciniz onları toplamaz. Her bir yardımcı mütevazı görünür.

"Tanımadığım bir süreç altında neden aniden 200 MB göründü?" Muhtemelen bir video akışı için bir oluşturucu, senkronizasyon işleyen bir XPC hizmeti (CloudKit, iCloud, Dropbox) veya arka plan işi yapan bir sistem arka plan programı. Sadece adına değil, yürütülebilir yoluna bakın.

"Aynı uygulama yeniden başlatmalar arasında neden iki farklı adla görünüyor?" Bazı yardımcılar süreç adlarına bir sürüm numarası veya UUID ekler. Çoğu izleyici bunları çıkarır, ama hepsi değil.

Pratikte katlama — ve ne zaman geri alınmalı

Yardımcıları katlayan bir izleyici size şuna benzer bir şey gösterir:

Google Chrome    412 MB ↓   18 MB ↑
Slack             89 MB ↓    4 MB ↑
Spotify           62 MB ↓  120 KB ↑
Dropbox           34 MB ↓   12 MB ↑

…şunun yerine:

Google Chrome Helper (Renderer)   38 MB ↓
Google Chrome Helper (GPU)         2 KB ↓
Google Chrome Helper (Plugin)    220 MB ↓
Google Chrome Helper             140 MB ↓
Google Chrome Helper (Renderer)   12 MB ↓
Slack Helper (Renderer)           41 MB ↓
Slack Helper                      48 MB ↓
... (30 satır daha devam eder)

İlki, gerçekte istediğinizdir. ova bu katlamayı otomatik olarak yapar — her yardımcı PID'i üst paket altında gruplandırır, böylece yedi yardımcı satır yerine "Slack" okuyorsunuz.

Yardımcı süreç katlama
ova her yardımcı PID'i üst uygulamasının altında gruplar, böylece yedi yardımcı satır yerine "Slack" okuyorsunuz. Chrome, Slack, Discord, Telegram, VS Code, Figma — hepsi otomatik olarak konsolide edilir.

Yardımcıları gerçekten görmek istediğinizde

Katlamanın yoldan çıktığı bir durum vardır: yanlış davranan bir uygulamanın hata ayıklanması. Hangi Chromium sürecinin soketleri sızdırdığını veya oluşturucunuzun ağ hizmetini atlayıp atlamadığını anlamaya çalışan bir geliştiriciyseniz, ham görünümü istersiniz.

Yararlı bir izleyici, katlanmış satıra tıklamanıza ve altta yatan yardımcıları görmenize izin verir — yardımcı başına bayt, mevcut PID, tam yürütülebilir yol. Bu şekilde varsayılan görünüm temizdir, ancak ayrıntı bir dokunuş uzaktadır.

Bu, çökmeleri teşhis etmek için de faydalıdır: her 30 saniyede bir yeniden başlayan ve TLS oturumlarını yeniden kuran bir yardımcı, şaşırtıcı arka plan trafiği biriktirebilir ve yalnızca yardımcı seviyesi geçmişi görebildiğinizde görünürdür.

Adım adım: bir Slack gizemini araştırma

Slack'in bugün 600 MB indirdiğini ve hiç video izlemediğinizi varsayalım. İşte kontrol edeceğim sıra.

  1. Günün saati desenini kontrol edin. Sabah 09'daki bir artış muhtemelen sabahki yetişme senkronizasyonudur. 24 saatlik düz bir eğri daha ilginçtir.
  2. Yardımcı dökümünü kontrol edin. %90'ı Slack Helper (Plugin) (ağ hizmeti) içindeyse, "gerçek" uygulama trafiğidir. Tuhaf bir şekilde oluşturucular arasında bölünmüşse, sızdırılmış bir sekme açık olabilir.
  3. Çalışma alanı sayısını kontrol edin. Her Slack çalışma alanı kalıcı bir WebSocket ve kendi avatar/dosya önbelleğini ekler. Üç çalışma alanı, birinin boştaki trafiğinin kabaca 3 katıdır.
  4. Ekran paylaşımı veya toplantı geçmişini kontrol edin. Toplantılar WebRTC kullanır ve aktifken 1-3 MB/sn yer.

Bunların hiçbiri için bir paket yakalama gerekmez. Yardımcıları katlayan ve bir saat geçmişi tutan uygulama başına bir izleyiciye ihtiyacınız var.

Toparlarken

Yardımcı süreçler, üzerinde çalışılması gereken bir tuhaflık değil — modern macOS uygulamalarının nasıl güvenli ve kararlı kaldığıdır. Bedeli, çekirdeğin "ağı kim kullandı" görünümünün şifreli düz bir liste gibi okunmasıdır ve bu, mac helper processes bandwidth muhasebesinin neden her genel amaçlı aracı tökezlettiğidir. macOS'taki düzgün herhangi bir bant genişliği izleyicisinin yardımcı katlama yapması gerekir ve yapmayan herhangi bir tane sizi ömrünüzün geri kalanında satırları zihinsel olarak toplayarak bırakacaktır.

Mevcut aracınız size ham yardımcı satırları gösteriyorsa ve binlerinci kez "Google Chrome Helper (Renderer)" okumaktan bıktıysanız, ova'yı yükleyin — yaklaşık 3 MB'da menü çubuğunda oturur, kabaca 1 Hz'de örnekler ve yardımcıları otomatik olarak katlar. Tüm veriler Mac'inizde kalır. macOS 14 ve sonrası, Apple Silicon ve Intel.