Resursstyrning

När du kör flera tjänster på samma nod eller kluster är det möjligt att en tjänst kan förbruka fler resurser och svälta andra tjänster i processen. Det här problemet kallas "bullriga granne"-problem. Med Azure Service Fabric kan utvecklaren styra det här beteendet genom att ange begäranden och begränsningar per tjänst för att begränsa resursanvändningen.

Innan du fortsätter med den här artikeln rekommenderar vi att du bekantar dig med Service Fabric-programmodellen och Service Fabric-värdmodellen.

Mått för resursstyrning

Resursstyrning stöds i Service Fabric i enlighet med tjänstpaketet. De resurser som har tilldelats till tjänstpaketet kan delas upp ytterligare mellan kodpaket. Service Fabric har stöd för processor- och minnesstyrning per tjänstpaket med två inbyggda mått:

• CPU (måttnamn servicefabric:/_CpuCores): En logisk kärna som är tillgänglig på värddatorn. Alla kärnor över alla noder viktas på samma sätt.

• Minne (måttnamn servicefabric:/_MemoryInMB): Minnet uttrycks i megabyte och mappas till fysiskt minne som är tillgängligt på datorn.

För dessa två mått spårar Cluster Resource Manager (CRM) total klusterkapacitet, belastningen på varje nod i klustret och de återstående resurserna i klustret. Dessa två mått motsvarar alla andra användare eller anpassade mått.

Kommentar

Anpassade måttnamn bör inte vara ett av dessa två måttnamn eftersom det leder till odefinierat beteende.

Alla befintliga funktioner kan användas med dem:

• Klustret kan balanseras enligt dessa två mått (standardbeteende).
• Klustret kan defragmenteras enligt dessa två mått.
• När du beskriver ett kluster kan buffrad kapacitet anges för dessa två mått.

Kommentar

Dynamisk inläsningsrapportering stöds inte för dessa mått. Belastningar för dessa mått definieras vid skapandetillfället.

Mekanism för resursstyrning

Från och med version 7.2 stöder Service Fabric-körningen specifikation av begäranden och gränser för PROCESSOR- och minnesresurser.

Kommentar

Service Fabric-körningsversioner som är äldre än 7.2 stöder endast en modell där ett enda värde fungerar både som begäran och gränsen för en viss resurs (CPU eller minne). Detta beskrivs som RequestsOnly-specifikationen i det här dokumentet.

• Begäranden: Värden för cpu- och minnesbegäran representerar de belastningar som används av Cluster Resource Manager (CRM) för måtten servicefabric:/_CpuCores och servicefabric:/_MemoryInMB . Crm anser med andra ord att resursförbrukningen för en tjänst är lika med dess begärandevärden och använder dessa värden när du fattar placeringsbeslut.

• Gränser: CPU- och minnesgränsvärden representerar de faktiska resursgränser som tillämpas när en process eller en container aktiveras på en nod.

Service Fabric tillåter RequestsOnly, LimitsOnly och både RequestsAndLimits specifikationer för CPU och minne.

• När RequestsOnly-specifikation används använder Service Fabric även begärandevärdena som gränser.
• När LimitsOnly-specifikationen används anser Service Fabric att begärandevärdena är 0.
• När RequestsAndLimits-specifikationen används måste gränsvärdena vara större än eller lika med begärandevärdena.

För att bättre förstå resursstyrningsmekanismen ska vi titta på ett exempel på placeringsscenario med en RequestsOnly-specifikation för CPU-resursen (mekanismen för minnesstyrning är likvärdig). Överväg en nod med två CPU-kärnor och två tjänstpaket som ska placeras på den. Det första tjänstpaketet som ska placeras består av bara ett containerkodpaket och anger bara en begäran om en CPU-kärna. Det andra tjänstpaketet som ska placeras består av bara ett processbaserat kodpaket och anger också bara en begäran om en CPU-kärna. Eftersom båda tjänstpaketen har en RequestsOnly-specifikation anges deras gränsvärden till sina begärandevärden.

1. Först placeras det containerbaserade tjänstpaketet som begär en CPU-kärna på noden. Körningen aktiverar containern och anger CPU-gränsen till en kärna. Containern kan inte använda mer än en kärna.

