Распространенным заблуждением относительно управления ресурсами для сервисов в SF является то, что это зарезервированный ресурс и изолированная емкость для вашего сервиса , как в док-контейнерах, и этоне соответствует действительности.
Эти показатели являются лишь мягкими ограничениями для поддержания баланса служб в кластере, но это не означает, что они зарезервированы исключительно для ваших служб, другие службы могут и будут использовать эти ресурсы, если ограничения не установлены.задавать.
Чтобы принудительное ограничение ресурсов работало, все пакеты кода в пакете услуг должны иметь указанные ограничения памяти.
Метрики - это меры, позволяющие найти надлежащий баланс услуг вкластеризовать и размещать сервисы в узлах с доступными ресурсами, поэтому при условии, что у вас есть свои сервисы A, B и C, и у каждого сервиса есть определенный объем требований к ресурсам, скажем, «Память», которую легко понять, A = 1000 МБ,B = 512 МБ, C = 512 МБ, и узел имеет 2 ГБ памяти, они могут быть размещены в одном и том же узле, поэтому при условии, что для службы C требуется 1000 МБ, при необходимости активации службы C она будет избегать того же узла, где A иB активированы, потому что у него нет возможности работать там, даже если эти службы не потребляют все запрашиваемые ресурсы, и будет выбран другой узел.
Из документов :
В настоящее время среда выполнения Service Fabric не обеспечивает резервирование ресурсов.Когда процесс или контейнер открыт, среда выполнения устанавливает ограничения ресурсов для нагрузок, которые были определены во время создания.Кроме того, среда выполнения отклоняет открытие новых пакетов услуг, доступных при превышении ресурсов.
Относительно вашего основного вопроса об общих ресурсах:
В тех же документах описывается, что общие ресурсы являютсяПропорция зарезервированного ядра ЦП, зарезервированного для пакета службы, распределяется между всеми пакетами кода, активированными на этом узле. Если вы определите общие ресурсы для каждого пакета кода, их сумма будет общей, и каждый из них получит долю от этихакции.
Как эти акции контролируются?
Имейте в виду, что нижеприведенное официально нигде не зарегистрировано, и я могу ошибаться в некоторых аспектах, я получил эту информацию отисходный код, и я мог пропустить некоторые детали
Предполагается, что пакет услуг с пакетами кодов A и B активирован со следующим разделением доли:
- Пакет кодов A(CP.A) = 1500 акций
- Пакет кодов B (CP.B) = 500 акций
SF:
- Определение емкости ядра ЦП, зарезервированной для пакета обслуживания:
- Емкость будет зарезервированной емкостью ядра ЦП (%) / всего доступного
- на 4-ядерном процессоре: 1 процессорное ядро зарезервировано = 25%
- Получите все акции из пакетов кода и суммируйте их значения, чтобы определить, сколько акций должно представлять 100% зарезервированной (25%) емкости
- 1500 + 500 = 2000 всего акций
- CP.A должен получить 3 фракции по 4
- CP.B должен получить 1 фракцию 4
- Преобразовать долю акций в Циклы заданий ЦП (см. Почему ниже)
- CP.A должен получить 3/4 из 10000 -> 7500 циклов
- CP.B должен получить 1/4 из10 000 -> 2500 циклов
- Умножьте количество зарезервированных циклов на количество зарезервированных ядер процессора
- CP.A должен получить 25% из 7500 циклов
- CP.B должен получить 25% из 2500 циклов
Эти ограничения ограничены Объектами заданий , когда процесс (пакет кода) активируется, он назначается заданию, в котором установлены эти ограничения, всякий раз, когда процесс потребляет больше циклов, чем ограничение, установленное взадание, потоки с приоритетом, и другой поток процесса запланирован в ядре.В коде они предлагают 10000 represents all available cores, но правильным является number of processor cycles that the threads in a job object can use during each scheduling interval.В задании 10000 циклов - это интервал каждого расписания заданий, в этом задании запланирован поток, который будет использовать x циклов этого расписания, и вы будете использовать только 10000 циклов, если резервируете 4 ядра.
Точная логика в этом бите кода:
double shares = fractionOfSp * Constants::JobObjectCpuCyclesNumber;
shares = shares * (numCoresAllocated / max(numAvailableCores_, systemCpuCores_));
rg.CpuShares = static_cast<uint>(shares);
//fractionOfSp -> Fraction of a Service Package
// - A service package represents 100% (Like a Pizza) of reserved core capacity
// - Each Code Package will have one or more fraction (A slice of the pizza)
//Constants::JobObjectCpuCyclesNumber -> is a constant for 10000 cycles
//numCoresAllocated -> How many cores you assigned to a service package
Некоторые приемы:
- Количество зарезервированных ядер также влияет на результат, вы должны зарезервировать не менее 0,01% отядро для достижения какого-либо эффекта.
- Общие ресурсы основаны на ядрах ЦП, зарезервированных для пакета услуг, и не на всех ЦП, доступных в узле. Если ваш узел имеет 4 ядра, вы резервируете 1 для ServicePackage, что означает, что выделят 25% емкости вашего узла между каждым пакетом кода.
- Если у некоторых пакетов кода нет общего ресурса или его нет, все пакеты кода будут иметь одинаковую долю, даже если вы укажете любое значение.
- В Linux он использует CpuQuota
- Максимальное количество циклов задания - 10k
Если вам нужна дополнительная информация, посмотрите исходный код здесь
PS: у меня закружилась голова при расчете всех этих чисел, я, вероятно, еще раз рассмотрю позже!