Kaynak idaresi

Aynı düğüm veya kümede birden çok hizmet çalıştırırken, bir hizmetin daha fazla kaynak tüketmesi ve bu da işlemdeki diğer hizmetlerden kaynaklanabilir. Bu sorun, "gürültülü komşu" sorunu olarak adlandırılır. Azure Service Fabric, kaynak kullanımını sınırlamak üzere hizmet başına istekleri ve sınırları belirterek geliştiricinin bu davranışı denetlemesini sağlar.

Bu makaleye devam etmeden önce Service Fabric uygulama modeli ve Service Fabric barındırma modelihakkında bilgi sahibi olmanız önerilir.

Kaynak idare ölçümleri

Kaynak İdaresi, hizmet paketineuygun olarak Service Fabric desteklenir. Hizmet paketine atanan kaynaklar kod paketleri arasında daha da ayrılabilir. Service Fabric, iki yerleşik ölçümile hizmet PAKETI başına CPU ve bellek yönetimini destekler:

• CPU (ölçüm adı servicefabric:/_CpuCores ): konak makinede bulunan mantıksal çekirdek. Tüm düğümlerdeki tüm çekirdekler aynı şekilde ağırlıklı olarak dağıtılır.

• Bellek (ölçüm adı servicefabric:/_MemoryInMB ): bellek megabayt cinsinden ifade edilir ve makinede bulunan fiziksel bellekle eşlenir.

Bu iki ölçüm için, küme kaynak yöneticisi (CRM) toplam küme kapasitesini, kümedeki her düğümdeki yükü ve kümedeki kalan kaynakları izler. Bu iki ölçüm, diğer Kullanıcı veya özel ölçümle eşdeğerdir. Var olan tüm özellikler bunlarla birlikte kullanılabilir:

• Küme, bu iki ölçümlere (varsayılan davranış) göre dengelenebilir .
• Küme, bu iki ölçümlere göre birleştirilebilirler .
• Bir kümeyi açıkladığında, bu iki ölçüm için arabelleğe alınan kapasite ayarlanabilir.

Kaynak idare mekanizması

Sürüm 7,2 ' den başlayarak Service Fabric çalışma zamanı, CPU ve bellek kaynakları için isteklerin ve limitlerin belirtimini destekler.

• Istek sayısı: CPU ve bellek isteği değerleri, ve ölçümleri için küme kaynak yöneticisi (CRM) tarafından kullanılan yükleri temsil servicefabric:/_CpuCores eder servicefabric:/_MemoryInMB . Diğer bir deyişle, CRM bir hizmetin kaynak tüketimini istek değerlerine eşit olacak şekilde değerlendirir ve yerleştirme kararları verirken bu değerleri kullanır.

• Sınırlar: CPU ve bellek sınırı değerleri, bir düğüm üzerinde bir işlem veya kapsayıcı etkinleştirildiğinde uygulanan gerçek kaynak sınırlarını temsil eder.

Service Fabric, CPU ve bellek için requestsonly, limitsonly ve her Iki requestsandlimit belirtimlerine izin verir.

• RequestsOnly belirtimi kullanıldığında, Service Fabric istek değerlerini de sınırlar olarak kullanır.
• LimitsOnly belirtimi kullanıldığında, Service Fabric istek değerlerini 0 olarak değerlendirir.
• Requestsandlimit belirtimi kullanıldığında, sınır değerleri istek değerlerinden büyük veya ona eşit olmalıdır.

Kaynak idare mekanizmasını daha iyi anlamak için, CPU kaynağı için Requestsonly belirtimine sahip örnek yerleştirme senaryosuna bakalım (bellek yönetimi mekanizması eşdeğerdir). İki CPU çekirdeği ve üzerine yerleştirilecek iki hizmet paketi içeren bir düğüm düşünün. Yerleştirilecek ilk hizmet paketi yalnızca bir kapsayıcı kodu paketinden oluşur ve yalnızca bir CPU çekirdeği isteği belirtir. Yerleştirilecek ikinci hizmet paketi yalnızca tek bir işlem tabanlı kod paketinden oluşur ve aynı zamanda yalnızca bir CPU çekirdeği isteği belirtir. Her iki hizmet paketinde de bir RequestsOnly belirtimi olduğundan, sınır değerleri kendi istek değerlerine ayarlanır.