2. Därefter placeras det processbaserade tjänstpaketet som begär en CPU-kärna på noden. Körningen aktiverar tjänstprocessen och anger cpu-gränsen till en kärna.

I det här läget är summan av begäranden lika med nodens kapacitet. CRM kommer inte att placera fler containrar eller tjänstprocesser med CPU-begäranden på den här noden. På noden körs en process och en container med en kärna vardera och kommer inte att konkurrera med varandra om CPU.

Nu ska vi gå tillbaka till vårt exempel med specifikationen RequestsAndLimits . Den här gången anger det containerbaserade tjänstpaketet en begäran om en CPU-kärna och en gräns på två CPU-kärnor. Det processbaserade tjänstpaketet anger både en begäran och en gräns på en CPU-kärna.

1. Först placeras det containerbaserade tjänstpaketet på noden. Körningen aktiverar containern och anger cpu-gränsen till två kärnor. Containern kan inte använda fler än två kärnor.
2. Därefter placeras det processbaserade tjänstpaketet på noden. Körningen aktiverar tjänstprocessen och anger cpu-gränsen till en kärna.

I det här läget är summan av CPU-begäranden för tjänstpaket som placeras på noden lika med nodens CPU-kapacitet. CRM kommer inte att placera fler containrar eller tjänstprocesser med CPU-begäranden på den här noden. På noden överskrider dock summan av gränserna (två kärnor för containern + en kärna för processen) kapaciteten för två kärnor. Om containern och processen spricker samtidigt finns det risk för konkurrens för CPU-resursen. Sådan konkurrens hanteras av det underliggande operativsystemet för plattformen. I det här exemplet kan containern brista upp till två CPU-kärnor, vilket resulterar i att processens begäran om en CPU-kärna inte garanteras.

Kommentar

Som du ser i föregående exempel leder inte begärandevärdena för PROCESSOR och minne till reservation av resurser på en nod. Dessa värden representerar den resursförbrukning som Klusterresurshanteraren tar hänsyn till när du fattar placeringsbeslut. Gränsvärden representerar de faktiska resursgränser som tillämpas när en process eller en container aktiveras på en nod.

Det finns några situationer där det kan finnas konkurrens om CPU. I dessa situationer kan processen och containern från vårt exempel uppleva det bullriga grannproblemet:

• Blandning av reglerade och icke-styrda tjänster och containrar: Om en användare skapar en tjänst utan någon angiven resursstyrning ser körningen den som att den inte förbrukar några resurser och kan placera den på noden i vårt exempel. I det här fallet förbrukar den här nya processen i praktiken en del PROCESSOR på bekostnad av de tjänster som redan körs på noden. Det finns två lösningar på det här problemet. Blanda antingen inte reglerade och icke-styrda tjänster i samma kluster eller använd placeringsbegränsningar så att dessa två typer av tjänster inte hamnar på samma uppsättning noder.

• När en annan process startas på noden, utanför Service Fabric (till exempel en OS-tjänst): I den här situationen konkurrerar processen utanför Service Fabric även om PROCESSOR med befintliga tjänster. Lösningen på det här problemet är att konfigurera nodkapaciteter korrekt för att ta hänsyn till os-omkostnader, som du ser i nästa avsnitt.

• När begäranden inte är lika med gränser: Enligt beskrivningen i exemplet RequestsAndLimits tidigare leder begäranden inte till reservation av resurser på en nod. När en tjänst med gränser som är större än begäranden placeras på en nod kan den förbruka resurser (om de är tillgängliga) upp till gränsen. I sådana fall kanske andra tjänster på noden inte kan använda resurser upp till sina begärandevärden.

Klusterkonfiguration för att aktivera resursstyrning

När en nod startar och ansluter till klustret identifierar Service Fabric den tillgängliga mängden minne och det tillgängliga antalet kärnor och anger sedan nodkapaciteterna för dessa två resurser.

För att lämna buffertutrymme för operativsystemet och för andra processer som kan köras på noden använder Service Fabric endast 80 % av de tillgängliga resurserna på noden. Den här procentandelen kan konfigureras och kan ändras i klustermanifestet.

