Вчера (8.11.2023) мы выпустили релиз фреймворка компьютерного зрения Savant с номером 0.2.6. Этот выпуск включает в себя множество исправлений ошибок, семь новых демонстрационных пайплайнов и ряд других улучшений, включая документацию, производительность и поддержку Nvidia Jetson Orin Nano.

Savant пересек отметку в 300 звезд на GitHub, и Discord наконец-то стал более активен, что нас сильно радует. Работа над релизом заняла 1.5 месяца. В следующих разделах мы подробно рассмотрим релиз более детально.

В этой статье я хочу рассказать о том, как я проектирую комплексные расширения для Python на Rust с использованием PyO3 и почему я принимаю те или иные проектные решения.

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

Мы рады представить вам новую версию Savant - 0.2.5. Мы работали над этим релизом более 2,5 месяцев. Он содержит значительные изменения, новые возможности и исправления ошибок в нескольких областях, но в первую очередь мы улучшили возможности для разработчиков и варианты развертывания.

После месяца напряженной работы мы выпустили новую версию Savant (0.2.4), с новыми функциями и примерами использования.

Savant — это фреймворк компьютерного зрения с открытым исходным кодом для создания приложений компьютерного зрения на базе нейронных сетей, работающий на стеке Nvidia. Он упрощает разработку динамических, отказоустойчивых конвейеров видео‑аналитики, использующих рекомендованные Nvidia инструменты для центров обработки данных и граничных ускорителей.

Savant построен на базе DeepStream и предоставляет высокоуровневый уровень абстракции для быстрой разработки конвейеров компьютерного зрения на базе Nvidia DeepStream.

В статье рассматривается новый открытый фреймворк для потоковой видеоаналитики и демонстрируются его возможности на примере демонстрационного приложения, которое использует модель DeepStream’s PeopleNet для обнаружения людей и их лиц, размывает лица и отображает панель управления с помощью OpenCV CUDA.

Мы будем использовать Savant для обработки видео в реальном времени с протоколом RTSP и для обработки видеофайлов в пакетном режиме, чтобы продемонстрировать, как конвейер может достигать скорости 400 кадров в секунду на Nvidia Tesla T4.

Для тех, кто хочет сначала попробовать без подробностей, мы подготовили скрипты для быстрого старта на основе Docker Compose (раздел "Быстрый старт").

Savant на GitHub: https://github.com/insight-platform/Savant

Nvidia DeepStream - широко известный в узких кругах инструмент для инференса на нейронных сетях и другой высокопроизводительной обработки видео-потоков в реальном времени на оборудовании от Nvidia.

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

В одном из наших проектов используется Edge-модуль, работающий на широком наборе оборудования c процессором ARM, типа Raspberry Pi. Данное устройство используется для того, чтобы пересылать медиа-данные посредством зашифрованного канала на сервер.

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

У меня возникла задача настроить отказоустойчивый Bare Metal кластер для комплексного приложения, в связи с чем и возникла данная статья. Сразу хочу сказать, что не являюсь экспертом в K8S, однако имею опыт развертывания продуктовых кластеров DC/OS (экосистемы, основанной на Apache Mesos).

Долгое время K8S меня отпугивал тем, что, при попытке его изучения, тебя закидывают кучей концепций и терминов, отчего мозг взрывается.

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

Disclaimer: Я не специалист в нейросетях, но выполняю роль владельца продукта, в котором ключевую роль занимают нейросетевые модели компьютерного зрения. Эта статья для тех, кто вынужден делать такую же работу, а так же для тех специалистов ML, которые хотят понять, как на их деятельность смотрят люди со стороны бизнеса.

TL;DR; настройка режима работы системы охлаждения сервера Supermicro Optimal не обеспечивает стабильность работы LSI-контроллера MegaRAID 9361-8i в холодном ЦОД-е.

Мы стараемся не использовать аппаратные контроллеры RAID, но есть у нас один клиент, который предпочитает именно конфигурации c LSI MegaRAID. Сегодня мы столкнулись с перегревом карты MegaRAID 9361-8i в связи с тем, что платформа не чувствовала перегрева, а RAID-контроллер его чувствовал.

Добрый день. В этой статье я расскажу, далеко не в первый раз, как на Raspberry Pi 3 и более слабых платформах одновременно детектировать движение и сохранять/транслировать видео в формате H264. Я поделюсь с такими же новичками в мире Raspberry Pi, как и я, о том, что узнал сам за несколько дней, пока разбирался в способах решения задачи. Говорить буду о работе с камерой Raspberry Pi простым человеческим языком.