1. İlk olarak, bir CPU çekirdeği isteyen kapsayıcı tabanlı hizmet paketi düğüme yerleştirilir. Çalışma zamanı kapsayıcıyı etkinleştirir ve CPU sınırını bir çekirdekli olarak ayarlar. Kapsayıcı birden fazla çekirdek kullanamaz.

2. Ardından, bir CPU çekirdeği isteyen işlem tabanlı hizmet paketi düğüme yerleştirilir. Çalışma zamanı, hizmet sürecini etkinleştirir ve CPU sınırını bir çekirdekli olarak ayarlar.

Bu noktada, isteklerin toplamı düğümün kapasitesine eşittir. CRM, bu düğümdeki CPU istekleriyle daha fazla kapsayıcı veya hizmet işlemi yerleştirmeyecektir. Düğümde, bir işlem ve kapsayıcı her biri çekirdekle çalışır ve CPU için birbirleriyle devam etmez.

Şimdi de Requestsandlimit belirtimi ile örneğimizi tekrar ziyaret edelim. Bu kez, kapsayıcı tabanlı hizmet paketi bir CPU çekirdeği isteği ve iki CPU çekirdeği sınırı belirtir. İşlem tabanlı hizmet paketi hem isteği hem de bir CPU çekirdeği sınırını belirtir.

1. Önce kapsayıcı tabanlı hizmet paketi düğüme yerleştirilir. Çalışma zamanı kapsayıcıyı etkinleştirir ve CPU sınırını iki çekirdeğe ayarlar. Kapsayıcı ikiden fazla çekirdek kullanamaz.
2. Sonra, işlem tabanlı hizmet paketi düğüme yerleştirilir. Çalışma zamanı, hizmet sürecini etkinleştirir ve CPU sınırını bir çekirdekli olarak ayarlar.

Bu noktada, düğüme yerleştirilmiş olan hizmet paketlerinin CPU isteklerinin toplamı, düğümün CPU kapasitesine eşittir. CRM, bu düğümdeki CPU istekleriyle daha fazla kapsayıcı veya hizmet işlemi yerleştirmeyecektir. Ancak, düğümünde limitlerin toplamı (kapsayıcı için iki çekirdek + işlem için bir çekirdek) iki çekirdeğin kapasitesini aşıyor. Kapsayıcı ve işlem aynı anda veri bloğu varsa, CPU kaynağı için çekişme olasılığı vardır. Bu çekişme, platformun temel alınan işletim sistemi tarafından kullanılacaktır. Bu örnekte, kapsayıcı iki CPU çekirdeğini patlama ve bu da işlemin bir CPU çekirdeği isteği garantisi oluşmasına neden olabilir.

CPU için çekişme olabilecek bazı durumlar vardır. Bu durumlarda, örneğimizin işlem ve kapsayıcısı gürültülü komşu sorunu yaşayabilirler:

• Yönetilen ve yönetilmeyen Hizmetleri ve kapsayıcıları karıştırma: bir Kullanıcı hiçbir kaynak İdaresi olmadan bir hizmet oluşturursa, çalışma zamanı bu dosyayı kaynak olmadan görür ve örneğimizdeki düğüme yerleştirebilir. Bu durumda, bu yeni işlem düğümde zaten çalışmakta olan hizmetlerin ücretine göre bazı CPU kullanımını etkili bir şekilde tüketir. Bu sorunun iki çözümü vardır. Aynı kümede yönetilen ve yönetilmeyen Hizmetleri karışmayın ya da bu iki hizmet türünün aynı düğüm kümesine bitmesi için yerleştirme kısıtlamalarını kullanın.

• Düğüm üzerinde başka bir işlem başlatıldığında Service Fabric dışında (örneğin, bir işletim sistemi hizmeti): Bu durumda, Service Fabric dışındaki işlem, var olan hizmetlerle CPU için de devam ediyor. Bu sorunun çözümü, sonraki bölümde gösterildiği gibi, işletim sistemi ek yükünü hesaba eklemek için düğüm kapasitelerinin doğru şekilde ayarlanmadır.

• İstekler sınırlara eşit olmadığında: Requestsandlimit örneğinde daha önce açıklandığı gibi, istekler bir düğümdeki kaynakların rezervasyonuna yol açabilir. İsteklerle daha büyük sınırlara sahip bir hizmet bir düğüme yerleştirildiğinde, kaynakları (varsa) bu sınıra kadar kullanabilir. Bu gibi durumlarda, düğümdeki diğer hizmetler, istek değerlerine kadar kaynakları tüketemeyebilir.

