Всем привет. Меня зовут Нещадин Иван, и я расскажу про оптимизацию одного из микросервисов Авито на Go. История построена вокруг различных инструментов, которые доступны в языке, и пойдёт от простых примеров к более сложным.

Постановка задачи

Сделать Wi-Fi в 2+ комнатной квартире, при этом чтобы скорость в любой локации была не ниже 90Мбит/с на любом современном мобильном устройстве (IEEE 802.11ac).

Предполагаем, что наша типовая квартира содержит типовой набор пользователей:

1. Условный Просто пользователь (используем базовый ЯндексDNS)
2. Условная Боящаяся интернета бабушка (ЯндексDNS, без мошеннических сайтов и вирусов)
3. Условный Студент 5 курса, которому нужен Интернет без ограничений (выход в Интернет через VPN в Европу, DNS 8.8.8.8)
4. Условный Школьник 7 класса, которому по административным причинам надо выключать Интернет в 21:00 час по будням и в 22:00 часа по выходным (используем ЯндексDNS «Семейный» и по расписанию выключаем/включаем SSID).

Радио моделирование

Начну с того, что как правило, если в квартире бетонные стены и количество комнат 2 и более, то одной точкой доступа Wi-Fi будет не обойтись, ведь 20 Мбит/с на диване у окна сегодня нас уже не устраивают, а это значит что минимальный уровень сигнала на клиенском устройстве долже быть не ниже -65дБ.

Вот пример:
Ставим одну точку доступа в прихожей, в 5 ГГц диапазоне зона покрытия до -65дБ выглядит так:


Поэтому надо добавить еще как минимум 2 точки доступа, получаем следующее:




Так уже лучше, с количеством и расположением точек доступа определились.

Долго искал книгу, в которой было бы разжёвано, как использовать FFmpeg-подобную библиотеку, известную как libav (название расшифровывается как library audio video). Обнаружил учебник «Как написать видеоплеер и уложиться в менее чем тысячу строк». К сожалению, информация там устаревшая, так что пришлось создавать мануал своими силами.

Большая часть кода будет на C, однако не волнуйтесь: Вы легко всё поймёте и сможете применить на любимом языке. У FFmpeg libav уйма привязок ко многим языкам (в том числе и к Python и к Go). Но даже если Ваш язык прямой совместимости не имеет, всё равно можно привязаться через ffi (вот пример с Lua).

Начнём с краткого экскурса о том, что такое видео, аудио, кодеки и контейнеры. Затем перейдем к ускоренному курсу, посвященному использованию командной строки FFmpeg, и, наконец, напишем код. Не стесняйтесь переходить сразу в раздел «Тернистый путь изучения FFmpeg libav».

Есть мнение (и не только моё), что потоковое интернет-видео уже приняло эстафету от традиционного телевидения. Как бы то ни было, FFmpeg libav точно достоин изучения.

Оглавление

• Вступление
  • Видео — это то, что ты видишь!
  • Аудио — это то, что ты слышишь!
  • Кодек — сжатие данных
  • Контейнер — удобный способ хранения аудио/видео
• Командная строка FFmpeg
  • Инструмент в виде командной строки FFmpeg 101
• Основные операции над видео
  • Транскодирование
  • Трансмультиплексирование
  • Трансрейтинг
  • Трансайзинг
  • Бонус: адаптивный стриминг
  • Выходя за рамки
• Тернистый путь изучения FFmpeg libav
  • Глава 0 — простенький «Hello World»
    • FFmpeg libav архитектура
    • Требования
    • Собственно, код
  • Глава 1 — синхронизация аудио и видео
  • Глава 2 — ремультиплексирование
  • Глава 3 — транскодирование
    • Трансмультиплексирование
    • Транскодирование

Привет! Хочу познакомить вас с проектом Rust Embedded. Он позволяет нам использовать язык программирования Rust для разработки под встроенные платформы (Embedded Linux / RTOS / Bare Metal).


В этой статье, мы рассмотрим компоненты, которые необходимы для начала разработки под микропроцессоры Cortex-M3. После этого напишем простой пример — моргание встроенным светодиодом.

Несколько недель назад в разговоре за обедом коллега пожаловался на какой-то медленный процесс. Он подсчитал количество сгенерированных байт, количество циклов обработки, и в конечном счёте, объём оперативной памяти. Коллега заявил, что современный GPU с пропускной способностью памяти более 500 ГБ/с съел бы его задачу и не подавился.

Мне показалось, что это интересный подход. Лично я раньше не оценивал задачи производительности с такой стороны. Да, я знаю о разнице в производительности процессора и памяти.



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

Часть 1. Общий алгоритм поиска

Введение

