Управление ресурсами

Статья
03/25/2023

При выполнении нескольких служб на одном узле или кластере одна служба может потреблять больше ресурсов, оставляя другие работающие службы без них. Это также известно как проблема "шумного соседа". Azure Service Fabric позволяет разработчику управлять этим поведением, указывая запросы и ограничения для каждой службы, чтобы ограничить использование ресурсов.

Прежде чем продолжить работу с этой статьей, рекомендуется ознакомиться с моделью приложения Service Fabric и моделью размещения Service Fabric.

Метрики управления ресурсами

Управление ресурсами поддерживается в Service Fabric в соответствии с каждым пакетом службы. Ресурсы, которые назначены пакету службы, могут быть дополнительно разделены между пакетами кода. Service Fabric поддерживает систему управления ЦП и памятью для каждого пакета службы с помощью двух встроенных метрик:

ЦП (имя метрики — servicefabric:/_CpuCores): логические ядра, доступные на хост-компьютере. Веса всех ядер для всех узлов считаются одинаковыми.
Память (имя метрики — servicefabric:/_MemoryInMB): измеряется в мегабайтах и сопоставляется с физической памятью, доступной на компьютере.

Для обеих метрик Диспетчер кластерных ресурсов (CRM) отслеживает общую емкость кластера, нагрузку на каждом узле кластера и оставшиеся в кластере ресурсы. Эти две метрики аналогичны любой другой пользовательской или настраиваемой метрике.

Примечание

Имена пользовательских метрик не должны совпадать с одним из этих двух имен метрик, так как это приведет к неопределенному поведению.

Их можно использовать для всех существующих функций:

Кластер может быть сбалансирован в соответствии с этими двумя метриками (реакция на событие по умолчанию).
Кластер может быть дефрагментирован в соответствии с этими двумя метриками.
При описании кластера для этих двух метрик можно задать емкость буфера.

Примечание

Передача данных о динамической нагрузке не поддерживается этими метриками, и нагрузка для них определяется во время создания.

Механизм управления ресурсами

Начиная с версии 7.2, среда выполнения Service Fabric поддерживает спецификацию запросов и ограничений для ресурсов ЦП и памяти.

Примечание

Среды выполнения Service Fabric до версии 7.2 поддерживают только модель, в которой одно значение выступает в качестве запроса и ограничения для определенного ресурса (ЦП или памяти). В этом документе это описывается как спецификация RequestsOnly.

Запросы. Значения запросов ЦП и памяти представляют нагрузки, используемые Диспетчером кластерных ресурсов для метрик servicefabric:/_CpuCores и servicefabric:/_MemoryInMB. Иными словами, Диспетчер кластерных ресурсов считает значение потребления ресурсов службой равным значению ее запросов. Он использует эти значения при принятии решений о размещении.
Ограничения. Значения ограничений ЦП и памяти представляют фактические ограничения ресурсов, применяемые при активации процесса или контейнера на узле.

Service Fabric позволяет использовать спецификации RequestsOnly, LimitsOnly и обе спецификации RequestsAndLimits для ЦП и памяти.

При использовании спецификации RequestsOnly Service Fabric в качестве ограничений также использует значения запроса.
При использовании спецификации LimitsOnly Service Fabric считает, что значения запросов равны 0.
При использовании спецификации RequestsAndLimits значения ограничений должны быть больше или равны значениям запросов.

Чтобы лучше понять механизм системы управления ресурсами, рассмотрим пример сценария размещения со спецификацией RequestsOnly для ресурса ЦП (эквивалентно механизму управления памятью). Рассмотрим узел с двумя ядрами ЦП и двумя пакетами служб, которые в нем будут размещены. Первый пакет службы, который необходимо разместить, включает только один пакет кода контейнера и указывает запрос на одно ядро ЦП. Второй пакет службы, который необходимо разместить, включает всего один пакет кода на основе процесса и также указывает запрос на одно ядро ЦП. Так как оба пакета служб имеют спецификацию RequestsOnly, для значений запросов задаются их значения ограничений.

