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 "bullrig granne"-problemet. 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 är tilldelade till tjänstpaketet kan delas upp ytterligare mellan kodpaket. Service Fabric stöder 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 i alla noder viktas på samma sätt.

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

För dessa två mått spårar Kluster Resource Manager (CRM) den totala klusterkapaciteten, belastningen på varje nod i klustret och de återstående resurserna i klustret. Dessa två mått motsvarar alla andra användar- eller anpassade mått.

Anteckning

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.

Anteckning

Dynamisk belastningsrapportering stöds inte för dessa mått. belastningar för dessa mått definieras vid skapandetillfället.

Resursstyrningsmekanism

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

Anteckning

Service Fabric-körningsversioner som är äldre än 7.2 stöder bara 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 kluster 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-specifikation 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.

Nu ä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 var och kommer inte att konkurrera med varandra om CPU.

Nu ska vi gå tillbaka till vårt exempel med en RequestsAndLimits-specifikation . 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 för 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 kommer att 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.

Anteckning

Som du ser i föregående exempel leder inte begärandevärdena för CPU och minne till reservation av resurser på en nod. Dessa värden representerar den resursförbrukning som klustret Resource Manager beaktar 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 problemet med den bullriga grannen:

• 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 effektivt en del CPU 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 även processen utanför Service Fabric 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 operativsystemets 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 det är tillgängligt) upp till gränserna. 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 buffertutrymmet 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 är aktiverad 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 nodkapaciteterna 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 behö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. Låt oss överväga 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ällning), 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 åsidosätta nodresurskapaciteten manuellt 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 gränser för resursstyrning anges i programmanifestet (avsnittet ServiceManifestImport). 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 bara 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 attributet CpuShares . 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 värdena för begäran som gränser för kodpaketen. Minnesbegäran (och gräns) för tjänstpaketet beräknas som summan av värdena för minnesbegäran (och gräns) för dess ingående kodpaket. För ServicePackageA beräknas minnesbegäran och gräns som 2 048 MB.

ServicePackageA placeras bara 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 attributen och MemoryInMBLimit 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 attributet) 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äns för ServicePackageA beräknas därför som 0 respektive 2048. Eftersom både CPU- och minnesbegäranden för ServicePackageA är 0 innebär det 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ärna respektive 3 072 (1 024 + 2 048). Den kan bara placeras på en nod som har minst 1 kärnor (och 3 072 MB) kapacitet kvar när du har subtraherat summan av alla CPU-begäranden (och minne) för alla tjänstpaket som placeras på noden från nodens totala CPU-kapacitet (och minne) för noden. 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 får 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 får ö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ält av andra tjänster som körs på noderna (inklusive Service Fabric-systemtjänster)
• Noder som hamnar i ett feltillstånd
• API:er för hantering av Service Fabric-kluster som inte svarar

För att förhindra att sådana 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 styrda och okontrollerade) för att garantera att användartjänsterna aldrig kommer att använda 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 resursgräns gäller endast för resursmåtten servicefabric:/_CpuCores och servicefabric:/_MemoryInMB
• Tvingande resursgränser fungerar bara 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 inte funktionen för tvingande resursgräns 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 går det 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 är kluster Resource Manager inte medvetna om dessa resurser och kommer inte att göra några 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 1000.
• DiskQuotaInMB: Diskkvot för containrar. Måste vara ett positivt heltal.
• KernelMemoryInMB: Gränser för kernelminne i byte. Måste vara ett positivt heltal. Observera att det här är Linux-specifikt och Docker i Windows får ett felmeddelande 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 kluster Resource Manager finns i Introduktion till Resurshanteraren för Service Fabric-kluster.
• Mer information om programmodellen, tjänstpaket och kodpaket – och hur repliker mappas till dem – finns i Modellera ett program i Service Fabric.