Поиск пути — это одна из тех тем, которые обычно представляют самые большие сложности для разработчиков игр. Особенно плохо люди понимают алгоритм A*, и многим кажется, что это какая-то непостижимая магия.

Цель данной статьи — объяснить поиск пути в целом и A* в частности очень понятным и доступным образом, положив таким образом конец распространённому заблуждению о том, что эта тема сложна. При правильном объяснении всё достаточно просто.

Учтите, что в статье мы будем рассматривать поиск пути для игр; в отличие от более академических статей, мы опустим такие алгоритмы поиска, как поиск в глубину (Depth-First) или поиск в ширину (Breadth-First). Вместо этого мы постараемся как можно быстрее дойти от нуля до A*.

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

Этот цикл статей опубликован выложен на GitHub. Если у вас какие-то вопросы или проблемы, открывайте там соответствующий тикет. Все исходники для статьи лежат в этой ветке.

Ещё одна статья о страничной организации памяти?
Если вы следите за этим циклом, то видели статью «Страничная память: продвинутый уровень» в конце января. Но меня раскритиковали за рекурсивные таблицы страниц. Поэтому решил переписать статью, применив иной подход для доступа к фреймам.

Первая часть
Вторая часть

Тема сегодняшнего разговора — работа с памятью. Я расскажу про инициализацию директории страниц, маппинг физической памяти, управление виртуальной и мою организацию кучи для аллокатора.

Как я уже говорил в первой статье, я решил использовать страницы размером 4 МБ, чтобы упростить себе жизнь и не иметь дела с иерархическими таблицами. В дальнейшем я надеюсь перейти на страницы размером 4 КБ, как большинство современных систем. Я мог бы использовать готовый (например, такой блочный аллокатор), но написать свой было чуть интереснее и хотелось чуть больше понять, как живет память, так что мне есть, что вам рассказать.

Первая часть

Первая статья еще не успела остыть, а я решил не держать вас в интриге и написать продолжение.

Итак, в предыдущей статье мы поговорили о линковке, загрузке файла ядра и первичной инициализации. Я дал несколько полезных ссылок, рассказал, как размещается загруженное ядро в памяти, как соотносятся виртуальные и физические адреса при загрузке, а так же как включить поддержку механизма страниц. В последнюю очередь управление перешло в функцию kmain моего ядра, написанного на Rust. Пришло время двигаться дальше и узнать, насколько глубока кроличья нора!

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

Я решил написать статью, а если получится — то и серию статей, чтобы поделиться своим опытом самостоятельного исследования как устройства Bare Bone x86, так и организации операционных систем. На данный момент мою поделку нельзя назвать даже операционной системой — это небольшое ядро, которое умеет загружаться из Multiboot (GRUB), управлять памятью реальной и виртуальной, а также выполнять несколько бесполезных функций в режиме многозадачности на одном процессоре.

При разработке я не ставил себе целей написать новый Linux (хотя, признаюсь, лет 5 назад мечтал об этом) или впечатлить кого-либо, поэтому особо впечатлительных прошу дальше не смотреть. Что мне на самом деле захотелось сделать — разобраться, как устроена архитектура i386 на самом базовом уровне, и как именно операционные системы делают свою магию, ну и покопать хайповый Rust.

В своих заметках я постараюсь поделиться не только исходными текстами (их можно найти на GitLab) и голой теорией (ее можно найти на многих ресурсах), но и тем путем, который я прошел, чтобы найти неочевидные ответы. Конкретно в этой статье я расскажу о компоновке файла ядра, его загрузке и инициализации.

Мои цели — структурировать информацию у себя в голове, а так же помочь тем, кто идет похожим путем. Я понимаю, что аналогичные материалы и блоги уже есть в сети, но чтобы прийти к моему текущему положению, мне пришлось долго собирать их воедино. Всеми источниками (во всяком случае, которые вспомню), я поделюсь прямо сейчас.

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

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными

Привет! Меня зовут Макс Матюхин, я работаю в SRV-команде Badoo. Мы в Badoo не только активно пишем посты в свой блог, но и внимательно читаем блоги наших коллег из других компаний. Недавно ребята из Dropbox опубликовали шикарный пост о различных способах оптимизации серверных приложений: начиная с железа и заканчивая уровнем приложения. Его автор – Алексей Иванов – дал огромное количество советов и ссылок на дополнительные источники информации. К сожалению, у Dropbox нет блога на Хабре, поэтому я решил перевести этот пост для наших читателей.

→ Часть 1. Kali Linux: политика безопасности, защита компьютеров и сетевых служб
→ Часть 2. Kali Linux: фильтрация трафика с помощью netfilter
→ Часть 3. Kali Linux: мониторинг и логирование
→ Часть 4. Kali Linux: упражнения по защите и мониторингу системы