Här är ett exempel på hur du instruerar Service Fabric att använda 50 % av den tillgängliga processorn och 70 % av det tillgängliga minnet:

<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>

För de flesta kunder och scenarier är automatisk identifiering av nodkapaciteter för CPU och minne den rekommenderade konfigurationen (automatisk identifiering aktiveras som standard). Men om du behöver fullständig manuell konfiguration av nodkapaciteter kan du konfigurera dem per nodtyp med hjälp av mekanismen för att beskriva noder i klustret. Här är ett exempel på hur du konfigurerar nodtypen med fyra kärnor och 2 GB minne:

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

När automatisk identifiering av tillgängliga resurser är aktiverat och nodkapaciteter definieras manuellt i klustermanifestet kontrollerar Service Fabric att noden har tillräckligt med resurser för att stödja den kapacitet som användaren har definierat:

• Om nodkapaciteter som definieras i manifestet är mindre än eller lika med de tillgängliga resurserna på noden använder Service Fabric de kapaciteter som anges i manifestet.

• Om nodkapaciteter som definieras i manifestet är större än tillgängliga resurser använder Service Fabric de tillgängliga resurserna som nodkapaciteter.

Automatisk identifiering av tillgängliga resurser kan inaktiveras om det inte krävs. Om du vill inaktivera det ändrar du följande inställning:

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

För optimala prestanda bör följande inställning också vara aktiverad i klustermanifestet:

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

Viktigt!

Från och med Service Fabric version 7.0 har vi uppdaterat regeln för hur nodresurskapaciteter beräknas i de fall då användaren manuellt tillhandahåller värdena för nodresurskapaciteter. Föreställ dig följande scenario:

• Det finns totalt 10 CPU-kärnor på noden
• SF har konfigurerats för att använda 80 % av de totala resurserna för användartjänsterna (standardinställningen), vilket lämnar en buffert på 20 % för de andra tjänsterna som körs på noden (inkl. Service Fabric-systemtjänster)
• Användaren bestämmer sig för att manuellt åsidosätta nodresurskapaciteten för måttet CPU-kärnor och anger den till 5 kärnor

Vi har ändrat regeln för hur den tillgängliga kapaciteten för Service Fabric-användartjänster beräknas på följande sätt:

• Före Service Fabric 7.0 beräknas tillgänglig kapacitet för användartjänster till 5 kärnor (kapacitetsbuffert på 20 % ignoreras)
• Från och med Service Fabric 7.0 beräknas tillgänglig kapacitet för användartjänster till 4 kärnor (kapacitetsbuffert på 20 % ignoreras inte)

Ange resursstyrning

Begäranden och begränsningar för resursstyrning anges i programmanifestet (ServiceManifestImport-avsnittet). Låt oss titta på några exempel:

Exempel 1: RequestsOnly-specifikation

<?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>

I det här exemplet CpuCores används attributet för att ange en begäran om 1 CPU-kärna för ServicePackageA. Eftersom CPU-gränsen (CpuCoresLimit attributet) inte har angetts använder Service Fabric även det angivna värdet för begäran på 1 kärna som CPU-gräns för tjänstpaketet.

ServicePackageA placeras endast på en nod där den återstående CPU-kapaciteten efter att ha subtraherat summan av CPU-begäranden för alla tjänstpaket som placerats på noden är större än eller lika med 1 kärna. På noden begränsas tjänstpaketet till en kärna. Tjänstpaketet innehåller två kodpaket (CodeA1 och CodeA2) och båda anger CpuShares attributet. Andelen CpuShares 512:256 används för att beräkna CPU-gränserna för de enskilda kodpaketen. CodeA1 begränsas därför till två tredjedelar av en kärna och CodeA2 begränsas till en tredjedel av en kärna. Om CpuShares inte har angetts för alla kodpaket delar Service Fabric cpu-gränsen lika mellan dem.

