Technologique
663 subscribers
144 photos
3 videos
42 files
949 links
Deeply involved developers about various aspects, tendencies & conceptions of programming technologies, FLOSS, Linux, security, cloud infrastructures & DevOps practices, distributed systems, data warehousing & analysis, DL/ML, web3, etc.
Author: @andrcmdr
Download Telegram
Отличное сравнение популярных облачных VPS провайдеров по цене и производительности железа - скорости обработки данных (мощности CPU), скорости ввода-вывода дисковой подсистемы серверов и производительности сетевого стэка.

https://www.webstack.de/blog/e/cloud-hosting-provider-comparison-2017/

https://www.vpsbenchmarks.com/compare/scaleway_vs_vultr
https://www.vpsbenchmarks.com/plans

Ссылки:
https://www.scaleway.com/pricing/
https://www.online.net/en

https://www.vultr.com/pricing/

https://www.ovh.com/world/vps/

https://www.digitalocean.com/pricing/

https://www.linode.com/pricing

https://www.heroku.com/pricing

https://www.hetzner.com/cloud?country=us

#vps #vds #asp
The big short

Прекрасная статья, объясняющая на реальных примерах опыта различных компаний почему время отклика веб-приложений имеет значение и играет ключевую роль в успехе онлайн компаний.

https://neilpatel.com/blog/speed-is-a-killer/

И занимательная аналитика на эту же тему:

https://blog.hubspot.com/marketing/page-load-time-conversion-rates

В условиях микро и нано-сервисных облачных (cloud native, FaaS) инфраструктур - оптимизация по расходу памяти (memory footprint) и времени отклика (decrease latency) это уже устойчивый тренд, при том не только для крупных компаний, который имеет более важное практическое значение, чем синтетические нагрузочные бенчмарки с замерами значений RPS (requests per second) к различным программным подсистемам софта.
Technologique
По следам OOM Killer'a. Последнее время читатели и друзья задают один и тот же вопрос про OOM Killer механизм ядра Linux и как сделать систему отзывчивой при превышении лимита памяти так, чтобы не использовать страничную подкачку очень часто. Поэтому я решил…
OOMd - user space daemon for killing processes by out of memory exception raises.

И в дополнение к предыдущей статье, а также серии статей, опубликованных мной ещё в январе месяце, написанных во время активной фазы работ над оптимизацией датацентров, сервисов и сети доставки контента.

Буквально на днях коллеги из группы Facebook Open Source Team опубликовали исходники демона oomd работающего в пространстве привилегий пользователя для завершения процессов при срабатывании исключения out of memory (OOM), при чрезмерном расходе памяти приложениями и сервисами.

https://code.fb.com/production-engineering/open-sourcing-oomd-a-new-approach-to-handling-ooms/

https://github.com/facebookincubator/oomd

Также для более раннего обнаружения (до срабатывания исключения OOM Killer в ядре) паразитических процессов и нагрузки создаваемой ими и чтобы не потерять контроль над уже нестабильной системой (а также для повышения стабильности и отзывчивости системы) в момент срабатывания OOM Killer механизма ядра, для включения в ядро был предложен механизм Pressure Stall Information — pressure metrics, метрики, подобные load average, по таймфреймам, для создания и определения модели нагрузки и определения livelocks состояний (взаимоблокировки процессов при попытке завладения доступом к ограниченным ресурсам) по подсистемам cpu, memory и io, и по отдельным процессам, как для отслеживания "качества жизни" отдельных процессов и их окружений cgroups, так и нагрузки по подсистемам ресурсов в целом — для предоставления информации ядру и для более раннего обнаружения процессов слишком активно требующих выделения ресурсов системы и потребляющих их:

https://lkml.org/lkml/2018/7/12/661

Данный механизм ядра совместно с демоном oomd позволяет более точно отслеживать состояние процессов и выделение ресурсов в системе, более точно локализовать проблемные места (bottle-necks) для дальнейшей оптимизации сервисов по потреблению ресурсов, а также повысить отзывчивость (время реакции, задержки, latency), стабильность и надёжность (fault tolerance) работы системы, особенно в условиях мультиконтейнерных stateless окружений микро и нано сервисов, повысить эффективность утилизации ресурсов кластерных систем и масштабируемость приложений при миграции процессов в пределах кластерной системы.

