апач часто зависает с semop
Хотя я ненавижу модные словечки, я должен защитить это, Вы проявляете Целостный подход, вместо того, чтобы пытаться установить базовые метрики, на которых можно категоризировать Ваши рабочие нагрузки для виртуализации.
В самом неопределенном из терминов вид основных определяющих факторов, которые можно использовать:
- Поддержка - Будет рассматриваемая ОС, даже выполненная в виртуальной среде? Сделайте Ваши Приложения зависят от чего-либо, что не может работать правильно в среде VM (например, лицензировать аппаратные ключи). Поставщики Вашей ОС и Приложения оказывают поддержку для систем, если это находится на виртуальной платформе?
- Лицензирование - у поставщика есть совместимое лицензионное соглашение для выполнения в Вашей виртуальной среде? Будут дополнительные затраты на лицензирование из-за увеличенных спецификаций хост-сервера?
- Использование ЦП - Какова характеристика использования ЦП на данном сервере? Это истратило ЦП в течение часа каждый день, потому что это генерирует крупный отчет? Это на самом деле вызвало бы проблему, если бы потребовалось 2 часа вместо этого?
- Использование диска - видит использование ЦП
- Использование оперативной памяти - видит использование ЦП
- Использование сети - видит использование ЦП
Также остерегайтесь Опасностей Методологии. Виртуализация среды компаний берут навык, опыт и немного креативного мышления для осуществления правильно, и необходимо будет глубокомысленно соединить среду, которую можно обеспечить с рабочими нагрузками, которые необходимо поддерживать при переплетении в целом наборе бизнес-требований и оппортунистических улучшений инфраструктуры по пути. Можно записать руководство для этого материала, но результат того подхода не обеспечит оптимальное значение бизнесу.
Я считаю, что вы споткнулись из-за малоизвестной проблемы. Похоже, это ошибка в Linux, где счетчик семефоров уже равен 0, но процессы ждут, как будто это не так. Я не понимаю механизма этой ошибки, но она, очевидно, происходит только на загруженных машинах.
Выполните ipcs -s -i $ SEM_ID , где $ SEM_ID - это первый аргумент, передаваемый semop (). Он должен показать, что счетчик равен 0, что подтвердит, что проблема в Linux, а не в Apache. Если значение не равно 0, проблема будет в коде Apache.
Похоже, вы не обновляли ядро около 2 лет, с тех пор могло быть исправление. Другие сообщили, что ограничение пути epoll в 1000 не позволяет Apache использовать более 1000 настроек «максимального количества клиентов».
Если кто-то еще наткнется на эту тему.
Мы столкнулись с проблемой в продукте со сшиванием OCSP, из-за которой все дочерние процессы зависали в semop после установления TCP-соединения, но до завершения рукопожатия TLS. По-видимому, главный сервер ждал скрепки OCSP от не отвечающего сервера OCSP. Кроме того, клиенты могут продолжать зависать в рукопожатии TLS, ожидая собственной проверки.