Представляем вашему вниманию продолжение перевода главы 7 книги «Kali Linux Revealed». В прошлый раз речь шла о политиках безопасности и о защите компьютеров и сетевых служб. Этот материал включает в себя перевод раздела 7.4, который посвящён файрволу и фильтрации пакетов.

Впервые про программируемый логический контроллер по имени CONTROLLINO мне довелось узнать году еще в 2014-м в случайной переписке с человеком, который подбирал себе ПЛК для домашней автоматизации. Я ему рекомендовал какие-то классические модели, а он в ответ сообщил, мол, видел на кикстартере некий интересный проект под названием CONTROLLINIO. Это промышленный ПЛК, который программируется так же, как Arduino, в его родной IDE.

Тот парень работал php-программером и С++ был для него не проблема. Деньги и идеи имел, а желания изучать LAD или Codesys нет. В итоге отписался, что сделал предзаказ на CONTROLLINO и больше на связь не выходил.

Не знаю, что и как у него вышло в конце концов, а вот мне через 3 года выпало поработать с этим девайсом.

Привет, Хабр! Встала передо мной недавно задача: настроить максимально надежный кластер серверов PostgreSQL версии 9.6.

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

Планируя кластер я проштудировал много статей, как из основной документации к PostgreSQL, так и различных howto, в том числе с Хабра, и пробовал настроить стандартный кластер с RepMgr, эксперементировал с pgpool.

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

В итоге где-то (уже не вспомню точно где) нашел ссылку на прекрасный проект Zalando Patroni, и все заверте…

Мы продолжаем перевод и озвучку Мессенджеровский лекций Нобелевского лауреата по физике Ричарда Фейнмана, которые он прочитал в Корнеллском университете в 1964 году.

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

Всего в курсе 7 лекций, с предыдущими можно ознакомиться здесь.

В этом эссе описана схема работы Git. Предполагается, что вы знакомы с Git достаточно, чтобы использовать его для контроля версий своих проектов.

Эссе концентрируется на структуре графа, на которой основан Git, и на том, как свойства этого графа определяют поведение Git. Изучая основы, вы строите своё представление на достоверной информации, а не на гипотезах, полученных из экспериментов с API. Правильная модель позволит вам лучше понять, что сделал Git, что он делает и что он собирается сделать.

Текст разбит на серии команд, работающих с единым проектом. Иногда встречаются наблюдения по поводу структуры данных графа, лежащего в основе Git. Наблюдения иллюстрируют свойство графа и поведение, основанное на нём.

После прочтения для ещё более глубокого погружения можно обратиться к обильно комментируемому исходному коду моей реализации Git на JavaScript.

Мы рады представить бету NGINX Amplify, нашего нового инструмента для мониторинга NGINX и NGINX Plus. Используя NGINX Amplify, вы сможете отслеживать и контролировать NGINX и приложения, которые он обслуживает. Новый инструмент позволит быстро решать проблемы с производительностью и доступностью отдельных сервисов и инфраструктуры в целом. На текущий момент он включает в себя гибко настраиваемую панель мониторинга с механизмом оповещений, а также систему автоматических рекомендаций по оптимизации производительности и улучшению безопасности.

Узнать больше и увидеть NGINX Amplify в действии можно записавшись на онлайн вебинар, который пройдет 13 июля в 20:00 по московскому времени.

Также, вы можете начать бесплатно использовать NGINX Amplify прямо сейчас, пройдя регистрацию.

Если вы пытаетесь оптимизировать производительность Вашего основанного на PostgreSQL приложения, Вы наверняка пользуетесь базовыми инструментами: EXPLAIN (BUFFERS, ANALYZE), pg_stat_statements, auto_explain, log_statement_min_duration, и т.д.

Возможно Вы смотрите в сторону конфликтов блокировок с помощью log_lock_waits, следите за поведением ваших контрольных точек и т.д.

Но задумывалились ли Вы о задержках в сети? Игроки знают о ней, но имеет ли это отношение к Вашему серверу с приложением?

Архитектура процессоров Intel становится все более ориентированной на ГП, что открывает удивительные возможности для резкого повышения производительности просто за счет разгрузки обработки мультимедиа с ЦП на ГП. Существует немало инструментов, доступных разработчикам для повышения производительности мультимедиа приложений. В числе этих инструментов есть бесплатные и простые в использовании.
В этой публикации вы найдете:

• Обзор вычислительных архитектур и текущие возможности ГП Intel
• Реализацию аппаратного ускорения с помощью FFmpeg
• Реализацию аппаратного ускорения с помощью Intel Media SDK или аналогичного компонента Intel Media Server Studio (в зависимости от целевой платформы)