Комментарии 9
Мне кажется с пикчами перебор :\ Может стоило остановиться на какой то одной?
Для "поделиться опытом" мало обобщений. Вы рассказали, как конкретное приложение конкретно пилили. Для личного опыта может быть хорошо, для помощи другим - 0.
И очень, очень много велосипедов (сделай сам). Я понимаю, что могут быть причины, но тогда их хотя бы надо декларировать.
Для меня сервер это как минимум xeon'чик и 128гб озу, у вас древние сервера или платформа с миллионом пользователей ? что за система которая постоянно ложится от нехватки ?
ps. Картинок много, но про пингвина поржал =)
Добрый день, Автор !
Статья безусловно интересная, но хотелось бы например узнать, как вы построили кластер Postgres (сколько нод, какое ПО) ? почему именно выбрали эту реализацию ?
Как было описано выше, у нас 3 ноды и трансирование журнала WAL. Выбрали этот метод из за большой надежности и простоты в эксплуатации) Подробнее написали ребята из Postgres Pro, https://postgrespro.ru/docs/postgrespro/10/warm-standby
С настоящими пользователями они начали отъедать много памяти. Тут стоит громко сказать: «не верьте официальной доке gunicorn!». Количество воркеров нужно ставить в зависимости от вашего приложения и проведенных тестов, а не на основе формулы которая дана в доке.
А теперь заходим в документацию (https://docs.gunicorn.org/en/stable/design.html) и читаем:
DO NOT scale the number of workers to the number of clients you expect to have. Gunicorn should only need 4-12 worker processes to handle hundreds or thousands of requests per second.
Gunicorn relies on the operating system to provide all of the load balancing when handling requests. Generally we recommend
(2 x $num_cores) + 1as the number of workers to start off with. While not overly scientific, the formula is based on the assumption that for a given core, one worker will be reading or writing from the socket while the other worker is processing a request.Obviously, your particular hardware and application are going to affect the optimal number of workers. Our recommendation is to start with the above guess and tune using TTIN and TTOU signals while the application is under load.
Always remember, there is such a thing as too many workers. After a point your worker processes will start thrashing system resources decreasing the throughput of the entire system.
Что мы видим? В документации, ясно указывается, что формулу надо использовать как отправную точку, но в зависимости от типа нагрузки и профиля использования (CPU Bound vs IO Bound, long-polling и т.д.) нужно выставлять данные параметры самому. Нету универсального способа. И в самом начале указывается, что в целом достаточно иметь 4-12 воркеров, и что ненужно иметь их много.
До ansible мы использовали обычный скрипт, который выкатывал нужные изменения на сервер из gitlab ci/cd. С приходом нескольких серверов, которые нужно обновлять, такой подход уже не работал.
Что-то не совсем понятно. С появлением доп. серверов сложно было в в скрипте перед блоком деплоя написать: for srv in {1..n};do ... done и деплоить не на один а на все сервера?
В какой-то момент вы решите переезжать в kubernetes. Вот тогда у вас будет весело.
Как сменить архитектуру на проекте и начать спать