Kaynak yönetimini etkinleştirmek için küme kurulumu

Bir düğüm başlatıldığında ve kümeye katıldığında, Service Fabric kullanılabilir bellek miktarını ve kullanılabilir çekirdek sayısını algılar ve bu iki kaynak için düğüm kapagruplarını ayarlar.

İşletim sistemi için arabellek alanını bırakmak ve düğümde çalışıyor olabilecek diğer süreçler için, Service Fabric düğümde kullanılabilir kaynakların yalnızca %80 ' unu kullanır. Bu yüzde yapılandırılabilir ve küme bildiriminde değiştirilebilir.

Aşağıda, kullanılabilir CPU 'nun %50 ' i ve kullanılabilir belleğin %70 ' i kullanmak için Service Fabric nasıl talimat alınacağını gösteren bir örnek verilmiştir:

<Section Name="PlacementAndLoadBalancing">
    <!-- 0.0 means 0%, and 1.0 means 100%-->
    <Parameter Name="CpuPercentageNodeCapacity" Value="0.5" />
    <Parameter Name="MemoryPercentageNodeCapacity" Value="0.7" />
</Section>

Çoğu müşteri ve senaryo için, CPU ve bellek için düğüm kapasitelerinin otomatik algılanması önerilen yapılandırmadır (otomatik algılama varsayılan olarak açıktır). Ancak, düğüm kapasitelerinin tam el ile kurulumunu yapmanız gerekiyorsa, kümedeki düğümleri açıklama mekanizmasını kullanarak düğüm türü başına yapılandırabilirsiniz. Düğüm türünü dört çekirdekli ve 2 GB bellek ile ayarlamaya yönelik bir örnek aşağıda verilmiştir:

    <NodeType Name="MyNodeType">
      <Capacities>
        <Capacity Name="servicefabric:/_CpuCores" Value="4"/>
        <Capacity Name="servicefabric:/_MemoryInMB" Value="2048"/>
      </Capacities>
    </NodeType>

Kullanılabilir kaynakların otomatik algılanması etkin olduğunda ve düğüm kapasiteleri küme bildiriminde el ile tanımlandığında Service Fabric, düğümün kullanıcının tanımladığı kapasiteyi desteklemek için yeterli kaynağa sahip olup olmadığını denetler:

• Bildirimde tanımlanan düğüm kapasiteleri, düğümdeki kullanılabilir kaynaklardan azsa veya buna eşitse, Service Fabric bildirimde belirtilen kapasiteleri kullanır.

• Bildirimde tanımlanan düğüm kapasiteleri kullanılabilir kaynaklardan fazlaysa, Service Fabric kullanılabilir kaynakları düğüm kapasiteleri olarak kullanır.

Gerekli değilse, kullanılabilir kaynakların otomatik algılanması kapatılabilir. Devre dışı bırakmak için aşağıdaki ayarı değiştirin:

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="AutoDetectAvailableResources" Value="false" />
</Section>

En iyi performans için, küme bildiriminde aşağıdaki ayar de açılmalıdır:

<Section Name="PlacementAndLoadBalancing">
    <Parameter Name="PreventTransientOvercommit" Value="true" />
    <Parameter Name="AllowConstraintCheckFixesDuringApplicationUpgrade" Value="true" />
</Section>

Kaynak yönetimini belirtin

Kaynak idare istekleri ve limitleri uygulama bildiriminde (Servicemanifestımport bölümünde) belirtilir. Bazı örneklere bakalım:

Örnek 1: RequestsOnly belirtimi

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCores="1"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="1024" />
    </Policies>
  </ServiceManifestImport>

Bu örnekte, CpuCores özniteliği servicepackagea için 1 CPU çekirdekli bir istek belirtmek için kullanılır. CPU sınırı ( özniteliği) belirtilmedi Service Fabric, hizmet paketi için CPU sınırı olarak 1 çekirdek belirtilen istek CpuCoresLimit değerini de kullanır.

ServicePackageA yalnızca bu düğüme yerleştirilen tüm hizmet paketlerinin CPU isteklerinin toplamı çıkarıldıktan sonra kalan CPU kapasitesinin 1 çekirdekten büyük veya bu değere eşit olduğu bir düğüme yerleştirilir. Düğümde hizmet paketi tek çekirdekle sınırlı olacaktır. Hizmet paketi iki kod paketi içerir (CodeA1 ve CodeA2) ve her ikisi de CpuShares özniteliğini belirtir. Tek tek kod paketlerinin CPU sınırlarını hesaplamak için CpuShares 512:256 oranı kullanılır. Bu nedenle CodeA1, bir çekirdeğin üçte ikisi ile sınırlı olacak ve CodeA2 de bir çekirdeğin üçte biri ile sınırlı olacak. CpuShare'ler tüm kod paketleri için belirtilmezse, Service Fabric CPU sınırını bunlar arasında eşit olarak böler.

