Сообщение Re[11]: WA: 3 млн tcp соединений на одном сервере от 06.08.2020 5:43
Изменено 06.08.2020 5:55 netch80
Re[11]: WA: 3 млн tcp соединений на одном сервере
Здравствуйте, SkyDance, Вы писали:
N>>Баги — исправляются. А вот принципиальная тормознутость рантайма — с ней сильно сложнее.
SD>Я так понимаю, "принципиальная тормознутость" рассматривается ниже (с конкретными проблемами). Или есть еще что-то еще? Кроме заявлений про "тормознутость", чтобы было нечто осмысленное. А то я вижу, что "тормознутость" — это 50.000 юзеров на машину в кластере (средней руки мессенджер на жаве) и 500.000 на такую же машину (на Эрланге).
В случае Java, я думаю, сделано просто какого-то явно лишнего кода. Или в условиях очень коротких сработок на один клиентский запрос с длительными ожиданиями между ними — сделана какая-нибудь глупость типа персональной нити на каждого клиента. Иначе бы такой суровой разницы не было.
Но это надо смотреть реализацию в деталях: что делается и как.
N>>Да. Только надо перестать смотреть на это как на "переизобретение эрланга". Даже если Erlang был одно время образцом, то все эти реализации уже давно ушли дальше.
SD>Это и есть переизобретение эрланга. "Эти реализации" ушли не дальше, а в болото. Как туда уходит любой мейнстрим, см. Жава, С++.
Вы можете считать это болотом, но эта кочка зрения (tm) не выглядит обоснованной. Мейнстрим уходит в обеспечение значительно более широкого набора потребностей, чем нишевый продукт, в более разнообразных условиях. Но это никак не означает невозможность качественной специализации под конкретную реализацию.
N>>OK, когда будут множественные входные очереди на процесс?
SD>Сначала нужно объяснить, зачем. Один из патчей, который я сделал, как раз подобная поддержка (в слегка упрощенном виде, т.н. prepend send, послать сообщение в голову очереди). Но чем больше я занимаюсь архитектурой и более серьезным пониманием происходящих процессов, тем больше я понимаю, как был неправ. Просто на тот момент, когда я это сделал, у меня не было достаточно знаний. Сейчас эти знания есть, и я понимаю, что и prepend send, и "множественные очереди", и priority queues — это ошибочные направления. Но, повторюсь, чтобы это понять, нужно действительно провести много времени за изучением этих проблем.
Ну в таком случае выдайте на-гора, пожалуйста, хоть немного этой мудрости (в хорошем смысле), почему это "ошибочное направление". А то то, что я вижу, пока что подтверждает важность подхода.
Вот например RabbitMQ борется с такой проблемой:
Опишите, пожалуйста, вашу точку зрения на их решение, одним из следующих вариантов (допустимы мелкие поправки):
1. Да, ребята молодцы, что для решения проблемы они полезли в обход аж двух слоёв стандартной библиотеки (gen_tcp и prim_inet), рискуя несовместимостью с будущими реализациями, так и надо. MQ много, OTP одна. Пусть страдают при переходе, не наше дело.
2. Нет, надо было искать чудо и делать, чтобы очередь никогда не превышала K сообщений, где K < N. Как это делать — да хоть через ETS, которую наполняет другой процесс. Публичная ETS (потому что удаляет другой процесс, чем добавляет) не страшна, все свои.
3. Надо было сидеть и страдать. Нефиг тут неуправляемые входные потоки принимать на процесс. TCP приёмник нормально контролирует, а заторы возникают по дороге? Пофиг, у меня всё работает (tm).
4. Вы неверно понимаете задачу и вообще у вас плохой дзен, становитесь ёжиками. Детали не интересуют, я стратегию разрабатываю.
5. Иное (интересно, что?)
N>>С какой версии это стало нормально работать? Я после 2015 не смотрел, до этого коллеги пробовали — не работало.
SD>В следующий раз посоветуй коллегам разобраться. Оно работало всегда. Могло не хватать каких-то инструментов для удобства. Но systools были еще с 90х годов.
Я именно про rebar. Где-то с 2012 вместо прежних подходов, когда народ достаточно любовно настраивал обстановку и был готов к тому, что система должна работать 24*365, пошли новые подходы типа
1) Пакуем всё в один тарболл вместе с рантаймом, зависимостями и рабочим кодом
2) Всей задачи девопам — развернуть на сервере и запустить
3) Прерывание сервиса? Если волнует, переедут на соседние узлы, если нет — и так пофиг
4) Завернём это ещё и в докер, нефиг тратить время на тюнинг внешних компонентов
5) failover, takeover, relup? Дядя, ты с кем сейчас разговаривал? У нас свои средства кластеризации и надёжности в кластере (90% — просто общая SQL база).
и именно к этому подходу rebar подошёл идеально и стал основным инструментом.
И на него тогда даже смотрели "а он сможет обеспечить нормальный relup на месте, без рестарта, при своей паковке?" и на версиях тех времён однозначно не сложилось.
N>>Основное было системой мониторинга кластера "Ломоносов". Её у нас забрали прямо в процессе затыкания этих проблем
SD>Вот в это я могу поверить — что в силу политических причин ("забрали проект") у кого-то образовалось неприятие к инструментам, которыми попросту не научились пользоваться.
Нет, для себя мы её решили — костылями различной кривости. На продуктин оно не ушло — или ушло, не знаем — но это уже стало не нашей заботой.
N>>А тут она ещё и грубо неверна. Когда проект начинался, мы взяли в контору группу военных админов(!) и они успешно за срок менее месяца переключились на проектирование и написание (при том, что часть ещё и не имела опыта программирования кроме одноэкранных скриптов баша) — и всё шло замечательно до тех пор, пока под реальной нагрузкой не начались уже характерно эрланговые проблемы, как минимум:
SD>Прям-таки классика жанра! Когда я написал "нельзя набрать обезьян" — я ровно это и имел в виду. Дело в том, что синтаксис и "первые шаги" на Эрланге до одури просты. И потому возникает ощущение "мы все поняли и все умеем". Но когда дело доходит до написания реального софта, оказывается, что кроме синтаксиса нужно еще... понять, что такое OTP, и как на самом деле надо пользоваться языком. Вы, однако, так и не поняли. Посему и проблемы, перечисленые ниже. Как раз отражение непонимания, как должна работать система.
Спасибо за извинения за "обезьян" (в соседнем сообщении), повторюсь, что именно эта группа не имеет отношения к проблемам перегрузки. Проблемы же возникали в следующей обстановке:
1. Приложение NA принимает входной поток (его плотность... ну давайте для простоты остановимся на цифре 10K сообщений в секунду) из толпы разных источников (можно распределять между экземплярами приложения на разных узлах). Но сообщение групповое, содержит ~50 вложенных других, и реально обрабатывается 500K. При первичной обработке поток сокращается в ~5 раз, получается 100K mps. Одно сообщение со всеми деталями это, насколько помню, около 200 байт. Вроде бы поток небольшой.
2. Поток выходных сообщений из NA отправляется на несколько приёмников, для простоты скажем про 2: генератор первичных логических выводов (NMU) и логгер. Реально между ними сидит ещё приложение шины.
3. NMU делает первичные выводы и посылает их на шину 2. Там свои логгер и групповая логика.
4. Приложение групповой логики (GL) делает выводы уже финальные — типа "стойка 123 недопустимо перегрета, надо выключать оборудование".
В спокойной обстановке на участке NMU — GL поток сообщений в десятки раз меньше входного потока NMU (то есть тысячи, если не сотни, в секунду, уровня "тут всё спокойно, тангаж, крен, рысканье в норме, температура 36.6"), при проблемах — может подскакивать до равного потока (считаем, те же 100K mps). Работа при пиковой нагрузке, соответственно, критична (должно быть всё гладко-линейно и должен ещё быть запас производительности).
Реально частично работало горизонтальное деление — NC, NMU, часть GL просто горизонтально масштабировалась. Но уже участок — вершина GL, и всё, что за ним — регистратор алармов, логгеры этой части, генератор команд по выводам GL (типа, уже надо грубо выключать ток) — не масштабируются. У получателя, типа регистратора, один отправитель. Не 100500 отдельных мелких, каждый из которых послал какое-нибудь "GET /zuka HTTP/1.1", а один, и он не ждёт — посылает следующие.
И вот тут начинается, что любой из процессов — приёмников потока:
1) Если он делает только обработку входящих сообщений и асинхронные посылки другим — живёт. (На самом деле чуть сложнее — иногда получалось, что и в этом случае начиналось торможение. Но этот вопрос на потом.)
2) Если ему хоть иногда надо делать синхронные вызовы (gen_server:call) и соответственно сразу ждать отвёт — всё, суши вёсла: из накопления входной очереди выше 10-20K сообщений он не способен уже выйти. Граница неточная, но, похоже, связана с размером кэша процессора. Само же временное переполнение, безвредное в других условиях,
3) Даже если он сам не делает синхронные вызовы, задача оперативно получить состояние, не блокируя запрашивающего на недопустимый срок (1 секунда уже предел), не выполняется — пока прорабатываются остальные, {'$call',запрос} стоит в конце очереди.
Вот теперь я хочу послушать Ваши предложения по исправлению этих проблем в пределах текущих возможностей Erlang.
N>>1) Переполнение входных очередей без возможности адекватного взаимодействия с пострадавшими процессами; лечилось грубыми хаками типа просовывания управляющих команд через ETS с соседним процессом;
SD>Иными словами, не смогли правильно реализовать backpressure.
Нет. Backpressure вообще недопустим на участке как минимум после NMU. Есть некоторый уровень нагрузки, который в ламинарном состоянии это весьма мелкая доля от того, что может осилить железо и рантайм. Но это в ламинарном. Как только где-то перегрузка, Erlang не даёт восстановиться.
В том решении, которое было испытано локально, но не дошло до целевой эксплуатации, было сделано, что при детекте перегрузки NMU приостанавливает отдачу разрешений посылки сообщений исходным агентам. Но даже это пришлось решать немного хакерски, ну и сама постановка вопроса означала, что система не справляется с задачей — состояние должно сниматься не реже раза в секунду.
SD> Справедливости ради, это действительно holy grail асинхронного программирования, и по сути нормально нигде и не реализовано. Да, есть теоретические измышления (SEDA та же) и кое-какие реализации (а ля GenStage), но чтоб серьезно к этому делу подойти, — пока руки не дошли. На данный момент все в стадии написания whitepaper.
Меня тут не интересуют дискуссии о теоретических основах. Остановить агентов мы были в состоянии. Реально они сами останавливались, не получив команды "даю разрешение на 5 отчётов". Меня интересует именно устойчивость реакции на перегрузку.
N>>2) Страшно тормозной global, с синхронизацией, страдающей при перегрузке (попросту кластер рассыпался — и это при несчастных ~30 узлах); сейчас, по слухам, есть настройка "межкластерные данные идут по другим каналам, чем heartbeats", я не успел это сделать — выдернули на живую.
SD>Сейчас global попросту не нужен (как он не был нужен и раньше). Если нужны process groups, они уже есть (и нет, не pg2, которые работали поверх global). В общем, то, что вы не смогли кластер из 30+ машин поднять, так я про то и пишу — надо было разработчиков высокой квалификации брать. Тогда и 20.000 машин в кластере не были бы проблемой, и даже 30.000 (больше просто пока не требовалось).
И снова домыслы и критика "обезьян". Но это я отложу на следующий заход.
N>>Были и другие, поменьше, но облом вспоминать (попросишь — подниму архивы).
SD>Нет смысла. Я уже понимаю, что не тот уровень знаний.
Нет, это ваш уровень верхоглядства и наплевательства. Я надеюсь, что вы его таки переборете, иначе точно нет смысла обсуждать с вами эти проблемы.
N>>Эти проблемы я обсуждал с Валкиным, Лапшиным, Димандтом
SD>А надо было обсуждать с Lukas Larsson, Kenneth Lundin, Rickard Green, Sverker Eriksson, Kjell Winnblad. Круг, действительно, узок, и он не включает ни одной из указанных выше фамилий.
Общением с кем-то из core team занимались другие коллеги. Успеха не добились.
N>>Баги — исправляются. А вот принципиальная тормознутость рантайма — с ней сильно сложнее.
SD>Я так понимаю, "принципиальная тормознутость" рассматривается ниже (с конкретными проблемами). Или есть еще что-то еще? Кроме заявлений про "тормознутость", чтобы было нечто осмысленное. А то я вижу, что "тормознутость" — это 50.000 юзеров на машину в кластере (средней руки мессенджер на жаве) и 500.000 на такую же машину (на Эрланге).
В случае Java, я думаю, сделано просто какого-то явно лишнего кода. Или в условиях очень коротких сработок на один клиентский запрос с длительными ожиданиями между ними — сделана какая-нибудь глупость типа персональной нити на каждого клиента. Иначе бы такой суровой разницы не было.
Но это надо смотреть реализацию в деталях: что делается и как.
N>>Да. Только надо перестать смотреть на это как на "переизобретение эрланга". Даже если Erlang был одно время образцом, то все эти реализации уже давно ушли дальше.
SD>Это и есть переизобретение эрланга. "Эти реализации" ушли не дальше, а в болото. Как туда уходит любой мейнстрим, см. Жава, С++.
Вы можете считать это болотом, но эта кочка зрения (tm) не выглядит обоснованной. Мейнстрим уходит в обеспечение значительно более широкого набора потребностей, чем нишевый продукт, в более разнообразных условиях. Но это никак не означает невозможность качественной специализации под конкретную реализацию.
N>>OK, когда будут множественные входные очереди на процесс?
SD>Сначала нужно объяснить, зачем. Один из патчей, который я сделал, как раз подобная поддержка (в слегка упрощенном виде, т.н. prepend send, послать сообщение в голову очереди). Но чем больше я занимаюсь архитектурой и более серьезным пониманием происходящих процессов, тем больше я понимаю, как был неправ. Просто на тот момент, когда я это сделал, у меня не было достаточно знаний. Сейчас эти знания есть, и я понимаю, что и prepend send, и "множественные очереди", и priority queues — это ошибочные направления. Но, повторюсь, чтобы это понять, нужно действительно провести много времени за изучением этих проблем.
Ну в таком случае выдайте на-гора, пожалуйста, хоть немного этой мудрости (в хорошем смысле), почему это "ошибочное направление". А то то, что я вижу, пока что подтверждает важность подхода.
Вот например RabbitMQ борется с такой проблемой:
| цитата | |
(там где-то есть ещё и игнорирование этих tcp reply, не буду искать сейчас) | |
Опишите, пожалуйста, вашу точку зрения на их решение, одним из следующих вариантов (допустимы мелкие поправки):
1. Да, ребята молодцы, что для решения проблемы они полезли в обход аж двух слоёв стандартной библиотеки (gen_tcp и prim_inet), рискуя несовместимостью с будущими реализациями, так и надо. MQ много, OTP одна. Пусть страдают при переходе, не наше дело.
2. Нет, надо было искать чудо и делать, чтобы очередь никогда не превышала K сообщений, где K < N. Как это делать — да хоть через ETS, которую наполняет другой процесс. Публичная ETS (потому что удаляет другой процесс, чем добавляет) не страшна, все свои.
3. Надо было сидеть и страдать. Нефиг тут неуправляемые входные потоки принимать на процесс. TCP приёмник нормально контролирует, а заторы возникают по дороге? Пофиг, у меня всё работает (tm).
4. Вы неверно понимаете задачу и вообще у вас плохой дзен, становитесь ёжиками. Детали не интересуют, я стратегию разрабатываю.
5. Иное (интересно, что?)
N>>С какой версии это стало нормально работать? Я после 2015 не смотрел, до этого коллеги пробовали — не работало.
SD>В следующий раз посоветуй коллегам разобраться. Оно работало всегда. Могло не хватать каких-то инструментов для удобства. Но systools были еще с 90х годов.
Я именно про rebar. Где-то с 2012 вместо прежних подходов, когда народ достаточно любовно настраивал обстановку и был готов к тому, что система должна работать 24*365, пошли новые подходы типа
1) Пакуем всё в один тарболл вместе с рантаймом, зависимостями и рабочим кодом
2) Всей задачи девопам — развернуть на сервере и запустить
3) Прерывание сервиса? Если волнует, переедут на соседние узлы, если нет — и так пофиг
4) Завернём это ещё и в докер, нефиг тратить время на тюнинг внешних компонентов
5) failover, takeover, relup? Дядя, ты с кем сейчас разговаривал? У нас свои средства кластеризации и надёжности в кластере (90% — просто общая SQL база).
и именно к этому подходу rebar подошёл идеально и стал основным инструментом.
И на него тогда даже смотрели "а он сможет обеспечить нормальный relup на месте, без рестарта, при своей паковке?" и на версиях тех времён однозначно не сложилось.
N>>Основное было системой мониторинга кластера "Ломоносов". Её у нас забрали прямо в процессе затыкания этих проблем
SD>Вот в это я могу поверить — что в силу политических причин ("забрали проект") у кого-то образовалось неприятие к инструментам, которыми попросту не научились пользоваться.
Нет, для себя мы её решили — костылями различной кривости. На продуктин оно не ушло — или ушло, не знаем — но это уже стало не нашей заботой.
N>>А тут она ещё и грубо неверна. Когда проект начинался, мы взяли в контору группу военных админов(!) и они успешно за срок менее месяца переключились на проектирование и написание (при том, что часть ещё и не имела опыта программирования кроме одноэкранных скриптов баша) — и всё шло замечательно до тех пор, пока под реальной нагрузкой не начались уже характерно эрланговые проблемы, как минимум:
SD>Прям-таки классика жанра! Когда я написал "нельзя набрать обезьян" — я ровно это и имел в виду. Дело в том, что синтаксис и "первые шаги" на Эрланге до одури просты. И потому возникает ощущение "мы все поняли и все умеем". Но когда дело доходит до написания реального софта, оказывается, что кроме синтаксиса нужно еще... понять, что такое OTP, и как на самом деле надо пользоваться языком. Вы, однако, так и не поняли. Посему и проблемы, перечисленые ниже. Как раз отражение непонимания, как должна работать система.
Спасибо за извинения за "обезьян" (в соседнем сообщении), повторюсь, что именно эта группа не имеет отношения к проблемам перегрузки. Проблемы же возникали в следующей обстановке:
1. Приложение NA принимает входной поток (его плотность... ну давайте для простоты остановимся на цифре 10K сообщений в секунду) из толпы разных источников (можно распределять между экземплярами приложения на разных узлах). Но сообщение групповое, содержит ~50 вложенных других, и реально обрабатывается 500K. При первичной обработке поток сокращается в ~5 раз, получается 100K mps. Одно сообщение со всеми деталями это, насколько помню, около 200 байт. Вроде бы поток небольшой.
2. Поток выходных сообщений из NA отправляется на несколько приёмников, для простоты скажем про 2: генератор первичных логических выводов (NMU) и логгер. Реально между ними сидит ещё приложение шины.
3. NMU делает первичные выводы и посылает их на шину 2. Там свои логгер и групповая логика.
4. Приложение групповой логики (GL) делает выводы уже финальные — типа "стойка 123 недопустимо перегрета, надо выключать оборудование".
В спокойной обстановке на участке NMU — GL поток сообщений в десятки раз меньше входного потока NMU (то есть тысячи, если не сотни, в секунду, уровня "тут всё спокойно, тангаж, крен, рысканье в норме, температура 36.6"), при проблемах — может подскакивать до равного потока (считаем, те же 100K mps). Работа при пиковой нагрузке, соответственно, критична (должно быть всё гладко-линейно и должен ещё быть запас производительности).
Реально частично работало горизонтальное деление — NC, NMU, часть GL просто горизонтально масштабировалась. Но уже участок — вершина GL, и всё, что за ним — регистратор алармов, логгеры этой части, генератор команд по выводам GL (типа, уже надо грубо выключать ток) — не масштабируются. У получателя, типа регистратора, один отправитель. Не 100500 отдельных мелких, каждый из которых послал какое-нибудь "GET /zuka HTTP/1.1", а один, и он не ждёт — посылает следующие.
И вот тут начинается, что любой из процессов — приёмников потока:
1) Если он делает только обработку входящих сообщений и асинхронные посылки другим — живёт. (На самом деле чуть сложнее — иногда получалось, что и в этом случае начиналось торможение. Но этот вопрос на потом.)
2) Если ему хоть иногда надо делать синхронные вызовы (gen_server:call) и соответственно сразу ждать отвёт — всё, суши вёсла: из накопления входной очереди выше 10-20K сообщений он не способен уже выйти. Граница неточная, но, похоже, связана с размером кэша процессора. Само же временное переполнение, безвредное в других условиях,
3) Даже если он сам не делает синхронные вызовы, задача оперативно получить состояние, не блокируя запрашивающего на недопустимый срок (1 секунда уже предел), не выполняется — пока прорабатываются остальные, {'$call',запрос} стоит в конце очереди.
Вот теперь я хочу послушать Ваши предложения по исправлению этих проблем в пределах текущих возможностей Erlang.
N>>1) Переполнение входных очередей без возможности адекватного взаимодействия с пострадавшими процессами; лечилось грубыми хаками типа просовывания управляющих команд через ETS с соседним процессом;
SD>Иными словами, не смогли правильно реализовать backpressure.
Нет. Backpressure вообще недопустим на участке как минимум после NMU. Есть некоторый уровень нагрузки, который в ламинарном состоянии это весьма мелкая доля от того, что может осилить железо и рантайм. Но это в ламинарном. Как только где-то перегрузка, Erlang не даёт восстановиться.
В том решении, которое было испытано локально, но не дошло до целевой эксплуатации, было сделано, что при детекте перегрузки NMU приостанавливает отдачу разрешений посылки сообщений исходным агентам. Но даже это пришлось решать немного хакерски, ну и сама постановка вопроса означала, что система не справляется с задачей — состояние должно сниматься не реже раза в секунду.
SD> Справедливости ради, это действительно holy grail асинхронного программирования, и по сути нормально нигде и не реализовано. Да, есть теоретические измышления (SEDA та же) и кое-какие реализации (а ля GenStage), но чтоб серьезно к этому делу подойти, — пока руки не дошли. На данный момент все в стадии написания whitepaper.
Меня тут не интересуют дискуссии о теоретических основах. Остановить агентов мы были в состоянии. Реально они сами останавливались, не получив команды "даю разрешение на 5 отчётов". Меня интересует именно устойчивость реакции на перегрузку.
N>>2) Страшно тормозной global, с синхронизацией, страдающей при перегрузке (попросту кластер рассыпался — и это при несчастных ~30 узлах); сейчас, по слухам, есть настройка "межкластерные данные идут по другим каналам, чем heartbeats", я не успел это сделать — выдернули на живую.
SD>Сейчас global попросту не нужен (как он не был нужен и раньше). Если нужны process groups, они уже есть (и нет, не pg2, которые работали поверх global). В общем, то, что вы не смогли кластер из 30+ машин поднять, так я про то и пишу — надо было разработчиков высокой квалификации брать. Тогда и 20.000 машин в кластере не были бы проблемой, и даже 30.000 (больше просто пока не требовалось).
И снова домыслы и критика "обезьян". Но это я отложу на следующий заход.
N>>Были и другие, поменьше, но облом вспоминать (попросишь — подниму архивы).
SD>Нет смысла. Я уже понимаю, что не тот уровень знаний.
Нет, это ваш уровень верхоглядства и наплевательства. Я надеюсь, что вы его таки переборете, иначе точно нет смысла обсуждать с вами эти проблемы.
N>>Эти проблемы я обсуждал с Валкиным, Лапшиным, Димандтом
SD>А надо было обсуждать с Lukas Larsson, Kenneth Lundin, Rickard Green, Sverker Eriksson, Kjell Winnblad. Круг, действительно, узок, и он не включает ни одной из указанных выше фамилий.
Общением с кем-то из core team занимались другие коллеги. Успеха не добились.
Re[11]: WA: 3 млн tcp соединений на одном сервере
Здравствуйте, SkyDance, Вы писали:
N>>Баги — исправляются. А вот принципиальная тормознутость рантайма — с ней сильно сложнее.
SD>Я так понимаю, "принципиальная тормознутость" рассматривается ниже (с конкретными проблемами). Или есть еще что-то еще? Кроме заявлений про "тормознутость", чтобы было нечто осмысленное. А то я вижу, что "тормознутость" — это 50.000 юзеров на машину в кластере (средней руки мессенджер на жаве) и 500.000 на такую же машину (на Эрланге).
В случае Java, я думаю, сделано просто какого-то явно лишнего кода. Или в условиях очень коротких сработок на один клиентский запрос с длительными ожиданиями между ними — сделана какая-нибудь глупость типа персональной нити на каждого клиента. Иначе бы такой суровой разницы не было.
Но это надо смотреть реализацию в деталях: что делается и как.
N>>Да. Только надо перестать смотреть на это как на "переизобретение эрланга". Даже если Erlang был одно время образцом, то все эти реализации уже давно ушли дальше.
SD>Это и есть переизобретение эрланга. "Эти реализации" ушли не дальше, а в болото. Как туда уходит любой мейнстрим, см. Жава, С++.
Вы можете считать это болотом, но эта кочка зрения (tm) не выглядит обоснованной. Мейнстрим уходит в обеспечение значительно более широкого набора потребностей, чем нишевый продукт, в более разнообразных условиях. Но это никак не означает невозможность качественной специализации под конкретную реализацию.
N>>OK, когда будут множественные входные очереди на процесс?
SD>Сначала нужно объяснить, зачем. Один из патчей, который я сделал, как раз подобная поддержка (в слегка упрощенном виде, т.н. prepend send, послать сообщение в голову очереди). Но чем больше я занимаюсь архитектурой и более серьезным пониманием происходящих процессов, тем больше я понимаю, как был неправ. Просто на тот момент, когда я это сделал, у меня не было достаточно знаний. Сейчас эти знания есть, и я понимаю, что и prepend send, и "множественные очереди", и priority queues — это ошибочные направления. Но, повторюсь, чтобы это понять, нужно действительно провести много времени за изучением этих проблем.
Ну в таком случае выдайте на-гора, пожалуйста, хоть немного этой мудрости (в хорошем смысле), почему это "ошибочное направление". А то то, что я вижу, пока что подтверждает важность подхода.
Вот например RabbitMQ борется с такой проблемой:
Опишите, пожалуйста, вашу точку зрения на их решение, одним из следующих вариантов (допустимы мелкие поправки):
1. Да, ребята молодцы, что для решения проблемы они полезли в обход аж двух слоёв стандартной библиотеки (gen_tcp и prim_inet), рискуя несовместимостью с будущими реализациями, так и надо. MQ много, OTP одна. Пусть страдают при переходе, не наше дело.
2. Нет, надо было искать чудо и делать, чтобы очередь никогда не превышала K сообщений, где K < N. Как это делать — да хоть через ETS, которую наполняет другой процесс. Публичная ETS (потому что удаляет другой процесс, чем добавляет) не страшна, все свои.
3. Надо было сидеть и страдать. Нефиг тут неуправляемые входные потоки принимать на процесс. TCP приёмник нормально контролирует, а заторы возникают по дороге? Пофиг, у меня всё работает (tm).
4. Вы неверно понимаете задачу и вообще у вас плохой дзен, становитесь ёжиками. Детали не интересуют, я стратегию разрабатываю.
5. Иное (интересно, что?)
N>>С какой версии это стало нормально работать? Я после 2015 не смотрел, до этого коллеги пробовали — не работало.
SD>В следующий раз посоветуй коллегам разобраться. Оно работало всегда. Могло не хватать каких-то инструментов для удобства. Но systools были еще с 90х годов.
Я именно про rebar. Где-то с 2012 вместо прежних подходов, когда народ достаточно любовно настраивал обстановку и был готов к тому, что система должна работать 24*365, пошли новые подходы типа
1) Пакуем всё в один тарболл вместе с рантаймом, зависимостями и рабочим кодом
2) Всей задачи девопам — развернуть на сервере и запустить
3) Прерывание сервиса? Если волнует, переедут на соседние узлы, если нет — и так пофиг
4) Завернём это ещё и в докер, нефиг тратить время на тюнинг внешних компонентов
5) failover, takeover, relup? Дядя, ты с кем сейчас разговаривал? У нас свои средства кластеризации и надёжности в кластере (90% — просто общая SQL база).
и именно к этому подходу rebar подошёл идеально и стал основным инструментом.
И на него тогда даже смотрели "а он сможет обеспечить нормальный relup на месте, без рестарта, при своей паковке?" и на версиях тех времён однозначно не сложилось.
N>>Основное было системой мониторинга кластера "Ломоносов". Её у нас забрали прямо в процессе затыкания этих проблем
SD>Вот в это я могу поверить — что в силу политических причин ("забрали проект") у кого-то образовалось неприятие к инструментам, которыми попросту не научились пользоваться.
Нет, для себя мы её решили — костылями различной кривости. На продуктин оно не ушло — или ушло, не знаем — но это уже стало не нашей заботой.
N>>А тут она ещё и грубо неверна. Когда проект начинался, мы взяли в контору группу военных админов(!) и они успешно за срок менее месяца переключились на проектирование и написание (при том, что часть ещё и не имела опыта программирования кроме одноэкранных скриптов баша) — и всё шло замечательно до тех пор, пока под реальной нагрузкой не начались уже характерно эрланговые проблемы, как минимум:
SD>Прям-таки классика жанра! Когда я написал "нельзя набрать обезьян" — я ровно это и имел в виду. Дело в том, что синтаксис и "первые шаги" на Эрланге до одури просты. И потому возникает ощущение "мы все поняли и все умеем". Но когда дело доходит до написания реального софта, оказывается, что кроме синтаксиса нужно еще... понять, что такое OTP, и как на самом деле надо пользоваться языком. Вы, однако, так и не поняли. Посему и проблемы, перечисленые ниже. Как раз отражение непонимания, как должна работать система.
Спасибо за извинения за "обезьян" (в соседнем сообщении), повторюсь, что именно эта группа не имеет отношения к проблемам перегрузки. Проблемы же возникали в следующей обстановке:
1. Приложение NA принимает входной поток (его плотность... ну давайте для простоты остановимся на цифре 10K сообщений в секунду) из толпы разных источников (можно распределять между экземплярами приложения на разных узлах). Но сообщение групповое, содержит ~50 вложенных других, и реально обрабатывается 500K. При первичной обработке поток сокращается в ~5 раз, получается 100K mps. Одно сообщение со всеми деталями это, насколько помню, около 200 байт. Вроде бы поток небольшой.
2. Поток выходных сообщений из NA отправляется на несколько приёмников, для простоты скажем про 2: генератор первичных логических выводов (NMU) и логгер. Реально между ними сидит ещё приложение шины (приняло и перепостило подписчикам).
3. NMU делает первичные выводы и посылает их на шину 2. Там свои логгер и групповая логика.
4. Приложение групповой логики (GL) делает выводы уже финальные — типа "стойка 123 недопустимо перегрета, надо выключать оборудование".
В спокойной обстановке на участке NMU — GL поток сообщений в десятки раз меньше входного потока NMU (то есть тысячи, если не сотни, в секунду, уровня "тут всё спокойно, тангаж, крен, рысканье в норме, температура 36.6"), при проблемах — может подскакивать до равного потока (считаем, те же 100K mps). Работа при пиковой нагрузке, соответственно, критична (должно быть всё гладко-линейно и должен ещё быть запас производительности).
Реально частично работало горизонтальное деление — NC, NMU, часть GL просто горизонтально масштабировалась. Но уже участок — вершина GL, и всё, что за ним — регистратор алармов, логгеры этой части, генератор команд по выводам GL (типа, уже надо грубо выключать ток) — не масштабируются. У получателя, типа регистратора, один отправитель. Не 100500 отдельных мелких, каждый из которых послал какое-нибудь "GET /zuka HTTP/1.1", а один, и он не ждёт — посылает следующие.
И вот тут начинается, что любой из процессов — приёмников потока:
1) Если он делает только обработку входящих сообщений и асинхронные посылки другим — живёт. (На самом деле чуть сложнее — иногда получалось, что и в этом случае начиналось торможение. Но этот вопрос на потом.)
2) Если ему хоть иногда надо делать синхронные вызовы (gen_server:call) и соответственно сразу ждать отвёт — всё, суши вёсла: из накопления входной очереди выше 10-20K сообщений он не способен уже выйти. Граница неточная, но, похоже, связана с размером кэша процессора. Временное переполнение, безвредное в других условиях, становится фатальным (надо только рубить процесс).
3) Даже если он сам не делает синхронные вызовы, задача оперативно получить состояние, не блокируя запрашивающего на недопустимый срок (1 секунда уже предел), не выполняется — пока прорабатываются остальные, {'$call',запрос} стоит в конце очереди.
Вот теперь я хочу послушать Ваши предложения по исправлению этих проблем в пределах текущих возможностей Erlang.
N>>1) Переполнение входных очередей без возможности адекватного взаимодействия с пострадавшими процессами; лечилось грубыми хаками типа просовывания управляющих команд через ETS с соседним процессом;
SD>Иными словами, не смогли правильно реализовать backpressure.
Нет. Backpressure вообще недопустим на участке как минимум после NMU. Есть некоторый уровень нагрузки, который в ламинарном состоянии это весьма мелкая доля от того, что может осилить железо и рантайм. Но это в ламинарном. Как только где-то перегрузка, Erlang не даёт восстановиться.
В том решении, которое было испытано локально, но не дошло до целевой эксплуатации, было сделано, что при детекте перегрузки NMU приостанавливает отдачу разрешений посылки сообщений исходным агентам. (Ну и темп регулировался, понятно, общими настройками.) Но даже это пришлось решать немного хакерски, ну и сама постановка вопроса означала, что система не справляется с задачей — состояние должно сниматься не реже раза в секунду, и не теряться.
SD> Справедливости ради, это действительно holy grail асинхронного программирования, и по сути нормально нигде и не реализовано. Да, есть теоретические измышления (SEDA та же) и кое-какие реализации (а ля GenStage), но чтоб серьезно к этому делу подойти, — пока руки не дошли. На данный момент все в стадии написания whitepaper.
Меня тут не интересуют дискуссии о теоретических основах. Остановить агентов мы были в состоянии. Реально они сами останавливались, не получив команды "даю разрешение на 5 отчётов". Меня интересует именно устойчивость реакции на перегрузку. В идеале, пока нет других проблем типа переполнения по памяти, ему должна была быть пофиг длина очереди, хоть миллиард.
N>>2) Страшно тормозной global, с синхронизацией, страдающей при перегрузке (попросту кластер рассыпался — и это при несчастных ~30 узлах); сейчас, по слухам, есть настройка "межкластерные данные идут по другим каналам, чем heartbeats", я не успел это сделать — выдернули на живую.
SD>Сейчас global попросту не нужен (как он не был нужен и раньше). Если нужны process groups, они уже есть (и нет, не pg2, которые работали поверх global). В общем, то, что вы не смогли кластер из 30+ машин поднять, так я про то и пишу — надо было разработчиков высокой квалификации брать. Тогда и 20.000 машин в кластере не были бы проблемой, и даже 30.000 (больше просто пока не требовалось).
И снова домыслы и критика "обезьян". Но это я отложу на следующий заход.
N>>Были и другие, поменьше, но облом вспоминать (попросишь — подниму архивы).
SD>Нет смысла. Я уже понимаю, что не тот уровень знаний.
Нет, это ваш уровень верхоглядства и наплевательства. Я надеюсь, что вы его таки переборете, иначе точно нет смысла обсуждать с вами эти проблемы.
N>>Эти проблемы я обсуждал с Валкиным, Лапшиным, Димандтом
SD>А надо было обсуждать с Lukas Larsson, Kenneth Lundin, Rickard Green, Sverker Eriksson, Kjell Winnblad. Круг, действительно, узок, и он не включает ни одной из указанных выше фамилий.
Общением с кем-то из core team занимались другие коллеги. Успеха не добились.
N>>Баги — исправляются. А вот принципиальная тормознутость рантайма — с ней сильно сложнее.
SD>Я так понимаю, "принципиальная тормознутость" рассматривается ниже (с конкретными проблемами). Или есть еще что-то еще? Кроме заявлений про "тормознутость", чтобы было нечто осмысленное. А то я вижу, что "тормознутость" — это 50.000 юзеров на машину в кластере (средней руки мессенджер на жаве) и 500.000 на такую же машину (на Эрланге).
В случае Java, я думаю, сделано просто какого-то явно лишнего кода. Или в условиях очень коротких сработок на один клиентский запрос с длительными ожиданиями между ними — сделана какая-нибудь глупость типа персональной нити на каждого клиента. Иначе бы такой суровой разницы не было.
Но это надо смотреть реализацию в деталях: что делается и как.
N>>Да. Только надо перестать смотреть на это как на "переизобретение эрланга". Даже если Erlang был одно время образцом, то все эти реализации уже давно ушли дальше.
SD>Это и есть переизобретение эрланга. "Эти реализации" ушли не дальше, а в болото. Как туда уходит любой мейнстрим, см. Жава, С++.
Вы можете считать это болотом, но эта кочка зрения (tm) не выглядит обоснованной. Мейнстрим уходит в обеспечение значительно более широкого набора потребностей, чем нишевый продукт, в более разнообразных условиях. Но это никак не означает невозможность качественной специализации под конкретную реализацию.
N>>OK, когда будут множественные входные очереди на процесс?
SD>Сначала нужно объяснить, зачем. Один из патчей, который я сделал, как раз подобная поддержка (в слегка упрощенном виде, т.н. prepend send, послать сообщение в голову очереди). Но чем больше я занимаюсь архитектурой и более серьезным пониманием происходящих процессов, тем больше я понимаю, как был неправ. Просто на тот момент, когда я это сделал, у меня не было достаточно знаний. Сейчас эти знания есть, и я понимаю, что и prepend send, и "множественные очереди", и priority queues — это ошибочные направления. Но, повторюсь, чтобы это понять, нужно действительно провести много времени за изучением этих проблем.
Ну в таком случае выдайте на-гора, пожалуйста, хоть немного этой мудрости (в хорошем смысле), почему это "ошибочное направление". А то то, что я вижу, пока что подтверждает важность подхода.
Вот например RabbitMQ борется с такой проблемой:
| цитата | |
(там где-то есть ещё и игнорирование этих tcp reply, не буду искать сейчас) | |
Опишите, пожалуйста, вашу точку зрения на их решение, одним из следующих вариантов (допустимы мелкие поправки):
1. Да, ребята молодцы, что для решения проблемы они полезли в обход аж двух слоёв стандартной библиотеки (gen_tcp и prim_inet), рискуя несовместимостью с будущими реализациями, так и надо. MQ много, OTP одна. Пусть страдают при переходе, не наше дело.
2. Нет, надо было искать чудо и делать, чтобы очередь никогда не превышала K сообщений, где K < N. Как это делать — да хоть через ETS, которую наполняет другой процесс. Публичная ETS (потому что удаляет другой процесс, чем добавляет) не страшна, все свои.
3. Надо было сидеть и страдать. Нефиг тут неуправляемые входные потоки принимать на процесс. TCP приёмник нормально контролирует, а заторы возникают по дороге? Пофиг, у меня всё работает (tm).
4. Вы неверно понимаете задачу и вообще у вас плохой дзен, становитесь ёжиками. Детали не интересуют, я стратегию разрабатываю.
5. Иное (интересно, что?)
N>>С какой версии это стало нормально работать? Я после 2015 не смотрел, до этого коллеги пробовали — не работало.
SD>В следующий раз посоветуй коллегам разобраться. Оно работало всегда. Могло не хватать каких-то инструментов для удобства. Но systools были еще с 90х годов.
Я именно про rebar. Где-то с 2012 вместо прежних подходов, когда народ достаточно любовно настраивал обстановку и был готов к тому, что система должна работать 24*365, пошли новые подходы типа
1) Пакуем всё в один тарболл вместе с рантаймом, зависимостями и рабочим кодом
2) Всей задачи девопам — развернуть на сервере и запустить
3) Прерывание сервиса? Если волнует, переедут на соседние узлы, если нет — и так пофиг
4) Завернём это ещё и в докер, нефиг тратить время на тюнинг внешних компонентов
5) failover, takeover, relup? Дядя, ты с кем сейчас разговаривал? У нас свои средства кластеризации и надёжности в кластере (90% — просто общая SQL база).
и именно к этому подходу rebar подошёл идеально и стал основным инструментом.
И на него тогда даже смотрели "а он сможет обеспечить нормальный relup на месте, без рестарта, при своей паковке?" и на версиях тех времён однозначно не сложилось.
N>>Основное было системой мониторинга кластера "Ломоносов". Её у нас забрали прямо в процессе затыкания этих проблем
SD>Вот в это я могу поверить — что в силу политических причин ("забрали проект") у кого-то образовалось неприятие к инструментам, которыми попросту не научились пользоваться.
Нет, для себя мы её решили — костылями различной кривости. На продуктин оно не ушло — или ушло, не знаем — но это уже стало не нашей заботой.
N>>А тут она ещё и грубо неверна. Когда проект начинался, мы взяли в контору группу военных админов(!) и они успешно за срок менее месяца переключились на проектирование и написание (при том, что часть ещё и не имела опыта программирования кроме одноэкранных скриптов баша) — и всё шло замечательно до тех пор, пока под реальной нагрузкой не начались уже характерно эрланговые проблемы, как минимум:
SD>Прям-таки классика жанра! Когда я написал "нельзя набрать обезьян" — я ровно это и имел в виду. Дело в том, что синтаксис и "первые шаги" на Эрланге до одури просты. И потому возникает ощущение "мы все поняли и все умеем". Но когда дело доходит до написания реального софта, оказывается, что кроме синтаксиса нужно еще... понять, что такое OTP, и как на самом деле надо пользоваться языком. Вы, однако, так и не поняли. Посему и проблемы, перечисленые ниже. Как раз отражение непонимания, как должна работать система.
Спасибо за извинения за "обезьян" (в соседнем сообщении), повторюсь, что именно эта группа не имеет отношения к проблемам перегрузки. Проблемы же возникали в следующей обстановке:
1. Приложение NA принимает входной поток (его плотность... ну давайте для простоты остановимся на цифре 10K сообщений в секунду) из толпы разных источников (можно распределять между экземплярами приложения на разных узлах). Но сообщение групповое, содержит ~50 вложенных других, и реально обрабатывается 500K. При первичной обработке поток сокращается в ~5 раз, получается 100K mps. Одно сообщение со всеми деталями это, насколько помню, около 200 байт. Вроде бы поток небольшой.
2. Поток выходных сообщений из NA отправляется на несколько приёмников, для простоты скажем про 2: генератор первичных логических выводов (NMU) и логгер. Реально между ними сидит ещё приложение шины (приняло и перепостило подписчикам).
3. NMU делает первичные выводы и посылает их на шину 2. Там свои логгер и групповая логика.
4. Приложение групповой логики (GL) делает выводы уже финальные — типа "стойка 123 недопустимо перегрета, надо выключать оборудование".
В спокойной обстановке на участке NMU — GL поток сообщений в десятки раз меньше входного потока NMU (то есть тысячи, если не сотни, в секунду, уровня "тут всё спокойно, тангаж, крен, рысканье в норме, температура 36.6"), при проблемах — может подскакивать до равного потока (считаем, те же 100K mps). Работа при пиковой нагрузке, соответственно, критична (должно быть всё гладко-линейно и должен ещё быть запас производительности).
Реально частично работало горизонтальное деление — NC, NMU, часть GL просто горизонтально масштабировалась. Но уже участок — вершина GL, и всё, что за ним — регистратор алармов, логгеры этой части, генератор команд по выводам GL (типа, уже надо грубо выключать ток) — не масштабируются. У получателя, типа регистратора, один отправитель. Не 100500 отдельных мелких, каждый из которых послал какое-нибудь "GET /zuka HTTP/1.1", а один, и он не ждёт — посылает следующие.
И вот тут начинается, что любой из процессов — приёмников потока:
1) Если он делает только обработку входящих сообщений и асинхронные посылки другим — живёт. (На самом деле чуть сложнее — иногда получалось, что и в этом случае начиналось торможение. Но этот вопрос на потом.)
2) Если ему хоть иногда надо делать синхронные вызовы (gen_server:call) и соответственно сразу ждать отвёт — всё, суши вёсла: из накопления входной очереди выше 10-20K сообщений он не способен уже выйти. Граница неточная, но, похоже, связана с размером кэша процессора. Временное переполнение, безвредное в других условиях, становится фатальным (надо только рубить процесс).
3) Даже если он сам не делает синхронные вызовы, задача оперативно получить состояние, не блокируя запрашивающего на недопустимый срок (1 секунда уже предел), не выполняется — пока прорабатываются остальные, {'$call',запрос} стоит в конце очереди.
Вот теперь я хочу послушать Ваши предложения по исправлению этих проблем в пределах текущих возможностей Erlang.
N>>1) Переполнение входных очередей без возможности адекватного взаимодействия с пострадавшими процессами; лечилось грубыми хаками типа просовывания управляющих команд через ETS с соседним процессом;
SD>Иными словами, не смогли правильно реализовать backpressure.
Нет. Backpressure вообще недопустим на участке как минимум после NMU. Есть некоторый уровень нагрузки, который в ламинарном состоянии это весьма мелкая доля от того, что может осилить железо и рантайм. Но это в ламинарном. Как только где-то перегрузка, Erlang не даёт восстановиться.
В том решении, которое было испытано локально, но не дошло до целевой эксплуатации, было сделано, что при детекте перегрузки NMU приостанавливает отдачу разрешений посылки сообщений исходным агентам. (Ну и темп регулировался, понятно, общими настройками.) Но даже это пришлось решать немного хакерски, ну и сама постановка вопроса означала, что система не справляется с задачей — состояние должно сниматься не реже раза в секунду, и не теряться.
SD> Справедливости ради, это действительно holy grail асинхронного программирования, и по сути нормально нигде и не реализовано. Да, есть теоретические измышления (SEDA та же) и кое-какие реализации (а ля GenStage), но чтоб серьезно к этому делу подойти, — пока руки не дошли. На данный момент все в стадии написания whitepaper.
Меня тут не интересуют дискуссии о теоретических основах. Остановить агентов мы были в состоянии. Реально они сами останавливались, не получив команды "даю разрешение на 5 отчётов". Меня интересует именно устойчивость реакции на перегрузку. В идеале, пока нет других проблем типа переполнения по памяти, ему должна была быть пофиг длина очереди, хоть миллиард.
N>>2) Страшно тормозной global, с синхронизацией, страдающей при перегрузке (попросту кластер рассыпался — и это при несчастных ~30 узлах); сейчас, по слухам, есть настройка "межкластерные данные идут по другим каналам, чем heartbeats", я не успел это сделать — выдернули на живую.
SD>Сейчас global попросту не нужен (как он не был нужен и раньше). Если нужны process groups, они уже есть (и нет, не pg2, которые работали поверх global). В общем, то, что вы не смогли кластер из 30+ машин поднять, так я про то и пишу — надо было разработчиков высокой квалификации брать. Тогда и 20.000 машин в кластере не были бы проблемой, и даже 30.000 (больше просто пока не требовалось).
И снова домыслы и критика "обезьян". Но это я отложу на следующий заход.
N>>Были и другие, поменьше, но облом вспоминать (попросишь — подниму архивы).
SD>Нет смысла. Я уже понимаю, что не тот уровень знаний.
Нет, это ваш уровень верхоглядства и наплевательства. Я надеюсь, что вы его таки переборете, иначе точно нет смысла обсуждать с вами эти проблемы.
N>>Эти проблемы я обсуждал с Валкиным, Лапшиным, Димандтом
SD>А надо было обсуждать с Lukas Larsson, Kenneth Lundin, Rickard Green, Sverker Eriksson, Kjell Winnblad. Круг, действительно, узок, и он не включает ни одной из указанных выше фамилий.
Общением с кем-то из core team занимались другие коллеги. Успеха не добились.