IK
Особенно хороша проверка типов тайпскриптом в рантайме между микросервисами
протобуф :)
Size: a a a
2021 February 08
PS
Особенно хороша проверка типов тайпскриптом в рантайме между микросервисами
есть пакеты для тс, которые делают рантайм проверки
DD
А как вы угадываете когда вам оом-киллер пришлет sigkill :)?
ну как бы настройки oom ставишь 2 gb.
Пишешь свой монитор, который ставишь на 1.5 GB и чтобы он вырубал сервис по хорошему. Если все же тот не хороший, то oom его прибьет по плохому
Пишешь свой монитор, который ставишь на 1.5 GB и чтобы он вырубал сервис по хорошему. Если все же тот не хороший, то oom его прибьет по плохому
𝔅К
Особенно хороша проверка типов тайпскриптом в рантайме между микросервисами
Которые общаются на графкьюэле?
A
process.on('SIGINT', handle);
process.on('SIGTERM', handle);
process.on('SIGTERM', handle);
ООМ-киллер на то и киллер, он предупредительных выстрелов не делает :), он делает SIGKILL и досвидос. Разве что ваша приложуха время от времени будет как самолет выстреливать ик-ловушки (писать неприлично большие значения в файлик oom_score_adj для фейкового процесса) и если еги пристрелят, то пора и основному процессу могилку рыть
АЗ
Особенно хороша проверка типов тайпскриптом в рантайме между микросервисами
толсто :D
A
ну как бы настройки oom ставишь 2 gb.
Пишешь свой монитор, который ставишь на 1.5 GB и чтобы он вырубал сервис по хорошему. Если все же тот не хороший, то oom его прибьет по плохому
Пишешь свой монитор, который ставишь на 1.5 GB и чтобы он вырубал сервис по хорошему. Если все же тот не хороший, то oom его прибьет по плохому
ООМ киллер выбирает жертву не только по тому сколько занимает памяти она. Приложуха может спокойно пасть его жертвой кушая и 1Гб.
DD
ООМ киллер выбирает жертву не только по тому сколько занимает памяти она. Приложуха может спокойно пасть его жертвой кушая и 1Гб.
Сорян, не силен в алгоритме работы oom в сgroups, но вообщем-то подход то верный, чи не так?
IK
в случае с cgroups у нас гораздо больше контроля для оценки memory pressure
A
Сорян, не силен в алгоритме работы oom в сgroups, но вообщем-то подход то верный, чи не так?
Верным был подход с "просто не делай так" (т.е. не писать борн-ту-дай программы/процессы).
IK
/sys/fs/cgroup/memory/memory.pressure_level как пример
DD
Верным был подход с "просто не делай так" (т.е. не писать борн-ту-дай программы/процессы).
ну как дев да, а если ты релиабилити инженер, и у тебя 100500 тим чет там пишут, ты в душе не чаешь умеют ли они писать.
A
ну как дев да, а если ты релиабилити инженер, и у тебя 100500 тим чет там пишут, ты в душе не чаешь умеют ли они писать.
То тогда тяжко ему прийдется. Ведь сожрать память можно и не самой программой непосредственно.
Например можно написать код, который засрет буфер какого-нибудь сетевого интерфейса и память улетит за пару секунд. А приложение себе преспокойно будет существовать.
Например можно написать код, который засрет буфер какого-нибудь сетевого интерфейса и память улетит за пару секунд. А приложение себе преспокойно будет существовать.
DD
а о чем мы спорим?
1. надо ли писать мемори лики - нет
2. надо ли защитить прод от oom и утечки ресурсов - по обстоятельствам
3. можно ли как-то защититься - можно но не на 100%(в кубе нашел вот такое https://cutt.ly/YkmBhrL)
1. надо ли писать мемори лики - нет
2. надо ли защитить прод от oom и утечки ресурсов - по обстоятельствам
3. можно ли как-то защититься - можно но не на 100%(в кубе нашел вот такое https://cutt.ly/YkmBhrL)
DD
То тогда тяжко ему прийдется. Ведь сожрать память можно и не самой программой непосредственно.
Например можно написать код, который засрет буфер какого-нибудь сетевого интерфейса и память улетит за пару секунд. А приложение себе преспокойно будет существовать.
Например можно написать код, который засрет буфер какого-нибудь сетевого интерфейса и память улетит за пару секунд. А приложение себе преспокойно будет существовать.
для этого вроде ж есть tcp max buffer size
DD
Но да, если играть в игру плохой разраб и хороший девопс, то скорее разраб победит=)
A
для этого вроде ж есть tcp max buffer size
Конечно. Но это всё надо учитывать. Т.к. если он полностью будет забит, то приложение хоть и будет работать, но никому вокруг об этом не будет известно.
И тут можно подумать о том, чтобы его сделать побольше, чтобы весь "хайлоад" поместился.
И так подкрутив что-то одно, можно получить проблемы в совершенно неожиданных местах.
И тут можно подумать о том, чтобы его сделать побольше, чтобы весь "хайлоад" поместился.
И так подкрутив что-то одно, можно получить проблемы в совершенно неожиданных местах.
DD
Конечно. Но это всё надо учитывать. Т.к. если он полностью будет забит, то приложение хоть и будет работать, но никому вокруг об этом не будет известно.
И тут можно подумать о том, чтобы его сделать побольше, чтобы весь "хайлоад" поместился.
И так подкрутив что-то одно, можно получить проблемы в совершенно неожиданных местах.
И тут можно подумать о том, чтобы его сделать побольше, чтобы весь "хайлоад" поместился.
И так подкрутив что-то одно, можно получить проблемы в совершенно неожиданных местах.
Именно по этому я не реабилити инженер.
Спасибо, Александр, за приятную беседую.
Спасибо, Александр, за приятную беседую.
AB
@tshemsedinov Почитал, посмотрел и поигрался с примером на Метархии, а было ли видео (список) где описаны недостатки?
PS
@tshemsedinov двусторонняя синхронизация для фронта с разрешением конфликтов и поддержкой оффлайна -- это прямо описание библиотеки Logux (ситник делает)