Назад | Перейти на главную страницу

Зачем ограничивать количество ядер выполнения, если вы не облачный провайдер

Мы ведем разработку системы, установленной на сайте заказчика на его виртуальном сервере. Это приложение время от времени требует большой работы. Однако ему было предоставлено только одно ядро.

Я вижу необходимость избегать того, чтобы приложение запускалось из-под контроля и останавливало все остальные приложения. Этого легко избежать, не давая приложению доступа более чем к половине процессоров.

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

Есть ли устоявшаяся передовая практика для основного администрирования?

Есть ли устоявшаяся передовая практика для основного администрирования?

Вы уже дали ответ: давайте по каждой заявке как можно меньше.

В идеале документация по системным требованиям поставщика дает разумные рекомендации по размеру (и не так часто встречается слишком большое количество ядер процессора / памяти / IOPS, чтобы быть в безопасности и всегда предотвращать потенциальные проблемы с производительностью). Мне нравится видеть минимальную поддерживаемую конфигурацию и таблицу размеров:

  • сценарий использования A -> Требования к оборудованию B
  • сценарий использования X -> Требования к оборудованию Y

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

Что касается восстановления после вращающихся процессов, типичным контраргументом будет написание лучшего программного обеспечения, которое этого не делает, и что ОС по-прежнему будет достаточно отзывчивой для восстановления.

Для обеспечения наилучшего времени отклика при высокой загрузке среды, чувствительные к задержкам, могут принять решение не увеличивать количество ядер процессора. Это обходится дорого, даже с 12 или 18-жильными сокетами.