Forwarded from Записки админа
⚒ Лёгкая, кроссплатформенная build утилита, написанная на Lua. Выглядит так, что работать и собирать нужное будет даже на чайнике, если потребуется.
https://github.com/xmake-io/xmake
#make #xmake
https://github.com/xmake-io/xmake
#make #xmake
Forwarded from Записки админа
ssh.pdf
4.7 MB
🛠 Brennon Thomas. "The Cyber Plumber’s Handbook. The definitive guide to SSH tunneling, port redirection, and bending traffic like a boss."
Взято из этого репозитория.
#ssh #tunnel #напочитать
Взято из этого репозитория.
#ssh #tunnel #напочитать
Forwarded from Evgeniy Rasyuk
https://medium.com/snowflake/automatic-clustering-at-snowflake-317e0bb45541
Теория о том как солить данные не оглядываясь на их природу
Теория о том как солить данные не оглядываясь на их природу
Medium
Automatic Clustering at Snowflake
Author: Ryan Shelly on behalf of the SQL Workload Optimization team
Forwarded from Записки админа
🐧 And now Linux has a Real-Time Linux Analysis (RTLA) tool! Кажется, в ядре 5.17 нас ждёт новый инструмент для трейсинга и получения данных о производительности.
Для желающих окунуться в детали, есть отдельный документ, доступный по ссылке - Demystifying the Real-Time Linux Scheduling Latency.
#linux #performance #rtla
Для желающих окунуться в детали, есть отдельный документ, доступный по ссылке - Demystifying the Real-Time Linux Scheduling Latency.
#linux #performance #rtla
Forwarded from addmeto (Grigory Bakunov 🧪)
Помните Roblox в октябре лежат трое суток? Хочу высказать почет и уважение - они только что выложили полное описание того как, от чего они упали и как развивались события. Это один из самых подробных пост-мортемов который я видел, вся проблема была в Consul, который использует BoltDB не рассчитанный на подобное супер-интенсивное использование.
Если вы занимаетесь эксплуатацией сервисов обязательно почитайте, невероятно поучительно https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/
Если вы занимаетесь эксплуатацией сервисов обязательно почитайте, невероятно поучительно https://blog.roblox.com/2022/01/roblox-return-to-service-10-28-10-31-2021/
Roblox
Roblox Return to Service | Roblox
Roblox is a global platform where millions of people gather together every day to imagine, create, and share experiences with each other in immersive, user-generated 3D worlds.
Forwarded from Записки админа
🛠 Отличная серия статей получилась, как по мне:
- Debugging Distributed Trace Gaps with tcpdump;
- Debugging Distributed Trace Gaps with ftrace;
- Monitoring Linux Audit.
#audit #trace #напочитать
- Debugging Distributed Trace Gaps with tcpdump;
- Debugging Distributed Trace Gaps with ftrace;
- Monitoring Linux Audit.
#audit #trace #напочитать
Forwarded from Записки админа
Forwarded from Experimental chill
Метастабильные падения
Я просто обожаю эксплуатацию.
Практически никто о метастабильных падениях не говорит, они достаточно бессистемные, но кажется на своей практике поиска и вот сейчас мап редьюса я столкнулся просто со всем, что написано в статье.
Метастабильные падения это падения, которые вызваны непредвиденными обстоятельствами и даже если их убрать, то система не восстанавливается и продолжает не работать. Скажем, DDOS атака сама по себе не является метастабильным падением. Вы можете её убрать, и система продолжит хорошо работать.
Ретраи
Рассмотрим пример. Скажем, вы пишете сервис Google Maps API для поиска маршрута. Новый релиз разломал бэкенд карт. Надо откатывать, но вот незадача, ваше API используется очень тупыми железками вроде GPS навигаторов. Они перезапрашивают в цикле. В итоге бэкенд карт разломался, вы пытаетесь откатить изменения, а из-за количества запросов бэкенд снова валится. Вы снова пытаетесь поднять инстансы, а они не держат эту нагрузку. В итоге система сломана, надо очень сильно понижать нагрузку уровнями выше.
Кэш
Другой пример. Сундар Пичай рассказывал конгрессу, что в поиске примерно 50% запросов, которые задаются единожды и не повторяются другими пользователями. Когда вы видите, что 50% запросов можно отвечать, не ходя на бэкенд, то вы сделаете себе кэш. Кэш понизит лэтенси, будет крутой оптимизацией. Но...
Скажем, кэш для поиска работает днями, с ним все хорошо, проходят релизы. В один момент формат кэша поменялся и все таки надо его сбросить. Сбрасывайте, а бэкенд не может выдержать нагрузки! А он нужен для того, чтобы набрать кэш. В итоге вы не можете набрать кэш, потому что бэкенд развалился, кэш уже сбросился и невалиден. Как минимум вы застряли в системе, которая не двигается вперёд, как максимум это просто ад восстанавливать из-за многих релизов бекенда.
Сверхоптимизации
Третий пример, которого я страшно боюсь в своей работе. В мапредьюсе надо решить, сколько вы должны заплодить машин, как подробить данные для выполнения работы на той или иной стадии, чтобы минимизировать выполнение. Это моделька машинного обучения, и машинное обучение может ошибаться на высоких квантилях. В итоге приходит пользователь, у него пайплайн работал день, а теперь не может завершиться 10 дней из-за плохих решений автоскейлинга. Да что там говорить, ресурсов всей компании не хватит с такими решениями модельки, чтобы завершить пайплайн за месяц.
Что произошло на самом деле:
1. Мы научились оптимизировать пайплайн очень хорошо, без модельки он завершался
2. Пайплайн вырос в сотню раз, но мы все ещё хорошо его оптимизировали
3. Мы поменяли модельку оптимизации
4. Теперь не хватит ресурсов компании его завершить
В итоге надо руками прописывать как запускать стадии, что противоречит всем моделям эластичности Клауда.
Ближайший простой пример: алгоритмам сжатия не стоит иметь формат, который умеет сжимать в экспоненту раз, а то и в квадрат. Из-за этого есть zip-бомбы.
Все такие примеры очень показательны, что распределенные системы странно ломаются и входят в такой порочный круг, и часто их оптимизации могут привести к таким состояниям, когда они ломаются и сами не починятся. В литературе практически никогда ничего не говорится про такие идеи.
Решения, которые стоит рассматривать при проектировке
* Приоритеты. Делать приоритеты хорошим запросам.
* Лимиты. Если что-то оптимизируете, не оптимизируете это в сотню раз, если можете эту сотню в итоге потерять и не справиться.
* Всегда планировать нагрузку без оптимизаций, которые когда-то могут не работать, в том числе кэши. Пусть оно замедлит на 100ms ответ, но оно хотя бы не упадёт. Учения, стресс тестирование пригодится.
* Деградация. Попытайтесь задизайнить бэкенд, чтобы он эластично деградировал, скажем, не искать лучший маршрут в Google Maps, а рассматривать только X%.
* Следите за системой, одно падение может обнаружить баг, который был годами. Обычно происходит так: система ломается чуть-чуть, что-то подозрительное происходит, на след день что-то ещё хуже, через 2 дня всё падает крахом.
[1] Metastable Failures in Distributed Systems
Я просто обожаю эксплуатацию.
Практически никто о метастабильных падениях не говорит, они достаточно бессистемные, но кажется на своей практике поиска и вот сейчас мап редьюса я столкнулся просто со всем, что написано в статье.
Метастабильные падения это падения, которые вызваны непредвиденными обстоятельствами и даже если их убрать, то система не восстанавливается и продолжает не работать. Скажем, DDOS атака сама по себе не является метастабильным падением. Вы можете её убрать, и система продолжит хорошо работать.
Ретраи
Рассмотрим пример. Скажем, вы пишете сервис Google Maps API для поиска маршрута. Новый релиз разломал бэкенд карт. Надо откатывать, но вот незадача, ваше API используется очень тупыми железками вроде GPS навигаторов. Они перезапрашивают в цикле. В итоге бэкенд карт разломался, вы пытаетесь откатить изменения, а из-за количества запросов бэкенд снова валится. Вы снова пытаетесь поднять инстансы, а они не держат эту нагрузку. В итоге система сломана, надо очень сильно понижать нагрузку уровнями выше.
Кэш
Другой пример. Сундар Пичай рассказывал конгрессу, что в поиске примерно 50% запросов, которые задаются единожды и не повторяются другими пользователями. Когда вы видите, что 50% запросов можно отвечать, не ходя на бэкенд, то вы сделаете себе кэш. Кэш понизит лэтенси, будет крутой оптимизацией. Но...
Скажем, кэш для поиска работает днями, с ним все хорошо, проходят релизы. В один момент формат кэша поменялся и все таки надо его сбросить. Сбрасывайте, а бэкенд не может выдержать нагрузки! А он нужен для того, чтобы набрать кэш. В итоге вы не можете набрать кэш, потому что бэкенд развалился, кэш уже сбросился и невалиден. Как минимум вы застряли в системе, которая не двигается вперёд, как максимум это просто ад восстанавливать из-за многих релизов бекенда.
Сверхоптимизации
Третий пример, которого я страшно боюсь в своей работе. В мапредьюсе надо решить, сколько вы должны заплодить машин, как подробить данные для выполнения работы на той или иной стадии, чтобы минимизировать выполнение. Это моделька машинного обучения, и машинное обучение может ошибаться на высоких квантилях. В итоге приходит пользователь, у него пайплайн работал день, а теперь не может завершиться 10 дней из-за плохих решений автоскейлинга. Да что там говорить, ресурсов всей компании не хватит с такими решениями модельки, чтобы завершить пайплайн за месяц.
Что произошло на самом деле:
1. Мы научились оптимизировать пайплайн очень хорошо, без модельки он завершался
2. Пайплайн вырос в сотню раз, но мы все ещё хорошо его оптимизировали
3. Мы поменяли модельку оптимизации
4. Теперь не хватит ресурсов компании его завершить
В итоге надо руками прописывать как запускать стадии, что противоречит всем моделям эластичности Клауда.
Ближайший простой пример: алгоритмам сжатия не стоит иметь формат, который умеет сжимать в экспоненту раз, а то и в квадрат. Из-за этого есть zip-бомбы.
Все такие примеры очень показательны, что распределенные системы странно ломаются и входят в такой порочный круг, и часто их оптимизации могут привести к таким состояниям, когда они ломаются и сами не починятся. В литературе практически никогда ничего не говорится про такие идеи.
Решения, которые стоит рассматривать при проектировке
* Приоритеты. Делать приоритеты хорошим запросам.
* Лимиты. Если что-то оптимизируете, не оптимизируете это в сотню раз, если можете эту сотню в итоге потерять и не справиться.
* Всегда планировать нагрузку без оптимизаций, которые когда-то могут не работать, в том числе кэши. Пусть оно замедлит на 100ms ответ, но оно хотя бы не упадёт. Учения, стресс тестирование пригодится.
* Деградация. Попытайтесь задизайнить бэкенд, чтобы он эластично деградировал, скажем, не искать лучший маршрут в Google Maps, а рассматривать только X%.
* Следите за системой, одно падение может обнаружить баг, который был годами. Обычно происходит так: система ломается чуть-чуть, что-то подозрительное происходит, на след день что-то ещё хуже, через 2 дня всё падает крахом.
[1] Metastable Failures in Distributed Systems
Forwarded from Andrei Yangabishev
Я сейчас просматриваю лекции и семинары ФПМИ за 2021. Просто офигенный лектор
https://mipt.ru/online/algoritmov-i-tekhnologiy/teoriya-ORS.php
https://mipt.ru/online/algoritmov-i-tekhnologiy/teoriya-ORS.php
mipt.ru
Липовский Р.Г. Теория отказоустойчивых распределенных систем
Курс лекций, 3 курс 2019
Forwarded from Vadim Shender
Это 19-й год. Если что, вот лекции 20-го: https://www.youtube.com/playlist?list=PL4_hYwCyhAvZaJ3CJlGo9FxOTA2bS1YyN, семинары: https://www.youtube.com/playlist?list=PL4_hYwCyhAvZTjajkPpwgR29jyx81lMCl, репозиторий на github: https://gitlab.com/Lipovsky/distsys-course.
Forwarded from DevOps Deflope News
Сайт с аннотированными примерами GitHub Actions для новичков
http://a.e42.link/jmO5Y
http://a.e42.link/jmO5Y
GitHub Actions by Example
GitHub Actions by Example is an introduction to the service through annotated examples.