Сначала пакет службы на основе контейнера, которому требуется один ЦП, размещается на узле. Среда выполнения активирует этот контейнер и задает ограничение в 1 ядро ЦП. Этот контейнер не сможет использовать более 1 ядра.
Затем пакет службы на основе процесса, которому требуется один ЦП, размещается на узле. Среда выполнения активирует этот процесс службы и задает ограничение в 1 ядро ЦП.

На этом этапе сумма запросов равна емкости узла. CRM не сможет разместить большее количество контейнеров или процессов службы с запросами ЦП на этом узле. На узле процесс и контейнер используют по одному ядру и не конфликтуют друг с другом за ЦП.

Теперь вернемся к нашему примеру со спецификацией RequestsAndLimits. На этот раз пакет службы на основе контейнера указывает запрос и задает ограничение в 2 ядра ЦП. Пакет службы на основе процесса указывает запрос и задает ограничение в 1 ядро ЦП.

Сначала пакет службы на основе контейнера размещается на узле. Среда выполнения активирует этот контейнер и задает ограничение в 2 ядра ЦП. Этот контейнер не сможет использовать более 2 ядер.
Затем пакет службы на основе процесса размещается на узле. Среда выполнения активирует этот процесс службы и задает ограничение в 1 ядро ЦП.

На этом этапе сумма запросов ЦП к пакетам служб, размещенным на узле, равна производительности ЦП узла. CRM не сможет разместить большее количество контейнеров или процессов службы с запросами ЦП на этом узле. Однако на узле сумма ограничений (2 ядра для контейнера и 1 ядро для процесса) превышает значение производительности двух ядер. Если нагрузка на контейнер и процесс повышается одновременно, может возникнуть состязание за ресурсы ЦП. Таким состязанием будет управлять базовая ОС для платформы. В этом примере контейнер может использовать до 2 ядер ЦП, в результате чего запрос процесса одного ядра ЦП не гарантируется.

Примечание

Как показано в предыдущем примере, значения запроса ЦП и памяти не приводят к резервированию ресурсов на узле. Эти значения представляют потребление ресурсов, которое учитывает Диспетчер кластерных ресурсов при принятии решений о размещении. Значения ограничений представляют фактические ограничения ресурсов, применяемые при активации процесса или контейнера на узле.

Есть несколько ситуаций, в которых может возникнуть состязание за использование ЦП. В таких ситуациях у процесса и контейнера из нашего примера может возникнуть проблема "шумного соседа".

Сочетание управляемых и не управляемых служб и контейнеров: если пользователь создает службу и не указывает управление ресурсами, среда выполнения решит, что она не использует ресурсы, и разместит ее на узле из нашего примера. В таком случае этот новый процесс будет активно использовать некоторые ресурсы ЦП за счет служб, которые уже запущены на узле. Эту проблему можно устранить двумя способами. Для этого не следует смешивать управляемые и не управляемые службы в одном кластере или следует использовать ограничения размещения, чтобы службы этих двух типов использовали разные наборы узлов.
Когда на узле запущен другой процесс, который не относится к процессам Service Fabric (например, служба ОС): в этой ситуации процесс извне Service Fabric также будет состязаться за ресурсы ЦП с имеющимися службами. Избежать этой проблемы можно, правильно настроив емкость узла с учетом дополнительной нагрузки на ОС, как описано в разделе ниже.
Если значения запросов не равны значениям ограничений. Как описано в примере RequestsAndLimits ранее, запросы не приводят к резервированию ресурсов на узле. Если служба с ограничениями, значения которых превышают значения запросов, размещается на узле, она может потреблять ресурсы (если они доступны) до указанных ограничений. В таких случаях другие службы на узле могут не иметь возможности использовать ресурсы в соответствии с их значениями запросов.

Настройка кластера для включения управления ресурсами

Когда узел запустится и присоединится к кластеру, Service Fabric обнаружит доступный объем памяти и доступное количество ядер и задаст емкости узла для этих двух ресурсов.

Чтобы оставить место в буфере для операционной системы и других процессов, которые могут быть запущены на узле, Service Fabric будет использовать только 80 % от доступных на нем ресурсов. Это процентное значение можно настроить и изменить в манифесте кластера.

Ниже приведен пример, как настроить Service Fabric для использования 50 % от доступных ресурсов ЦП и 70 % от доступной памяти:

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