Medan CpuShares som anges för kodpaket representerar deras relativa andel av tjänstpaketets övergripande CPU-gräns, anges minnesvärden för kodpaket i absoluta termer. I det här exemplet MemoryInMB används attributet för att ange minnesbegäranden på 1 024 MB för både CodeA1 och CodeA2. Eftersom minnesgränsen (MemoryInMBLimit attributet) inte har angetts använder Service Fabric även de angivna begärandevärdena som gränser för kodpaketen. Minnesbegäran (och gränsen) för tjänstpaketet beräknas som summan av värdena för minnesbegäran (och gräns) för dess komponentkodpaket. För ServicePackageA beräknas minnesbegäran och gränsen därför som 2 048 MB.

ServicePackageA placeras endast på en nod där den återstående minneskapaciteten efter att ha subtraherat summan av minnesbegäranden för alla tjänstpaket som placerats på noden är större än eller lika med 2 048 MB. På noden begränsas båda kodpaketen till 1 024 MB minne vardera. Kodpaket (containrar eller processer) kommer inte att kunna allokera mer minne än den här gränsen, och om du försöker göra det resulterar det i undantag utan minne.

Exempel 2: LimitsOnly-specifikation

<?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>

I det här exemplet används CpuCoresLimit och MemoryInMBLimit attribut, som endast är tillgängliga i SF-versionerna 7.2 och senare. Attributet CpuCoresLimit används för att ange en CPU-gräns på 1 kärna för ServicePackageA. Eftersom CPU-begäran (CpuCores attribut) inte har angetts anses den vara 0. MemoryInMBLimit -attributet används för att ange minnesgränser på 1 024 MB för CodeA1 och CodeA2 och eftersom begäranden (MemoryInMB attributet) inte anges anses de vara 0. Minnesbegäran och gränsen för ServicePackageA beräknas därför som 0 respektive 2048. Eftersom både CPU- och minnesbegäranden för ServicePackageA är 0, visas ingen belastning för CRM att överväga för placering, för måtten servicefabric:/_CpuCores och servicefabric:/_MemoryInMB . Ur ett resursstyrningsperspektiv kan därför ServicePackageA placeras på valfri nod oavsett återstående kapacitet. I likhet med exempel 1 begränsas CodeA1 på noden till två tredjedelar av en kärna och 1 024 MB minne, och CodeA2 begränsas till en tredjedel av en kärna och 1 024 MB minne.

Exempel 3: RequestsAndLimits-specifikation

<?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>

Det här exemplet bygger på de två första exemplen och visar hur du anger både begäranden och gränser för CPU och minne. ServicePackageA har processor- och minnesbegäranden på 1 kärnor respektive 3072 (1 024 + 2 048) MB. Den kan bara placeras på en nod som har minst 1 kärnor (och 3 072 MB) kapacitet kvar efter att ha subtraherat summan av alla CPU-begäranden (och minne) för alla tjänstpaket som placeras på noden från nodens totala processorkapacitet (och minne). På noden begränsas CodeA1 till två tredjedelar av 2 kärnor och 3 072 MB minne medan CodeA2 begränsas till en tredjedel av 2 kärnor och 4 096 MB minne.

Använda programparametrar

När du anger inställningar för resursstyrning är det möjligt att använda programparametrar för att hantera flera appkonfigurationer. I följande exempel visas användningen av programparametrar:

<?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>

I det här exemplet anges standardparametervärden för produktionsmiljön, där varje tjänstpaket skulle få 4 kärnor och 2 GB minne. Det går att ändra standardvärden med programparameterfiler. I det här exemplet kan en parameterfil användas för att testa programmet lokalt, där det skulle få färre resurser än i produktion:

<!-- 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>

Viktigt!

Det går att ange resursstyrning med programparametrar från och med Service Fabric version 6.1.

När programparametrar används för att ange resursstyrning kan inte Service Fabric nedgraderas till en version före version 6.1.

Framtvinga resursgränser för användartjänster

När du tillämpar resursstyrning på dina Service Fabric-tjänster garanterar att dessa resursstyrda tjänster inte kan överskrida sin resurskvot, måste många användare fortfarande köra några av sina Service Fabric-tjänster i okontrollerat läge. När du använder okontrollerade Service Fabric-tjänster är det möjligt att stöta på situationer där "skenande" okontrollerade tjänster förbrukar alla tillgängliga resurser på Service Fabric-noderna, vilket kan leda till allvarliga problem som:

