Knowledge sharing
55 subscribers
59 photos
12 files
342 links
Тутати постараюсь шарить всякую годноту. А может и нет
@strukov
Download Telegram
Forwarded from I hate overtime
Открыл тут для себя диаграммы Исикавы. Оказалось, что очень удобно с помощью сабжа наглядно объяснять суть проблемы людям, не имеющим нужных компетенций, или не очень понимающим предметную область. Особенно, если софт-скилы не на высоте(как у меня😞)
Кароч хозяюшке на заметку)
Forwarded from Dodo Engineering
Шпаргалки по Python. Продвинутый уровень.
Сохраняйте, чтобы не потерять.

– Regular Expression (https://clck.ru/H59qw);
– Concurrency (https://clck.ru/H59se);
– Security (https://clck.ru/H59ua);
– Test (https://clck.ru/H59vV);
– Asyncio (https://clck.ru/H59wP).

Авторы: https://www.pythonsheets.com

Enjoy!
Я на днях в твиттере написал "смешной" бизнес-совет из интернета: "будьте везучими". Посмеялся, типа. И со мной также люди посмеялись. Мол, ха-ха, спасибо за полезный совет, вот теперь-то все наладится!

Только я - не смеялся в этом месте.

Вы делаете гы-гы, вы и так все знаете лучше всех. А я глупый, я пошел смотреть, что такое везение, и что знает культура про удачу и неудачу.

"Неудачи бессильны против того, кто твердо гнет свою линию. Раз не везет, два, сто, – но не бесконечно. И когда человек обретает умение и мужество держаться вопреки любому невезению – вот тогда он в порядке; и с первой крохой удачи – а эти крохи выпадают всем! – он попрет, как танк."

"Во-первых, [..] невезение – это когда человек хочет больше, чем может. Этим надо быть скромней. Второе: не умеет учитывать все жизненные обстоятельства. Третье: не готов к худшему. Четвертое: принимает мелочи близко к сердцу."

"На удачу надо плевать – тогда она придет сама. И быть к ней готовым: недостойному она не поможет – он не сумеет ею воспользоваться, удержать. Ее надо добиваться, но на нее нельзя рассчитывать: везет тому, кто сам себя везет. Когда человек может и без удачи, своим горбом и разумом добиться цели – при любых обстоятельствах! – вот тогда удача сама идет навстречу."

👆 Это все из одной только книги, навскидку. Совет в твите умный, просто не всякий читатель его способен понять.
Forwarded from Experimental chill
Как Netflix пытается лучше обеспечить CPU изоляцию.

Статья:https://medium.com/netflix-techblog/predictive-cpu-isolation-of-containers-at-netflix-91f014d856c7
Репозитория нет.

CPU кристалл один, но количество сервисов, которые на нём запускается на одной машине, может быть много. Это есть принцип общежития, и порой соседи друг другу мешают.

Механизмы выделения CPU в основном занимается господин Linux, используя стандартный и прекрасный алгоритм CFS (Completely Fair Scheduler), почитать о котором можно в огромном количестве мест (точкой для старта может стать эта ссылка https://opensource.com/article/19/2/fair-scheduling-linux). Netflix у себя померил и понял, что их распределение CPU далеко от идеала и сделал следующее.

Давайте вместо того, чтобы класть контейнеры как попало, будем их класть эффективнее через задачи комбинаторной оптимизации. Как этого достигать -- современные процессоры разбивают процессор на несколько NUMA сокетов (считайте, что это просто отдельная сущность, где рядом хранятся L1, L2, L3 кэши и сам CPU вместе с его hyper threading клоном). И у нас есть свойство, что ходить к соседней NUMA node для доступа к кэшам в 5 раз дороже, чем сходить в свою память. (картинка внизу показывает упрощенно архитектуру и плохую и хорошую упаковку).

Итак, у нас есть K контейнеров, каждый который потребляет сколько-то CPU и d тредов на инстансе. Это задача Mixed Integer Program и хорошо решается на не очень больших d и K. На самом деле, нам надо найти бинарную матрицу (d, K), в которой сумма в столбце будет равна количеству CPU, который просит контейнер, а в строке не более одной единицы. Последнее условие вряд ли выполняется всегда, поэтому мы скорее введём loss функцию, чтобы её уменьшать. Какие эвристики в loss функции бывают:

* Количество контейнеров на разных NUMA nodes должно быть минимально
* Не использовать hyper-thread, пока не надо, чтобы L1/L2 кэши не мешались
* Пытаться не загружать L3 кэши (например, в зависимости от важности контейнера, кому-то нужен L3 кэш очень сильно)

Теперь вместо того, чтобы CFS отрабатывал каждые несколько милисекунд, стоит перебалансировать на инстансе раз в несколько секунд, опираясь на статистику контейнеров или даже предсказательный ML (в Netflix взяли градиентный бустинг, чтобы предсказывать 95 квантиль потребления контейнера в следующие 10 минут).

Netflix утверждает, что они так смогли очень сильно сбавить высокие квантили и уменьшить дисперсию ожидания/потребления CPU. Linux не тратит CPU, чтобы шедулить процессы, теперь потребление контейнеров лучше предсказывается и легче воспроизводимо.

Дальше Netflix хочет понимать, а есть ли вообще в процессах ненужные ресурсы и перешардивать нагрузку на инстансе исходя из этого.

Это просто охеренно. Шах и мат, дискретные опты всё же нужны. Прочитайте статью полностью, я упускал некоторые детали.

Захотелось в Netflix поработать, жаль, там Java :(
Вот туть еще про разработку для кубера, так то ребятки говорят что еще 7 не хватает, но это пойнт для срачика имхо
Forwarded from sudo rm -rf /*
Годная схема по контекстам nginx от tproger
вот тут https://news.ycombinator.com/item?id=20817627
нашёл вот это https://insomnia.rest/ это REST client builder
такая то вкуснота
хотя приходили по-пиарить это https://liyasthomas.github.io/postwoman/
зачем, ну вдруг у вас 1998 и нету OpenAPI/Swagger клиента
в посте ещё отписался Improvotter, который рассказал за свой экспириенс с другими тулами, каждый(почти) достоен(нет) как минимум попробовать
#REST