Но всё это не избавляет от зависших процессов, нагружающих процессор под 100% и тормозящих систему.
Такое всегда возможно и часто возникает, если где-либо в (плохо протестированной на краевые значения run-time параметров) программе, при совпадении определённых обстоятельств и значений параметров, возможен бесконечный цикл с малой задержкой (возможно уже после компиляции) или deadlock или race condition в критической секции (shared mutable memory/state) памяти при десинхронизации потоков, что также приводит к возникновению hard reference указателей на одну и ту же область памяти, препятствует сборке мусора, в результате чего возникает утечка памяти.

При исчерпании памяти другие механизмы ядра должны завершать процесс, с меньшим количеством проверок и ожидания завершения процесса, т.к. механизм OOM Killer в этом плане крайне не надёжен и полагаться на него не стоит - в конфигурации ядра системы по умолчанию он зависает вместе с ядром и всей системой ещё до срабатывания уничтожения процесса, который привёл к фризу системы.

https://askubuntu.com/questions/398236/oom-killer-not-working

К тому же любой процесс может отключить для себя вызов oom_kill() через константу OOM_DISABLE (-17), устанавливаемую для процесса.

https://superuser.com/questions/1150215/disabling-oom-killer-on-ubuntu-14-04/1150229

https://linux-mm.org/OOM_Killer