Kod paketleri için belirtilen CpuShare'ler hizmet paketinin genel CPU sınırının göreli oranını temsil ederken, kod paketleri için bellek değerleri mutlak terimlerle belirtilir. Bu örnekte, özniteliği hem CodeA1 hem de MemoryInMB CodeA2 için 1024 MB bellek isteklerini belirtmek için kullanılır. Bellek sınırı ( özniteliği) belirtilmedikten, Service Fabric paketleri için sınır olarak belirtilen istek MemoryInMBLimit değerlerini de kullanır. Hizmet paketi için bellek isteği (ve sınırı), ilgili kod paketlerinin bellek isteği (ve limit) değerlerinin toplamı olarak hesaplanır. Bu nedenle ServicePackageA için bellek isteği ve sınırı 2048 MB olarak hesaplanır.

ServicePackageA yalnızca bu düğüme yerleştirilen tüm hizmet paketlerinin bellek isteklerinin toplamı çıkarıldıktan sonra kalan bellek kapasitesinin 2048 MB'den büyük veya bu değere eşit olduğu bir düğüme yerleştirilir. Düğümde her iki kod paketi de 1024 MB bellekle sınırlı olacaktır. Kod paketleri (kapsayıcılar veya işlemler) bu sınırdan daha fazla bellek ayıramayacak ve bunu yapmaya çalışılamaması yetersiz bellek özel durumlarının ortaya çıkar.

Örnek 2: LimitOnly belirtimi

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCoresLimit="1"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMBLimit="1024" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMBLimit="1024" />
    </Policies>
  </ServiceManifestImport>

Bu örnekte yalnızca CpuCoresLimit SF 7.2 ve sonraki sürümlerinde kullanılabilen ve MemoryInMBLimit öznitelikleri 2. CpuCoresLimit özniteliği, ServicePackageA için 1 çekirdek CPU sınırı belirtmek için kullanılır. CPU isteği ( CpuCores özniteliği) belirtilmedikten, 0 olarak kabul edilir. MemoryInMBLimit özniteliği CodeA1 ve CodeA2 için 1024 MB bellek sınırlarını belirtmek için kullanılır ve istekler (öznitelik) belirtilmedikten 0 olarak MemoryInMB kabul edilir. Bu nedenle ServicePackageA için bellek isteği ve sınırı sırasıyla 0 ve 2048 olarak hesaplanır. ServicePackageA için hem CPU hem de bellek istekleri 0 olduğu için, ve ölçümleri için CRM'nin yerleştirme için göz önünde bulundurarak yük servicefabric:/_CpuCores servicefabric:/_MemoryInMB oluşturmaz. Bu nedenle, kaynak idaresi perspektifinden bakıldığında, ServicePackageA kalan kapasiteden bağımsız olarak herhangi bir düğüme yer değiştirebilir. Örnek 1'e benzer şekilde, düğümde CodeA1 bir çekirdeğin üçte ikisi ve 1024 MB bellekle sınırlı olacak ve CodeA2 bir çekirdeğin üçte biri ve 1024 MB bellekle sınırlı olacaktır.

Örnek 3: RequestsAndLimits belirtimi

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCores="1" CpuCoresLimit="2"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="512" MemoryInMB="1024" MemoryInMBLimit="3072" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="256" MemoryInMB="2048" MemoryInMBLimit="4096" />
    </Policies>
  </ServiceManifestImport>

İlk iki örneği tamamlayan bu örnekte HEM CPU hem de bellek için istekler ve sınırlar belirtildi. ServicePackageA sırasıyla 1 çekirdek ve 3072 (1024 + 2048) MB CPU ve bellek isteklerine sahiptir. Yalnızca düğüme yerleştirilen tüm hizmet paketlerinin CPU (ve bellek) isteklerinin toplamı düğümün toplam CPU (ve bellek) kapasitesinden çıkarildikten sonra en az 1 çekirdek (ve 3072 MB) kapasiteye sahip bir düğüme yer olabilir. Düğümde CodeA1, 2 çekirdeğin üçte ikisi ve 3072 MB bellekle sınırlıyken CodeA2, 2 çekirdeğin üçte biri ve 4096 MB bellekle sınırlı olacaktır.