Для большинства клиентов и сценариев рекомендуется использовать автоматическое обнаружение емкости узлов ЦП и памяти (автоматическое обнаружение включено по умолчанию). Однако, если емкости узлов нужно настроить только вручную, их можно настроить для каждого типа узла с помощью механизма описания узлов в кластере. Ниже приведен пример настройки типа узла с 4 ядрами и 2 ГБ памяти.

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

Если включено автоматическое обнаружение доступных ресурсов и в манифесте кластера емкости узлов определены вручную, Service Fabric проверит, достаточно ли в узле ресурсов для поддержки определенной пользователем емкости.

Если емкостей узлов, определенных в манифесте, недостаточно для доступных на узле ресурсов (или же хватает), Service Fabric будет использовать емкости, указанные в манифесте.
Если емкости узлов, определенные в манифесте, превышают количество доступных ресурсов, Service Fabric будет использовать эти доступные ресурсы как емкости узла.

Если автоматическое обнаружение доступных ресурсов не требуется, его можно отключить. Для этого измените приведенный ниже параметр.

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

Для достижения оптимальной производительности следующий параметр также должен быть включен в манифесте кластера:

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

Важно!

Начиная с версии Service Fabric 7.0, мы обновили правило для вычисления емкости ресурсов узла в случаях, когда пользователь вручную предоставляет значения емкости ресурсов узла. Рассмотрим следующий сценарий.

Для узла выделено 10 ядер ЦП.
Service Fabric настроен для использования 80 % от общего количества ресурсов для пользовательских служб (значение по умолчанию). Другие службы, работающие на узле (включая системные службы Service Fabric), будут использовать память буфера в размере 20 %.
Пользователь решает вручную переопределить емкость ресурса узла для метрики ядра ЦП и устанавливает для этого 5 ядер.

Мы изменили правило расчета доступной емкости для пользовательских служб Service Fabric следующим образом:

До версии Service Fabric 7.0 для пользовательских служб будет рассчитана доступная емкость для 5 ядер (буфер емкости 20 % игнорируется).
Начиная с Service Fabric версии 7.0, для пользовательских служб будет рассчитана доступная емкость для4 ядер (буфер емкости 20 % не игнорируется).

Настройка управления ресурсами

Запросы ограничения ресурсов системы управления указываются в манифесте приложения (раздел ServiceManifestImport). Рассмотрим несколько примеров:

Пример 1. Спецификация RequestsOnly

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

В этом примере атрибут CpuCores используется для указания запроса 1 ядра ЦП для ServicePackageA. Так как ограничение ЦП (атрибут CpuCoresLimit) не указано, Service Fabric также использует указанное значение запроса 1 ядра в качестве ограничения ЦП для пакета службы.

Спецификация ServicePackageA будет размещена только на узле, где оставшийся ресурс ЦП после вычитания суммы запросов ЦП всех пакетов служб, размещенных на этом узле, больше или равен 1 ядру. На узле пакет службы будет ограничен одним ядром. Этот пакет службы содержит два пакета кода (CodeA1 и CodeA2), и оба указывают атрибут CpuShares. Доля CpuShares 512:256 используется для вычисления ограничений ЦП для отдельных пакетов кода. Таким образом, пакет кода CodeA1 будет ограничен двумя третями ядер, а CodeA2 — одной третью. Если параметр CpuShares не указан для всех пакетов кода, Service Fabric делит ограничение ЦП между ними поровну.

Хотя параметр CpuShares, указанный для пакетов кода, представляет относительную долю от общего ограничения ЦП пакета службы, значения памяти для пакетов кода указываются в абсолютных выражениях. В этом примере атрибут MemoryInMB используется для указания запросов памяти размером 1024 МБ для пакетов кода CodeA1 и CodeA2. Так как ограничение памяти (атрибут MemoryInMBLimit) не указано, Service Fabric также использует указанные значения запроса в качестве ограничений для пакетов кода. Запрос памяти (и ограничение) для пакета службы вычисляется как сумма значений запросов (и ограничений) памяти составляющих пакетов кода. Таким образом, для ServicePackageA запрос и ограничение памяти рассчитываются как 2048 МБ.

