i
А чем мощнее проц, тем context switching еще и дороже становится
Size: a a a
2020 May 16
i
То есть в подобной ситуации более мощная машина сделает хуже
SM
Хз, размазать по нодам, и может не так печаально будет
i
Это да, конечно, но подобных камней подводных может быть немало, это я один привел
i
К тому, что лучше под ingress отдать отдельные машины
SM
В твоем кейсе один хрен такой софт нужно на отдельные ноды уносить
SM
Да, мысль понял, будем подумать
i
Чтобы точно его исключить из влияния кого-то
SM
У меня там пока один проект, так что пока по.уй %]
i
Ну я вот на своих проектах под ингресс отдаю пару t3.medium на aws, этого хватает чтобы переварить несколько тысяч rps, сам по себе nginx-то не ест особо
SM
Да, но лишние хопы на ровном месте тоже такое себе
i
У тебя что так, что так через nginx будет проходить
AY
А чем мощнее проц, тем context switching еще и дороже становится
Алерты ставить на context switch обязательно. Где-то были готовые на Prometheus, оттуда это раскопал.
i
Алерты ставить на context switch обязательно. Где-то были готовые на Prometheus, оттуда это раскопал.
Так это понятно
AY
У нас очень много любителей взять жирный серв и стартануть там овер дофига процессов на все 😀 в рф
AY
Алерты ставить на context switch обязательно. Где-то были готовые на Prometheus, оттуда это раскопал.
i
Только когда алерт заалертит, у тебя уже ингресс на той же ноде не работает по факту
i
А обслуживать он может и 100 приложений и страдают все
i
Поэтому во избежание - входная точка для трафика отделяется от основных ворклоадов
AY
Я же не спорю. У меня так. Нагрузок нет, но так проще балансёр натравить на группу нод в облаке