Uygulama parametrelerini kullanma

Kaynak idaresi ayarlarını belirtirken, birden çok uygulama yapılandırması yönetmek için uygulama parametrelerini kullanmak mümkündür. Aşağıdaki örnek, uygulama parametrelerinin kullanımını gösterir:

<?xml version='1.0' encoding='UTF-8'?>
<ApplicationManifest ApplicationTypeName='TestAppTC1' ApplicationTypeVersion='vTC1' xsi:schemaLocation='http://schemas.microsoft.com/2011/01/fabric ServiceFabricServiceModel.xsd' xmlns='http://schemas.microsoft.com/2011/01/fabric' xmlns:xsi='https://www.w3.org/2001/XMLSchema-instance'>

  <Parameters>
    <Parameter Name="CpuCores" DefaultValue="4" />
    <Parameter Name="CpuSharesA" DefaultValue="512" />
    <Parameter Name="CpuSharesB" DefaultValue="512" />
    <Parameter Name="MemoryA" DefaultValue="2048" />
    <Parameter Name="MemoryB" DefaultValue="2048" />
  </Parameters>

  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName='ServicePackageA' ServiceManifestVersion='v1'/>
    <Policies>
      <ServicePackageResourceGovernancePolicy CpuCores="[CpuCores]"/>
      <ResourceGovernancePolicy CodePackageRef="CodeA1" CpuShares="[CpuSharesA]" MemoryInMB="[MemoryA]" />
      <ResourceGovernancePolicy CodePackageRef="CodeA2" CpuShares="[CpuSharesB]" MemoryInMB="[MemoryB]" />
    </Policies>
  </ServiceManifestImport>

Bu örnekte, her Hizmet Paketi'nin 4 çekirdek ve 2 GB bellek alabiliyor olduğu üretim ortamı için varsayılan parametre değerleri ayarlanmıştır. Uygulama parametre dosyalarıyla varsayılan değerleri değiştirmek mümkündür. Bu örnekte, uygulamayı yerel olarak test etmek için bir parametre dosyası kullanılabilir ve burada üretime göre daha az kaynak elde kullanılmaktadır:

<!-- ApplicationParameters\Local.xml -->

<Application Name="fabric:/TestApplication1" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Parameters>
    <Parameter Name="CpuCores" DefaultValue="2" />
    <Parameter Name="CpuSharesA" DefaultValue="512" />
    <Parameter Name="CpuSharesB" DefaultValue="512" />
    <Parameter Name="MemoryA" DefaultValue="1024" />
    <Parameter Name="MemoryB" DefaultValue="1024" />
  </Parameters>
</Application>

Kullanıcı hizmetleri için kaynak sınırlarını zorlama

Service Fabric hizmetlerinize kaynak idaresi uygulamak, kaynak tarafından yönetilen hizmetlerin kaynak kotasını geçemeyeceklerini garantilerken, çoğu kullanıcının yine de Service Fabric hizmetlerinden bir çoğunu yönetilmiyor modunda çalıştırması gerekir. Yönetnilen Service Fabric hizmetleri kullanırken, "runaway" tarafından yönetilen hizmetlerin Service Fabric düğümler üzerinde kullanılabilir tüm kaynakları tükettiği ve bu durum aşağıdaki gibi ciddi sorunlara neden olabilir:

• Düğümlerde çalışan diğer hizmetlerin kaynak kullanımı (sistem hizmetleri dahil Service Fabric)
• Durumu iyi olmayan düğümler
• Küme yönetimi API'Service Fabric yanıt vermiyor

Bu durumların meydana Service Fabric, kullanıcı hizmetlerinin hiçbir zaman belirtilen miktardan daha fazla kaynak kullanmay güvencesi için düğümde çalışan tüm Service Fabric kullanıcı hizmetleri için kaynak sınırlarını zorunlu hale (hem yönetilen hem de yönetilen) uygulamama izin verir. Bu, ClusterManifest'in PlacementAndLoadBalancing bölümündeki EnforceUserServiceMetricCapacities yapılandırmasının değeri true olarak ayarlayarak elde edilir. Bu ayar varsayılan olarak kapalıdır.

<SectionName="PlacementAndLoadBalancing">
    <ParameterName="EnforceUserServiceMetricCapacities" Value="false"/>