Для большей отзывчивости системы и процессов, гарантированного времени ожидания (задержек, latency) и реакции системы на события и ввод-вывод, ядро должно использовать вытесняющую многозадачность (preemptive multitasking) мягкого или жёсткого реального времени.
Для этого нужно либо ставить патч-сет с поддержкой вытесняющей многозадачности для агрессивного убийства зависших процессов (https://wiki.archlinux.org/index.php/Kernels#Patches_and_patchsets, https://wiki.archlinux.org/index.php/Realtime_kernel), либо руками собирать кастомное ядро и самому выставлять требуемые параметры ограничений per-process memory limits для процессов (менеджера памяти ядра) и задержек шедуллера (планировщика задач ядра).

На Debian я использую ядро с патч-сетом PREEMPT_RT для вытесняющей многозадачности реального времени, на Arch использую сборку ядра Zen — при должной конфигурации эти ядра работают прекрасно даже в самых критических ситуациях (как на локальных машинах, так и на серверах), реакция системы остаётся отзывчивой даже при длительном аптайме, фрагментации и переполнении памяти.

https://wiki.linuxfoundation.org/realtime/start

https://rt.wiki.kernel.org/index.php/Main_Page

https://packages.debian.org/sid/linux-image-rt-amd64

https://liquorix.net

https://github.com/zen-kernel/zen-kernel

https://www.archlinux.org/packages/?name=linux-zen

У поисковых движков для БД много in-memory механизмов и ввод-вывод из/в память очень активный.
ElasticSearch рекомендует отключать swap, что для продакшн серверов не позволительно, т.к. при переполнении памяти сделает сервер недоступным.
В этой связи вспомнился один из случаев оптимизации памяти.
Как-то раз мы экспериментировали и пробовали для оптимизации высокой доступности подсиситемы хранения данных (data warehouse) in-memory хранение БД (с горячим агрессивным кэшированием в память) с дополнительным использованием zRAM (сжатие страниц памяти в swap раздел, находящийся в самой ОЗУ) на серверах - сжатие страниц памяти в swap не так сильно нагружало процессор, но расширяло доступную память за счёт сжатия невостребованных страниц ("остывающего" кэша) и давало профит при размещении swap раздела в ОЗУ, т.к. снижало нагрузку по дисковому вводу-выводу (почти все IO операции происходят в RAM) и соответственно уменьшало задержки (latency) IO операций при доступе к данным, особенно для in-memory хранилищ, даже при наличии быстрого SSD кэша в дисковой подсистеме на серверах хранилища (задержки/latency в RAM меньше и ОЗУ память всё равно быстрее).

zRAM:
https://t.me/technologique/1040

Также есть zswap, встроенный механизм ядра, для сжатия и дампа страниц памяти в swap:
https://wiki.archlinux.org/index.php/zswap

https://wiki.archlinux.org/index.php/Improving_performance#Zram_or_zswap

Можно конечно просто разместить swap раздел в памяти ОЗУ без его сжатия, но использование zRAM давало дополнительную живучесть серверам в критических ситуациях и нагрузках - если памяти хватало использовался in-memory swap, но при острой нехватке памяти включалось её сжатие в in-memory swap (для "остывающего" кэша), что повышало доступность сервисов (без завершения процессов сервисов и перезапуска контейнеров - https://t.me/technologique/1253) и повышало uptime серверов, лишь немного снижая задержки ответов для клиентов.
Сейчас данная техника с несколько другим софтом используется регулярно для оптимизации доступности серверов хранилища.

Доклад Дениса Аникина на HighLoad++ 2015 об оптимизации БД, in-memory хранении, категориях "теплоты" кэша и in-memory механизмах хранения данных в СУБД Tarantool:
https://t.me/technologique/583

Спасибо нашему читателю Борису за отличный фидбэк! 👍

PS:
Немного футуризма:
https://t.me/technologique/88
Представьте как всё изменится, когда произойдёт конвергенция быстрой и энергозависимой ОЗУ (имеющей малый объём) и медленной энергонезависимой ПЗУ (имеющей большой объём), ОЗУ и ПЗУ память сравняются по скорости, объёму и постоянству хранения, благодаря новым технологиям памяти на мемристорах - многие границы будут стёрты, а ограничения сняты!
Не нужен будет swap, uptime будет максимальным, перезагрузка и гибернация будут мгновенными, будет доступно единое шифрование ФС всей памяти, что предотвратит утечки данных и уязвимости с ними связанные (подобные недавним уязвимостям контроля доступа к памяти в процессорах), безопасность кода (нельзя изменять) и данных (нельзя исполнять) будет основываться на политике безопасности единой ФС памяти (ACL и атрибутах файлов устройств, процессов и потоков в системе).

Официальный релиз клиента Telegram X

https://telegram.org/blog/telegram-x

Клиентское приложение создано на базе библиотеки TDLib (https://t.me/technologique/1222, http://telegram.org/blog/tdlib) и ранее носило название Challegram, благодаря участию автора в конкурсе по разработке клиентских приложений Telegram для мобильных платформ.

https://play.google.com/store/apps/details?id=org.thunderdog.challegram

https://itunes.apple.com/app/id898228810

Джон Мастерс из RedHat об уязвимостях аппаратных архитектур в целом и суперскалярной архитектуры микропроцессоров в частности на семинаре Stanford Online университета Стенфорда.

https://youtu.be/zuBw1HFJMsM

Ссылки:
https://t.me/technologique/1242
https://t.me/technologique/1243
https://t.me/technologique/1244
https://t.me/technologique/1245
https://t.me/technologique/1246

Поглощение проекта CoreOS компанией RedHat.

Разработки проекта CoreOS будут интегрированы в дистрибутив RedHat Atomic и облачную инфраструктуру RedHat OpenShift.

https://coreos.com/blog/coreos-agrees-to-join-red-hat

https://www.redhat.com/en/blog/faq-red-hat-acquire-coreos

https://www.redhat.com/en/about/press-releases/red-hat-acquire-coreos-expanding-its-kubernetes-and-containers-leadership

Oracle Fn

Соонователь Iron.io, ныне директор по направлению serverless в Oracle, Чед Аримура рассказал подробнее о serverless/FaaS платформе Fn, применяемой для создания инфраструктуры микро и наносервисов, на базе Docker, Kubernetes и написанных на различных языках программирования.

https://youtu.be/YgNrGT8pzYw

#serverless
#FaaS
#Go
#Golang

Ссылки по теме:
https://t.me/technologique/1177
https://t.me/technologique/608

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

В новом раунде были проведены тесты фреймворков из предыдущих раундов, а также появилось несколько новых очень классных фреймворков на Rust (Hyper, Actix, улучшены тесты Tokio) и Kotlin (ktor, hexagon, http4k, pronghorn), которые заняли топовые позиции по результатам тестов, при этом показатели результатов тестов производительности уже присутствовавших ранее фреймворков на данных языках (взгляните на фреймворк Tokio.rs) с каждым раундом и релизом фреймворка только растут, это показывает, что кодовая база и архитектура фреймворков уже стабилизировалась и теперь происходит её постепенная оптимизация и улучшение.
Безусловно, довольно молодые экосистемы языков Rust, Go и Kotlin растут, библиотеки и фреймворки на этих языках улучшаются и появляются новые.

https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext&a=2

https://www.techempower.com/blog/2018/02/14/framework-benchmarks-round-15/

За непрерывным обновлением данных по прохождению тестов между раундами можно следить на данной странице:
https://tfb-status.techempower.com

Предыдущие посты по теме:
https://t.me/technologique/970
https://t.me/technologique/609
https://t.me/technologique/59

Релиз Go 1.10

https://blog.golang.org/go1.10

https://golang.org/doc/go1.10

#Go #Golang

Связанные посты:
https://t.me/technologique/1170
https://t.me/technologique/1172

https://t.me/technologique/1057
https://t.me/technologique/750
https://t.me/technologique/551

Оливер Гоулд, CTO компании Buoyant, в интервью-подкасте от InfoQ, о проектах Conduit и LinkerD, организации сервисных шин для управления роем сверхлёгких (микро/нано) сервисов в контейнерных окружениях в IoT и Cloud Native инфраструктурах.

https://soundcloud.com/infoq-channel/oliver-gould-omicroservices-service-meshes-linkerd

https://www.infoq.com/podcasts/Oliver-Gould-microservices-linkerd-service-mesh

Ссылки по теме:
https://t.me/technologique/1200
https://t.me/technologique/1207

Kategory for Kotlin

Очень впечатляющий спич о фреймворке Kategory для Kotlin.

Extension functions и extension interfaces (KEEP-87) для поддержки type classes - будут введены в Kotlin для всех экосистем языка и в этом есть большая уверенность, потому что это кардинально изменит расклад сил в JVM экосистеме.
Что самое интересное - Kotlin хорошо совместим с Java и байт-кодом JVM и таким образом при введении в язык классов типов он вносит базовый элемент для создания настоящего продвинутого функционального программирования на JVM при полной совместимости с ней и всей экосистемой библиотек и фреймворков. Расширения Scala, scalaz и cats, а также диалекты Haskell для JVM, Eta и Frege, не позволяют достичь совместимости, т.к. используют нестандартные трюки с байт-кодом для реализации классов типов, монад и категорий.

https://www.youtube.com/watch?v=s9oMED6ZikQ&t=16m12s

#Kotlin

Про архитектурные паттерны с применением функционального программирования для проектирования приложений.

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

Nightly build удался! 525 модулей - легко! #NodeJS'сть!

#humorous_tech

Тенденции индустрии

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

Rust вновь, уже третий год подряд, занял первое место среди самых любимых разработчиками языков.
Следом за ним второе место занял Kotlin, который был впервые введён в индекс исследования в этом году.

https://insights.stackoverflow.com/survey/2018/#technology-most-loved-dreaded-and-wanted-languages

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

Другие тренды вы можете также посмотреть в данном исследовании - в нём очень много интересной информации!

#Rust #Kotlin

Опубликован roadmap для языка Rust и его экосистемы на этот год.

https://blog.rust-lang.org/2018/03/12/roadmap.html

Language improvements:

Ownership system improvements, including making borrowing more flexible via “non-lexical lifetimes”, improved pattern matching integration, and more.

Trait system improvements, including the long-awaited impl Trait syntax for dealing with types abstractly.

Module system improvements, focused on increasing clarity and reducing complexity.

Generators/async/await: work is rapidly progressing on first-class async programming support.

Долгожданные возможности, которые будут реализованы в этом году - статическая перегрузка имлементаций трейтов impl Trait (статическая диспетчеризация при возврате реализаций абстрактных типов описанных в трейтах, без необходимости их boxing'a и unboxing'a с выделением памяти в куче, что медленнее и дороже), которая ускорит исполнение кода и повысит производительность асинхронных библиотек (например Tokio), а также возможности асинхронного программирования на уровне языка, first-class async programming support, пожалуй самая долгожданная возможность, т.к. позволяет программировать многопоточный код (легковесные потоки, диспетчеры потоков и M:N thread-mapping на системные потоки) на базе сопрограмм и использовать асинхронный неблокирующий ввод-вывод на базе сопрограмм без применения сторонних библиотек.

#Rust

Метафизика программирования.

Многие годы идёт дискуссия о том, что есть программирование - искусство или только ремесло?
Для меня в первую очередь это инженерная дисциплина и профессия, для многих это ремесло (разработка софта).
Но эстетическое ощущение процесса творения не сравнимо ни с чем другим - поэтому программирование это искусство во многом. При этом нужно признать, что не у каждого творца (программиста) есть чувство прекрасного и не у всех оно развито в равной степени одинаково (после проведения code review это ощущается особенно остро - были даже рассуждения в духе https://www.youtube.com/watch?v=-a7unnF48t0&t=5m38s =) - поэтому чтобы быть лучшим программистом и совершенствовать свои навыки не так важно знать все технологии, методологии, концепции и паттерны, нужно совершенствовать своё сознание, работать над своим эстетическим ощущением окружающей дествительности и чувством прекрасного! Но при этом не нужно очень сильно погружаться в искусство программирования, ибо это страсть, а страстями сложно управлять (хаскелисты поймут о чём я говорю - всегда можно сделать код совершеннее, если есть множество очевижных и неочевижных, даже если вы голландец, способов сделать одно и то же решение правильно работающим, i.e. remind about syntactical diabet vs. syntactical sugar).

Я хочу сказать вам о том, что всем нам требуется работать над собой, развивать своё тонкое восприятие красоты. Многие находят отдушину в разнообразных хобби. Ваш покорный слуга и автор канала любит хорошее кино (желательно со сценарием по книгам), литературу в жанре киберпанк, электронную музыку (Trance) и читает блог Classic Programming Paintings 😉 (http://classicprogrammerpaintings.com/post/142321815809/hieronymus-bosch-a-visual-guide-to-the-scala).

В нашем канале вы можете найти не только посты о технологиях, но и о влиянии техногогий на форматирование техно-ноосферы человечества, о технологиях в дизайне, искусствте, литературе в жанре киберпанк, кино и даже о "тщете всего сущего"!

Связанные посты:
https://t.me/technologique/1039
https://t.me/technologique/1175
https://t.me/technologique/1180
https://t.me/technologique/1181
https://t.me/technologique/1182

The day when the Telegram stood still.

Сегодня европейский датацентр Telegram перестал быть доступен (якобы) из-за проблем с его энергообеспечением (т.к. это уже не первый сбой питания в датацентрах Telegram), что вызвало общий сбой и недоуступность мессенджера для пользователей по всему миру (в т.ч. в Азии и Америке).

https://outage.report/telegram#2018-03-29

https://twitter.com/telegram/status/979274718401515521

https://twitter.com/durov/status/979284965178400769

https://twitter.com/durov/status/979303818126135299

https://t.me/durov/75

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

Необходимо снижать зависимость инфраструктуры (компании, организации) от внешних сервисов и всегда иметь резервные сервисы и каналы связи на базе собственной self-hosted инфраструктуры - есть решения на базе self-hosted облачных сервисов, например плагины Spreed, реализующие полноценный обмен сообщениями, файлами и аудио-видео связсь (на базе WebRTC) и работающие на базе self-hosted облачной инфраструктуры NextCloud (альтернатива и форк OwnCloud):
https://apps.nextcloud.com/apps/spreed
https://github.com/nextcloud/spreed

https://apps.nextcloud.com/apps/spreedme
https://github.com/strukturag/nextcloud-spreedme/blob/master/README.md

У меня в свою очередь возникает другой вопрос - где же децентрализация сервер-сайд бэк-энд инфраструктуры Телеграм, обеспечиваемая также и его протоколом MTProto 2.0? Где отказоустойчивость и высокая доуступность?

https://twitter.com/andrcmdr/status/979324546334552064

#telegram

Истоки многопоточности в Rust.

Как и многие другие разработчики в экосистеме Rust я хотел бы видеть в Rust сопрограммы и продолжения на уровне языка и его ключевых слов (first-class coroutines and first-class continuations) с сохранением состояний (scopes, namespaces, lifetimes) на базе замыканий (closures), что более естественно в мире функционального программирования.

http://mttyng.com/closures-101/

Но то, что делается сейчас для реализации async/await макросов с их последующим внедрением на уровне языка в виде ключевых слов (или трейтов в stdlib) - реализуется на базе линейного "выпрямления" вложенных (call-back'ов) и рекурсивных вызовов функций посредством использования futures/promises и оптимизации хвостовой рекурсии с превращением рекурсивных вызовов в итераторы (итеративные вызовы), последовательные вызовы функций.

https://boats.gitlab.io/blog/post/2018-03-20-async-vi/

Базовая абстракция во многих языках для реализации сопрограмм и положений (call with current continuation - call/cc) - это замыкания (closures), которые пришли во многие языки из языка Lisp, но впервые были изобретены для цепочки вызовов ассемблерных подпрограмм.

Замыкание хранит состояние вызова функции (её локальную область видимости со всеми переменными и передаными в неё ссыклами на другие функции в качестве параметров или возвратами этих функций, call-back'ов) как её стэк вызова и восстанавливает его при повторном вызове функции - это используется для создания сопрограмм, продолжений и программирования в continuation passing style, для программирования многопоточного кода.
Поэтому в отличии от функций, которые всегда stateless, сопрограммы хранят промежуточные состояния вычислений, поэтому они stateful, как и акторы.
Это используется в CSP многопоточности.

Кстати, основное отличие CSP на базе сопрограмм от акторов на базе тех же сопрограмм главным образом не в том, что для сопрограмм сообщения передаются синхронно, а для акторов асинхронно, а в том, что в CSP каналы это отдельная абстракция, которая способна передавать сообщения через канал только синхронно, что делает асинхронный код более "линейным" и последовательным при его программировании, но работает такой код при этом асинхронно (наприер с вводом-выводом).
В свою очередь в акторах тоже есть отдельная абстракция для сообщений с виде mailbox'ов, которая способна принимать сообщения асинхронно и представлять их в виде последовательности сообщений (message queue).

Сопрограммы на базе замыканий реализованы в Kotlin, Go, JavaScript, TypeScript, Python, Lua и ещё многих языках.
Но не в Rust, т.к. в Rust есть проблема lifetimes of scopes/namespaces (времени жизни областей видимости переменных) - деструкторы (RAII), чтобы не было утечек памяти, сразу освобождают память при выходе потока исполнения кода из области видимости функции (impl's scope) и срабатывания умного указателя на финализатор и деструктор, поэтому любая область видимости всегда stateless и не хранит состояние достаточно долго (по причине финализации и вызова деструкторов для объектов хранящихся в куче, подобная концепция применена также в generational garbage collecting, автоматической сборке мусора в памяти на базе длительности времени жизни групп стэков вызовов сопрограмм, хранимых в памяти кучи как цепочки стэков вызовов подпрограмм на базе cactus-stack/parent-pointer tree), в результате чего корректно реализовать stateful сопрограммы (продолжения/continuations и continuation-passing style код) на базе замыканий в Rust очень сложно, поэтому чаще для реализации многопоточных сетевых приложений с асинхронным вводом-выводом используется модель акторов и future/promise трейты (как например в фреймворке Tokio) для реализации асинхронных вызовов в event-loop цикле.

Таковы ограничения концепций и особенности реализации управления памятью в Rust.

#Rust

Ссылки по теме:
https://t.me/technologique/1273
https://t.me/technologique/1263
https://t.me/technologique/1209
https://t.me/technologique/1207
https://t.me/technologique/1200

Анонс релиза второй версии языка Dart.

Буквально месяц назад состоялся официальный анонс второй версии языка Dart.

На данный момент Dart позволяет программировать код для всех платформ - server-side back-end сервисы исполняемые JIT компилятором DartVM, клиентские мобильные приложения для Android и iOS благодаря Flutter (DartVM с поддержкой SDK мобильных платформ) и клиентские веб-приложения благодаря транс-компилятору Dart2JS.
Это в свою очередь позволяет иметь максимально обобщённую кодовую базу проекта, с отдельными слоями сопряжения со средой для взаимодействия с платформой, и использовать таким образом максимально общую логику в приложениях для разных платформ.

https://medium.com/dartlang/announcing-dart-2-80ba01f43b6

https://news.dartlang.org/2018/02/announcing-dart-2-optimized-for-client.html

https://www.dartlang.org/dart-2

Во второй версии языка Dart и его среды исполнения кода DartVM будет использоваться новая система типов (в меньшей степени gradual typing, в большей flow-sensitive typing), со структурным статическим выводом типов на этапе компиляции (sounding type system) и минимальным динамизмом определения типов времени исполнения, в run-time (только для обобщенных generic типов).
Это в свою очередь повысит скорость исполнения кода в run-time, которая в версии Dart 1.x была сравнима с Node.js/V8 (около 10x раз медленнее кода на Си, по результатам синтетических тестов производительности - http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-fastest.html).

#Dart

Ссылки по теме:
https://t.me/technologique/1084