Спецификация ServicePackageA будет размещена только на узле, где оставшийся объем памяти после вычитания суммы запросов памяти всех пакетов служб, размещенных на этом узле, больше или равен 2048 МБ. На узле оба пакета кода будут ограничены 1024 МБ памяти. Пакеты кода (контейнеры или процессы) не могут выделить больше памяти, чем задано ограничением, а при попытке сделать это возникнет проблема нехватки памяти.

Пример 2. Спецификация LimitsOnly

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

В этом примере используются атрибуты CpuCoresLimit и MemoryInMBLimit, которые доступны только в Service Fabric 7.2 и более поздних версиях. Атрибут CpuCoresLimit используется для указания ограничения ЦП ServicePackageA в 1 ядро. Так как запрос ЦП (атрибут CpuCores) не указан, считается, что он равен 0. Атрибут MemoryInMBLimit используется для указания ограничения памяти 1024 МБ для пакетов кода CodeA1 и CodeA2. Так как запросы (атрибут MemoryInMB) не указаны, считается, что они равны 0. Таким образом, значения запроса и ограничения памяти для пакета ServicePackageA вычисляются как 0 и 2048 соответственно. Так как запросы ЦП и памяти для ServicePackageA равны 0, они не создают нагрузки для CRM, которую следует учитывать при размещении метрик servicefabric:/_CpuCores и servicefabric:/_MemoryInMB. Таким образом, с точки зрения системы управления ресурсами ServicePackageA можно разместить на любом узле независимо от оставшейся емкости. Как и в примере 1, пакет кода CodeA1 на узле будет ограничен двумя третьими емкости ядра и 1024 МБ памяти, а пакет CodeA2 будет ограничен одной третьей емкости ядра и 1024 МБ памяти.

Пример 3. Спецификация RequestsAndLimits

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

Основываясь на первых двух примерах, в этом примере демонстрируется указание запросов и ограничений для ЦП и памяти. Значения ЦП и запросов памяти для пакета ServicePackageA: 1 ядро и 3072 МБ (1024 + 2048) соответственно. Пакет можно разместить только на узле с по крайней мере 1 ядром (и 3072 МБ памяти) емкости после вычитания суммы всех запросов ЦП (и памяти) всех пакетов служб, размещенных на узле, из общей емкости ЦП (и памяти) узла. Пакет кода CodeA1 на узле будет ограничен двумя третьими емкости 2 ядер и 3072 МБ памяти, тогда как пакет CodeA2 будет ограничен одной третьей емкости 2 ядер и 4096 МБ памяти.

Использование параметров приложения

При указании параметров системы управления ресурсами можно использовать параметры приложения, чтобы управлять несколькими конфигурациями приложений. Ниже приведен пример с использованием параметров приложения.

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

В этом примере задаются значения параметров по умолчанию для рабочей среды, в которой каждому пакету службы выделяются 4 ядра и 2 ГБ памяти. Значения по умолчанию можно изменить с помощью файлов параметров приложения. В этом примере один файл параметров может использоваться для тестирования приложения в локальной среде, в которой ему предоставляется меньше ресурсов, чем в рабочей среде.

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

Важно!

Указание системы управления ресурсами с помощью параметров приложения доступно, начиная с Service Fabric версии 6.1.

Если параметры приложения используются для указания системы управления ресурсами, то невозможно перейти на использование версии Service Fabric, более ранней, чем версия 6.1.

Применение ограничений ресурсов для пользовательских служб

Применение системы управления ресурсами к службам Service Fabric гарантирует, что эти управляемые ресурсом службы не смогут превышать квоту ресурсов. Многие пользователи все равно должны запускать некоторые из своих служб Service Fabric в неуправляемом режиме. При использовании неуправляемых служб Service Fabric можно столкнуться с ситуациями, когда неуправляемые службы бесконтрольно потребляют все доступные ресурсы на узлах Service Fabric. Это может привести к серьезным проблемам, таким как:

нехватка ресурсов для других служб, работающих на узлах (включая системные службы Service Fabric);
завершение работы узлов по причине неработоспособного состояния;
неотвечающие API-интерфейсы управления кластерами Service Fabric.