Следующий большой шаг, над которым ведётся работа - разработка и интеграция новых решений для систем инициации (systemd, а также upstart и sysVinit для более старых систем) по отслеживанию состояний потребления ресурсов процессами резидентных приложений (демонов), с высоким постоянным невыгружаемым пулом памяти (memory footprint).

Существующие механизмы в текущих системах инициализации в ОС GNU/Linux не дают необходимой гибкости управления процессами, особенно у условиях состояний ограниченных или исчерпывающихся ресурсов в системе.

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#OOMScoreAdjust=

http://upstart.ubuntu.com/cookbook/#oom-score
http://upstart.ubuntu.com/cookbook/#respawn
http://upstart.ubuntu.com/cookbook/#respawn-limit

Хочу выразить благодарность Артёму, автору канала @SysadminNotes, за публикацию данной информации (https://t.me/SysadminNotes/877) и за прекрасный и очень интересный канал (подписывайтесь, читайте - рекомендую! 😉)

PS: На самом деле очень приятно видеть, когда то, над чем работали для конторы уходит в open source - труды не пропадают даром и подобные проекты будут полезны всему сообществу. Жаль что не столь оперативно происходит открытие исходников подобных интересных проектов.

Материалы по теме:
https://t.me/technologique/1253
https://t.me/technologique/1254 - в данной статье я упоминал также про подобное уже существовавшее на тот момент решение проблемы ранней упреждающей обработки OOM исключений в user space, EarlyOOM (https://github.com/rfjakob/earlyoom)
https://t.me/technologique/1255
https://t.me/technologique/1256
https://t.me/technologique/1258
Technologique
OOMd - user space daemon for killing processes by out of memory exception raises. И в дополнение к предыдущей статье, а также серии статей, опубликованных мной ещё в январе месяце, написанных во время активной фазы работ над оптимизацией датацентров, сервисов…
Daemonization for JVM

Есть ещё одна неприятная известная проблема с Java приложениями которая требует освещения.
На Java невозможно написать нормальное резидентное stateless приложение демона, коими являются любые сетевые демоны, обеспечивающие работу сетевых протоколов, да и вообще любые приложения относящиеся к server-side cloud infrastructure software.

То есть написать возможно, но чтобы сохранялось нормальное состояние работы и отказоустойчивость пориложения при его сбоях в run-time и/или перезагрузках системы - это сложно в реализации.

На скриптовых языках такое написать более возможно поэтому они широко используется как системные демоны для управления различными подсистемами в Linux (пример - OpenStack, комплексная система автоматизации управления облачными инфраструктурами) и используются в мультиконтейнерных приложениях и микро/нано сервисных серверных инфраструктурах для украшения ими.

На нативно статически компилируемых языках такие приложения писать возможно и более того - это единственный правильный корректный способ написания и реализации таких резидентных приложений.

В общем, стояла недавно такая задача...
Управлять стартом/рестартом Java приложений после их краха, убийства процесса приложения ядром при переполнении памяти (по out of memory exception) при помощи системы инициализации (Upstart в Ubuntu LTS, systemd на Debian) в Линуксе внутри контейнера или без контейнера в самой системе (для старых монолитных систем).

Сделать это непросто, т.к. Java машина, особенно если на ней исполняется сервер приложений с несколькими сервлет-контейнерами, имеет множество системных потоков (тред-пулов, spawned fork-join thread-pools) и может ответвлять отдельные процессы (fork-join process pools) для запуска сторонних приложений (например инициировать запуск sms демона для обслуживания SMS шлюза).
Состояние и PID (process id) процессов при этом отслеживать системой инициализации демонов в Linux очень сложно технически и не представляется возможным, т.к. система инициализации умеет отслеживать либо один форк процесса (expect fork stanza), либо двойной форк процесса (expect daemon stanza) при запуске и работе управления приложением, его автоматическим запуском и перезапуском, но не процесс пулы, где сложно отследить корневое приложение иницирующее ветвления, форки процессов в пуле.

Для этого приходится писать обёртки (wrappers), чаще на скриптовых языках или использовать готовые типа start-stop-daemon, для демонизации Java приложений и ортогонального управления ими.

Благо по системам инициализации есть прекрасная документация.

http://upstart.ubuntu.com/cookbook/#stanzas-by-category

http://upstart.ubuntu.com/cookbook/#initctl-commands-summary

http://upstart.ubuntu.com/cookbook/#expect

http://upstart.ubuntu.com/cookbook/#run-a-java-application

http://upstart.ubuntu.com/cookbook/#alternative-method

https://wiki.ubuntu.com/Upstart

https://www.freedesktop.org/software/systemd/man/systemd.exec.html

И пара классных статей от Digital Ocean по различиям систем инициализации и управления процессами в Linux системах.

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference

#Linux
#Ubuntu
#Upstart
#systemd
Rust concurrency in a nutshell

https://www.youtube.com/watch?v=SiUBdUE7xnA

Отличная лекция Алекса Крайтона, разработчика библиотечных решений для использования паттернов многопоточности в языке Rust и знаменитого фреймворка Tokio для разработки приложений, использующих многопоточный асинхронный неблокирующий ввод-вывод (concurrent event loop for asynchronous non-blocking IO) — о подходах, моделях и парадигмах использованных в языке Rust для разработки безопасного многопоточного кода более простыми и понятными методами (closures, corourines, continuations, message passing and channels, actors, futures, promises и их использование в контексте концепций языка, системы типов и компилятора языка Rust — владения и заимствования для контроля использования указателей и время жизни для областей видимости в контексте вызова и исполнения функций).

#Rust
Forwarded from pub ThisWeekInRust {}
It’s that time again! Time for us to take a look at how the Rust project is doing, and what we should plan for the future. The Rust Community Team is pleased to announce our 2018 State of Rust Survey! Whether or not you use Rust today, we want to know your opinions. Your responses will help the project understand its strengths and weaknesses and establish development priorities for the future.Completing this survey should take about 10 to 15 minutes and is anonymous unless you choose to give us your contact information. We will be accepting submissions until September 8th, and we will write up our findings a month or so afterwards to blog.rust-lang.org. You can see last year’s results here.This year, volunteers have also translated the survey into many languages! You can now take the survey in:EnglishSimplified ChineseTraditional ChineseFrenchGermanHindiItalianKoreanPolishPortugueseRussianSpanishSwedishVietnamese(If you speak multiple languages, please pick one)Please help us spread the word by sharing the survey link on your social network feeds, at meetups, around your office, and in other communities.If you have any questions, please see our frequently asked questions or email the Rust Community team at community-team@rust-lang.org.Finally, we wanted to thank everyone who helped develop, polish, and test the survey!

via The Rust Programming Language Blog https://ift.tt/2MsBOmR
ECMAScript 9 (2018)

В стандарте ECMAScript 9 (2018) добавлена долгожданная поддержка positive and negative lookbehind assertions, backreferences и named captured groups - то, чего всегда не хватало для продвинутого поиска строк. Теперь регулярные выражения в JS стали ближе к PCRE. В скором времени поддержка более продвинутого синтаксиса регулярных выражений появится в движках браузеров, в Node.js и в редакторах VSCode и Atom (чего я лично особенно жду - уже привык к синтаксису Oniguruma в Sublime Text).
Также добавлена поддержка асинхронных итераторов и генераторов на уровне языка, через async/await синтаксис и на базе библиотечной реализации Promises.

http://www.ecma-international.org/ecma-262/9.0/index.html#prod-Assertion

http://www.ecma-international.org/ecma-262/9.0/index.html#prod-annexB-Assertion

http://www.ecma-international.org/ecma-262/9.0/index.html#sec-assertion

This specification, the 9th edition, introduces support for asynchronous iteration via the AsyncIterator protocol and async generators. This specification also includes four new regular expression features: the dotAll flag, named capture groups, Unicode property escapes, and look-behind assertions. It also includes rest parameter and spread operator support for object properties. There have also been many minor updates, editorial and normative, with many contributions from our awesome community.
Официальный релиз Dart 2.0

Уже не на Google IO 2018, но на днях состоялся официальный релиз второй версии языка Dart.

https://medium.com/dartlang/dart-2-stable-and-the-dart-web-platform-3775d5f8eac7

https://news.dartlang.org/2018/08/announcing-dart-2-stable-and-dart-web.html

В транслятор DartVM внедрили строгую систему динамических типов - типы данных записываются в байт-код при компиляции исходников (их верификации и выводе типов из выражений - flow-sensitive type system), но строгий контроль типов данных, динамическое связывание типов данных (статически записанных в байт-код - gradual type system) и значений объектов в памяти происходят во время исполнения кода в run-time. Такая схема напоминает расширение mypy (PEP-484) для статически аннотируемых типов в Python, используемое для снижения риска run-time ошибок и уменьшения пространства покрытия исходных текстов динамическими юнит тестами.
С одной стороны такая sounding type system даёт больший контроль типов данных и гибкость для обобщённых типов (для поддержки параметрического импредикативного полиморфизма), особенно с учётом вывода типов, но run-time проверки приводят к бОльшим задержкам при исполнении кода, что снижает производительность и применение языка для разработки критических к скорости реакции и чувствительных к задержкам онлайн систем и облачных инфраструктур.

https://medium.com/@matanlurey/dart-2-for-fun-and-profit-types-7757de406568

Виртуальная машина DartVM и платформа Flutter, работающая на ней и созданная для нативной разработки кроссплатформенных приложений, имеют несколько режимов компиляции - от нативной машиннозависимой AoT компиляции до динамической JIT кросскомпиляции байт-кода.

https://proandroiddev.com/flutters-compilation-patterns-24e139d14177

Для Dart уже есть инфраструктура сборки проектов Pub и экосистема пакетов на её основе - есть пакеты, которые можно использовать для различных платформ (изоморфная разработка). Например фреймфорк Angel можно использовать для разработки как серверной части (MVC), так и для разработки клиентских мобильных приложений на Flutter и веб-приложений на Dart Web - используется транскомпилятор Dart2JS, который напоминает по принципам своей работы TypeScript - исходники могут быть транскомпилированы в соответствии с различными стандартами ECMAScript для кросс-браузерной совместимости.

https://medium.com/dartlang/getting-ready-for-dart-2-and-making-your-packages-look-great-on-the-pub-site-118464d7f59d

Платформа Flutter имеет огромные перспективы, т.к. фактически это shim layer для DartVM, транслирующий API вызовы платформы Flutter в системные вызовы ОС и использующий FFI интерфейс к системным библиотекам для абстрагирования над системным API мобильных ОС, при этом с близкой к нулевой стоимостью таких обращений к системным библиотекам.

В ближайшие несколько лет Google имеет долгосрочный план перехода на Fuchsia OS для замены экосистемы Android - новая экосистема разработки будет построена именно вокруг и на базе Flutter SDK и NDK.

Ссылки на предыдущие публикации по Dart, Flutter и ОС Fuchsia:

https://t.me/technologique/1278

https://t.me/technologique/1288

https://t.me/technologique/1287

https://t.me/technologique/1084

https://t.me/technologique/1080

https://t.me/technologique/1082

https://t.me/technologique/1083
Technologique
Официальный релиз Dart 2.0 Уже не на Google IO 2018, но на днях состоялся официальный релиз второй версии языка Dart. https://medium.com/dartlang/dart-2-stable-and-the-dart-web-platform-3775d5f8eac7 https://news.dartlang.org/2018/08/announcing-dart-2-stable…
Также по режимам компиляции DartVM есть очень интересный доклад из первых рук - непосредственно от разработчиков DartVM.

https://www.youtube.com/watch?v=lqE4u8s8Iik

https://github.com/flutter/engine/wiki/Flutter-Engine-Operation-in-AOT-Mode

Команда разработчиков Dart - это много очень опытных и умных людей, разрабатыающих ранее V8, HotSpot VM, Вячеслав Егоров в свою очередь сделал вклад в развитие проекта LuaJIT (автор проекта Михаэль Пэлл, Michael Pall).

https://www.blossom.co/blog/who-is-behind-dart
Foreshadow

Очередная уязвимость механизма спекулятивного исполнения инструкций в процессорах Intel и эксплуатирующая её атака посредством использования анализа сторонних каналов - Foreshadow.

Уязвим механизм безопасности Intel Software Guard Extensions (Intel SGX).

Уязвимость позволяет непривилегированному пользователю читать кэш данных первого уровня (L1 data cache) процессора.

https://youtu.be/ynB1inl4G3c

http://foreshadowattack.com

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html

Предыдущие публикации по теме:
https://t.me/technologique/1289
https://t.me/technologique/1260
https://t.me/technologique/1242
https://t.me/technologique/1235
https://t.me/technologique/1246
https://t.me/technologique/1223
https://t.me/technologique/1225
Утечка приложений инфраструктуры Аэрофлота

У комании Аэрофлот были скопированы дампы файловой системы всех контейнеров из локальной инфраструктуры репозиториев контейнеров Docker Registry, через незащищённый API, открытый публично.
Дампы содержат слои ФС контейнеров приложений компании, по которым можно восстановить полностью содержимое образов контейнеров - исходный код приложений (на Python), конфигурации и данные авторизации, и другую весьма занимательную для анализа информацию.

https://github.com/aeroflotsrc/webapp
Introducing Sorbet - gradual typing for Ruby

Дмитрий Петрашко, автор компилятора DOTty с системой зависимых типов (dependent types, calculus of constructions, CoC) для будущей версии языка Scala 3, совместно с Полом Тарьяном (Paul Tarjan), инженером Stripe (одного из крупнейших сервисов для платежей в интернете), создали gradual typing run-time типизатор Sorbet для языка Ruby.
Декларации типов по синтаксису схожи со Scala.
Sorbet был применён для server-side инфраструктуры Stripe, насчитывающей миллионы строк динамически типизированного кода на Ruby, при этом внедрение происходило без приостановки процессов разработки сервисов Stripe.

https://sorbet.run/talks/StrangeLoop2018/

https://sorbet.run

Постепенная типизация (gradual typing, статическая аннотация типов в исходниках, с дальнейшей записью информации о типах в байт-код в фазе compile-time и с последующей инвокацией, диспетчеризацией и связыванием типов в run-time при интерпретации байт-кода) доступны и внедрены во множестве других языков официально - PEP-484 (mypy) для Python, в Dart 2.0 и Groovy.
Такой подход позволяет снизить количество run-time ошибок и уменьшить необходимость в покрытии исходников unit-тестами.
При этом нужно учитывать, что даже с учётом введения статической типизации в язык, инвокация методов вывода типов, диспетчеризация типов и связывание с типами происходят динамически в run-time в процессе интерпретации байт-кода, ввиду чего производительность исполнения кода увеличивается несущественно, как минимум из-за наличия задержки (latency, временнОго барьера, временнОго окна) при связывании типов данных с переменными в процессе исполнения, интерпретации кода (в run-time).

Вся проблема динамических типов и динамических языков их использующих в том, что в них в run-time все типы объектов в памяти изначально обобщённые и мутабельные, как дженерики, и ad-hoc подстановка нужного типа (даже если тип не требует вывода и уже записан в байт-код) выполняется динамически в run-time, что приводит к задержкам исполнения кода, лишним latency. Интерпретация также играет свою роль в замедлении исполнения кода, но например в Dart 2.0 с AoT компиляцией (https://t.me/technologique/1312) и записью данных о типах уже в бинарный код основным фактором latency является динамическая подстановка нужного типа и связывание его с объектом в памяти также в процессе исполнения кода (авторы DartVM мотивируют это решение большей гибкостью обобщённых алгоритмов и их кода).

В Rust например компилятор выполняет статическую мономорфизацию и ad-hoc подстановку выведенного типа для типов данных и type-class'ов в compile-time и в фазе исполнения кода вообще нет динамизма типов, даже для дженериков (обобщённых типов), т.к. в бинарном коде типы уже мономорфизированы в фазе compile-time и имеют конкретный тип данных, примитивный или абстрактный, но записанный в код и статически связанный с объектами, которые будут размещены в памяти.

Ссылки по теме:
https://t.me/technologique/1287
https://t.me/technologique/1214
https://t.me/technologique/1311
https://t.me/technologique/1124
https://t.me/technologique/155

https://t.me/technologique/1131
https://t.me/technologique/1133
https://t.me/technologique/720
Technologique
Роман Элизаров снова очень хорошо рассказал про сопрограммы и глубоко погрузил всех в асинхронный и многопоточный код на базе сопрограмм, продолжений и suspend functions. https://www.youtube.com/watch?v=_hfBv0a09Jc Ссылки на предыдущие материалы по теме:…
Structured concurrency

Статья Романа Элизарова, в которой приведено весьма доступное объяснение концепций структурной многопоточности, их отношений и различий, на базе futures/promises, отложенных вызовов (defferred) и приостанавливаемых функций (suspend functions), продолжений и сопрограмм (continuations & coroutines).

https://medium.com/@elizarov/futures-cancellation-and-coroutines-b5ce9c3ede3a

#Kotlin
RustRush Conference

8 декабря в Москве пройдёт конференция RustRush для разработчиков и всех заинтересованных языком Rust и его экосистемой.

https://rustrush.ru

@rustrush
GitHub Actions

Сервис GitHub запустил GitHub Actions - средства автоматизации процессов разработки (Workflows as Code) с помощью языка HCL (HashiCorp Config Language).

https://github.com/features/actions