• Resurssvältning av andra tjänster som körs på noderna (inklusive Service Fabric-systemtjänster)
• Noder hamnar i ett felfritt tillstånd
• Api:er för hantering av Service Fabric-kluster som inte svarar

För att förhindra att dessa situationer inträffar kan du med Service Fabric tillämpa resursgränserna för alla Service Fabric-användartjänster som körs på noden (både reglerade och okontrollerade) för att garantera att användartjänster aldrig använder mer än den angivna mängden resurser. Detta uppnås genom att ange värdet för enforceUserServiceMetricCapacities-konfigurationen i avsnittet PlacementAndLoadBalancing i ClusterManifest till true. Den här inställningen är inaktiverad som standard.

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

Ytterligare kommentarer:

• Tvingande av resursgränser gäller endast för resursmåtten servicefabric:/_CpuCores och servicefabric:/_MemoryInMB
• Tvingande av resursgränser fungerar endast om nodkapaciteter för resursmåtten är tillgängliga för Service Fabric, antingen via mekanismen för automatisk identifiering eller via användare som manuellt anger nodkapaciteterna (enligt beskrivningen i avsnittet Klusterkonfiguration för aktivering av resursstyrning ). Om nodkapaciteter inte har konfigurerats kan resursgränsens tvingande kapacitet inte användas eftersom Service Fabric inte kan veta hur mycket resurser som ska reserveras för användartjänster. Service Fabric utfärdar en hälsovarning om "EnforceUserServiceMetricCapacities" är sant men nodkapaciteterna inte har konfigurerats.

Andra resurser för containrar

Förutom CPU och minne är det möjligt att ange andra resursgränser för containrar. Dessa gränser anges på kodpaketsnivå och tillämpas när containern startas. Till skillnad från cpu och minne känner Inte Klusterresurshanteraren till dessa resurser och utför inga kapacitetskontroller eller belastningsutjämning för dem.

• MemorySwapInMB: Den totala mängden växlingsminne som kan användas i MB. Måste vara ett positivt heltal.
• MemoryReservationInMB: Den mjuka gränsen (i MB) för minnesstyrning som endast framtvingas när minneskonkurration identifieras på noden. Måste vara ett positivt heltal.
• CpuPercent: Användbar procentandel av tillgängliga processorer (endast Windows). Måste vara ett positivt heltal. Kan inte användas med CpuShares, CpuCores eller CpuCoresLimit.
• CpuShares: Relativ CPU-vikt. Måste vara ett positivt heltal. Kan inte användas med CpuPercent, CpuCores eller CpuCoresLimit.
• MaximumIOps: Maximal I/O-hastighet (läsning och skrivning) när det gäller IOps som kan användas. Måste vara ett positivt heltal.
• MaximumIOBandwidth: Den maximala I/O (byte per sekund) som kan användas (läsa och skriva). Måste vara ett positivt heltal.
• BlockIOWeight: Blockera I/O-vikt i förhållande till andra kodpaket. Måste vara ett positivt heltal mellan 10 och 1 000.
• DiskQuotaInMB: Diskkvot för containrar. Måste vara ett positivt heltal.
• KernelMemoryInMB: Minnesgränser för kernel i byte. Måste vara ett positivt heltal. Observera att detta är Linux-specifikt och Docker i Windows får fel om detta har angetts.
• ShmSizeInMB: Storleken på /dev/shm i byte. Om det utelämnas använder systemet 64 MB. Måste vara ett positivt heltal. Observera att detta är Linux-specifikt, men Docker ignorerar bara (och inte fel ut) om det anges.

Dessa resurser kan kombineras med CPU och minne. Här är ett exempel på hur du anger ytterligare resurser för containrar:

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

Nästa steg

• Mer information om Klusterresurshanteraren finns i Introduktion till Service Fabric-klusterresurshanteraren.
• Om du vill veta mer om programmodellen, tjänstpaketen och kodpaketen – och hur repliker mappas till dem – läser du Modell ett program i Service Fabric.