Здравствуйте, написать эту статью меня побудил мой опыт участия в open-source проекте Apache Cloudstack, куда я периодически отправляю фичи и багфиксы. Меня нельзя назвать активным контрибьютором, поскольку я вношу вклад лишь время от времени, когда мне что-то требуется от продукта или я нахожу баг, от которого моему кластеру "зудит".

Опыт, описанный в этой статье — сугубо личный, причем характерный именно для продукта Apache Cloudstack.

Всем привет. Мы разрабатываем продукт для анализа оффлайн-трафика. В проекте есть задача, связанная со статистическим анализом путей движения посетителей по областям.

В рамках этой задачи пользователи могут задавать системе запросы следующего вида:

• сколько посетителей прошло из области "A" в область "Б";
• сколько посетителей прошло из области "A" в область "Б" через область "C", а затем через область "Д";
• сколько времени заняло прохождение посетителя определенного типа из области "А" в область "Б".

и еще ряд подобных аналитических запросов.

Движение посетителя по областям представляет собой направленный граф. Почитав интернеты, я обнаружил, что графовые СУБД используются и для аналитических отчетов. У меня появилось желание посмотреть как будут справляться с подобными запросами графовые СУБД (TL;DR; плохо).

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

Преамбула

Мы эксплуатируем облако средних размеров, которое строим на типовых серверах следующего конфига — 32 ядра, 256 GB RAM и NVMe накопитель PCI-E Intel P4500 размером 4TB. Нам очень нравится эта конфигурация, поскольку она позволяет не думать о недостатке IO, обеспечив корректное ограничение на уровне типов инстансов (экземпляров) VM. Поскольку NVMe Intel P4500 обладает впечатляющей производительностью, мы можем одновременно обеспечить как полное предоставление IOPS машинам, так и резервное копирование хранилища на сервер резервных копий с нулевым IOWAIT.

TL;DR: рассказываю о задаче оценки вклада сотрудника в общий результат и новой open source системе проведения круговой оценки сотрудников, разработанной в нашей компании, на базе метода оценки 360 градусов.

Здравствуйте, меня зовут Иван Кудрявцев — я технический директор и совладелец компании, которая занимается контрактной разработкой. В 2016 году мы начали разрабатывать систему поощрения достижений для инженеров.

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

• разработчик ⟶ руководитель проекта;
• сотрудник ⟶ топ-менеджер;
• участник проекта ⟶ клиент.

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

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

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

В последние два года мы широко используем Docker как для разработки, так и для выполнения систем в производственной среде, и все текущие продукты для наших клиентов разрабатываются именно с учетом данной системы контейнеризации. Стоит отметить, что Docker достаточно сильно изменяется от версии к версии, добавляя как дополнительные возможности (Swarm, Compose), так и дополнительные инструменты повышения защищенности и контроля приложений.

В данной статье рассматривается подход к интеграции Apache CloudStack (ACS) со сторонними системами посредством экспорта событий в брокер очередей сообщений Apache Kafka.

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

После моих первой и второй статей об Apache CloudStack ко мне обратился пользователь с вопросом о том, как организовать высокодоступный управляющий сервер ACS с использованием Galera. Ранее я не использовал такую топологию развертывания, но по этому поводу решил попробовать выполнить такую настройку.

В статье описывается метод развертывания отказоустойчивой конфигурации управляющих серверов Apache CloudStack совместно с мультимастер-кластером MariaDB (Galera).

По роду своей деятельности мне достаточно часто приходится участвовать в проектах, в которых создаются высокодоступные, высокопроизводительные системы для различных рынков — реклама, финтех, сервисы классов SaaS, PaaS. В таких системах применяется вполне устоявшийся набор архитектур и компонентов, которые позволяют эффективно обеспечить соответствие продукта требованиям, например, lambda-архитектура для поточной обработки данных, масштабируемый микросервисный дизайн программного обеспечения, ориентированный на горизонтальное масштабирование, noSQL СУБД (Redis, Aerospike, Cassandra, MongoDB), брокеры сообщений (Kafka, RabbitMQ), распределенные серверы координации и обнаружения (Apache Zookeeper, Consul). Такие базовые инфраструктурные блоки чаще всего позволяют успешно решить большую часть задач и команда разработки не сталкивается с задачами разработки компонентов среднего уровня (middleware), которые, в свою очередь, будут использованы бизнес-ориентированной частью разрабатываемой системы.