Чтобы предотвратить возникновение таких ситуаций, Service Fabric позволяет применять ограничения ресурсов для всех пользовательских служб Service Fabric, выполняемых на узле (как управляемых, так и неуправляемых). Это позволит гарантировать, что пользовательские службы никогда не будут использовать больше указанного объема ресурсов. Для этого устанавливается значение True для конфигурации EnforceUserServiceMetricCapacities в разделе PlacementAndLoadBalancing в ClusterManifest. По умолчанию этот параметр отключен.

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

Дополнительные примечания:

Ограничение использования ресурсов применяется только к метрикам ресурсов servicefabric:/_CpuCores и servicefabric:/_MemoryInMB.
Ограничение ресурсов можно применить только в том случае, если емкость узла для метрик ресурсов доступна для Service Fabric. Это можно сделать с помощью механизма автоматического обнаружения, либо пользователям необходимо вручную указать емкость узла (как описано в разделе Настройка кластера для включения управления ресурсами). Если емкость узла не настроена, невозможно применить ограничения к ресурсам, так как Service Fabric не может определить, сколько ресурсов резервируется для пользовательских служб. Service Fabric выдаст предупреждение о работоспособности, если значение EnforceUserServiceMetricCapacities равно True, а емкость узлов не настроена.

Другие ресурсы для контейнеров

Помимо ограничений ресурсов ЦП и памяти можно указать другие ограничения ресурсов для контейнеров. Эти ограничения указываются на уровне пакета кода и будут применены при запуске контейнера. В отличие от ограничений ресурсов ЦП и памяти, диспетчер кластерных ресурсов не будет учитывать эти ресурсы и не будет выполнять проверки емкости или балансировку нагрузки для них.

MemorySwapInMB. Общий объем используемой памяти подкачки, в МБ. Принимаются только положительные целые числа.
MemoryReservationInMB. Мягкое ограничение (в МБ) по управлению памятью, которое применяется, только когда на узле обнаруживается состязание за память. Принимаются только положительные целые числа.
CpuPercent. Процент доступных используемых ЦП (только для Windows). Принимаются только положительные целые числа. Не может использоваться с CpuShares, CpuCores и CpuCoresLimit.
CpuShares. Относительный вес ЦП. Принимаются только положительные целые числа. Не может использоваться с CpuPercent, CpuCores и CpuCoresLimit.
MaximumIOps. Максимальная скорость ввода-вывода (чтение и запись) с точки зрения операций ввода-вывода, которые могут использоваться. Принимаются только положительные целые числа.
MaximumIOBandwidth. Максимальная скорость ввода-вывода (в байтах в секунду), которую можно использовать (чтение и запись). Принимаются только положительные целые числа.
BlockIOWeight. Вес блока ввода-вывода, относительно других пакетов кода. Принимается только целочисленное значение в диапазоне от 10 до 1000.
DiskQuotaInMB. Дисковая квота для контейнеров. Принимаются только положительные целые числа.
KernelMemoryInMB. Ограничения памяти ядра в байтах. Принимаются только положительные целые числа. Обратите внимание, что это применимо только для Linux. При использовании данного атрибута в Docker на платформе Windows возникнет ошибка.
ShmSizeInMB. Размер /dev/shm в байтах. Если размер не указан, система использует 64 МБ. Принимаются только положительные целые числа. Обратите внимание, что это применимо только для Linux. Однако при использовании данного атрибута в Docker он будет игнорироваться (ошибка не возникнет).

Эти ресурсы можно объединять с ресурсами ЦП и памяти. Ниже приведен пример определения дополнительных ресурсов для контейнеров:

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

Следующие шаги

Дополнительные сведения о диспетчере кластерных ресурсов см. в статье Общие сведения о диспетчере кластерных ресурсов Service Fabric.
Дополнительные сведения о модели приложения, пакетах служб и пакетах кода см. в статье Моделирование приложения в структуре службы.

Управление ресурсами

Метрики управления ресурсами

Механизм управления ресурсами

Настройка кластера для включения управления ресурсами

Настройка управления ресурсами

Использование параметров приложения

Применение ограничений ресурсов для пользовательских служб

Другие ресурсы для контейнеров

Следующие шаги

Дополнительные ресурсы