Определение наличия узких мест в вашем дизайне OTP

Question

Если вы неправильно спроектируете иерархию OTP, какие ошибки вы увидите в рабочей среде?

Скажем, существует узкое место, когда у вас недостаточно работников и блоков кода, это в основном ошибки времени ожидания?

Есть ли способ мониторинга, если у вас есть узкое место?

Я знаю, что вы можете писать тесты, я уверен, кто-то может подсказать мне хороший пример сравнительного анализа для этого типапроверить?

Answer 1

Помимо неправильного проектирования дерева контроля, другой распространенной ошибкой является отправка слишком большого количества сообщений одному процессу.Процесс станет узким местом в том смысле, что в почтовом ящике процесса слишком много сообщений.И отправка сообщения в большой почтовый ящик в Erlang VM еще дороже.При настройке приоритета процесса по умолчанию он блокирует процесс вызывающего (как вы пытаетесь использовать GenServer.call), и, таким образом, этот процесс быстро станет узким местом в вашей системе.Тайм-аут, скорее всего, произойдет в этой ситуации.

Несмотря на то, что вы можете использовать Process.info(pid, :message_queue_len) для проверки размера очереди сообщений, есть такая библиотека, как recon , чтобы помочь вам контролировать как информационный процесс,ВМ во время выполнения.И в процессе разработки, я хочу просто запустить :observer.start в iex.Erlang Observer предлагает отличный интуитивно понятный способ проверки системной информации, деревьев супервизора и информации о процессах.

Answer 2

Скажем, есть узкое место, когда у вас недостаточно рабочих и ваших блоков кода, это в основном ошибки тайм-аута?

Нельзя защищаться от проблемы «недостаточно рабочих», покареальные условия четко указаны.Наличие 1М работников на 1 сообщение в час крайне неэффективно;1 рабочий на 1М сообщений в секунду блокирует.Там нет серебряной пули. Sidenote: для решения этой конкретной проблемы мы используем GenStage для противодействия давлению.

---

Наиболее распространенной проблемой AFAICT является неправильная конструкциядерево наблюдения, когда сбой одного из рабочих приводит к несогласованному состоянию (другие работники имеют устаревшие ссылки на это или подобное). В качестве примера можно привести работника, который поддерживает удаленное соединение и говорит RabbitMQ .Когда последний отказывает, нужно перезапустить / перенастроить все иждивенцы.

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

Будучи явно оптимизированным для высокой нагрузки, ErlangVM готов к некоторой обработкеобычно из коробки, и когда кто-то встречает очень необычные условия, нет чека, кроме как понять, где находится узкое место (оно всегда находится где-то, о чем вы никогда не могли подумать, кстати :) и исправить эту конкретную проблему .

Я сомневаюсь, что может существовать какое-либо общее решение.