</Section>

Ek açıklamalar:

• Kaynak sınırı zorlaması yalnızca ve servicefabric:/_CpuCores kaynak servicefabric:/_MemoryInMB ölçümleri için geçerlidir
• Kaynak sınırı zorlaması yalnızca otomatik algılama mekanizması aracılığıyla veya düğüm kapasitelerini el ile belirten kullanıcılar aracılığıyla (kaynak idaresini etkinleştirmeye yönelik küme kurulumu bölümünde açıklanmıştır) kaynak ölçümleri için düğüm kapasitelerinin Service Fabric tarafından kullanılabilir durumda olduğu durumda çalışır. Düğüm kapasiteleri yapılandırılmazsa, kaynak sınırı zorlama özelliği kullanılamaz çünkü Service Fabric kullanıcı hizmetleri için ne kadar kaynak tutulacaklarını bile bilmiyorum. Service Fabric "EnforceUserServiceMetricCapacities" true ise ancak düğüm kapasiteleri yapılandırılmamışsa bir sistem durumu uyarısı gösterir.

Kapsayıcılar için diğer kaynaklar

CPU ve belleğin yanı sıra kapsayıcılar için başka kaynak sınırları da belirtebilirsiniz. Bu sınırlar kod paketi düzeyinde belirtilir ve kapsayıcı başlatılana uygulanır. CPU ve bellek gibi Küme Kaynak Yöneticisi, bu kaynakları fark etmemektedir ve bunlar için kapasite denetimi veya yük dengelemesi yapmaz.

• MemorySwapInMB: MB olarak değiştirilebilir belleğin toplam miktarı. Pozitif bir tamsayı olmalıdır.
• MemoryReservationInMB: Yalnızca düğümde bellek belirsizliği algılandığında zorlanan bellek idaresi için yazılım sınırı (MB). Pozitif bir tamsayı olmalıdır.
• CpuPercent: Kullanılabilir CPU'ların kullanılabilir yüzdesi (yalnızca Windows). Pozitif bir tamsayı olmalıdır. CpuShares, CpuCores veya CpuCoresLimit ile kullanılamaz.
• CpuShares: Göreli CPU ağırlığı. Pozitif bir tamsayı olmalıdır. CpuPercent, CpuCores veya CpuCoresLimit ile kullanılamaz.
• MaximumIOps: kullanılmaktadır IOps açısından en yüksek IO oranı (okuma ve yazma). Pozitif bir tamsayı olmalıdır.
• MaximumIOBandwidth: kullanılmaktadır (okuma ve yazma). Pozitif bir tamsayı olmalıdır.
• BlockIOWeight: Diğer kod paketlerine göre, blok IO ağırlığı. 10 ile 1000 arasında pozitif bir tamsayı olmalıdır.
• DiskQuotaInMB: Kapsayıcılar için disk kotası. Pozitif bir tamsayı olmalıdır.
• KernelMemoryInMB: Bayt cinsinden çekirdek bellek sınırları. Pozitif bir tamsayı olmalıdır. Bunun Linux'a özgü olduğunu ve ayarlanırsa Windows'da Docker'ın hataya neden olduğunu unutmayın.
• ShmSizeInMB: Bayt cinsinden /dev/shm boyutu. Atlanırsa, sistem 64 MB kullanır. Pozitif bir tamsayı olmalıdır. Bunun Linux'a özgü olduğunu ancak Docker'ın belirtilmişse yalnızca yoksayacak (ve hata çıkarmayacak) olduğunu unutmayın.

Bu kaynaklar CPU ve bellekle bir araya kullanılabilir. Kapsayıcılar için ek kaynak belirtme örneği:

    <ServiceManifestImport>
        <ServiceManifestRef ServiceManifestName="FrontendServicePackage" ServiceManifestVersion="1.0"/>
        <Policies>
            <ResourceGovernancePolicy CodePackageRef="FrontendService.Code" CpuPercent="5"
            MemorySwapInMB="4084" MemoryReservationInMB="1024" MaximumIOPS="20" />
        </Policies>
    </ServiceManifestImport>

Sonraki adımlar

• Daha fazla bilgi için Küme Kaynak Yöneticisi küme kaynak yöneticisine Service Fabric.
• Uygulama modeli, hizmet paketleri ve kod paketleri hakkında daha fazla bilgi edinmek ve çoğaltmaların onlara nasıl eşley olduğu hakkında daha fazla bilgi edinmek için Service Fabric.