Серверная оптимизация *

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

Привет, Хабр! Меня зовут Дмитрий Гоголев, я менеджер по развитию CMP-платформы Cloudlink. Участвую в интеграции нашего ПО у заказчиков и разработке новых фич.

Мы в Orion soft каждый день общаемся с компаниями, которые ищут замену привычным решениям для виртуализации. Однако далеко не всегда (а, точнее, почти никогда) переход на новое происходит легко и быстро. Решения класса Cloud Management Platform (CMP) упрощают этот процесс. Они дают возможность управлять разнородной облачной инфраструктурой через единый интерфейс. 

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

Когда бизнес-аналитика внедряется как корпоративный инструмент, ее пользователями становятся сотни или даже тысячи людей из разных подразделений. Кроме этого нередко результаты прогнозов, расчетов и визуализаций все чаще выкладывают прямо на порталы или открывают к ним доступ без авторизации, чтобы сторонние наблюдатели могли получить важную для себя информацию. Все это порождает проблемы конфиденциальности, которые раньше решались с помощью дублирования данных и создания нескольких контуров BI. Но, как говорится, «есть способ лучше»! Сегодня мы поговорим про механизм Row Level Security (RLS), который позволяет и BI предложить сразу всем, и доступ разграничить, и не плодить личные сущности. Ну а подопытным, которому мы будем ограничивать доступ в наших примерах, как вы уже догадались, будет Александр Сергеевич.

Привет, Хабр! Меня зовут Евгений Старков, и я, как и вы, часто сталкиваюсь с техдолгом.

Пришло время рассказать, как я с ним справляюсь! Проблема не нова и встречается в любой компании, связанной с разработкой. Мне, по большей части, техдолг достался «в наследство». Первой задачей в Тензоре было разделение и рефакторинг большой части кодовой базы своей группы. Там попадались и суперклассы, и файлы с количеством строк, перевалившем далеко за 1000, и именование переменных по типу a, b, c.

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

serde — основной фреймворк для сериализации и десериализации в Rust. Его используют как крейт по умолчанию во всей экосистеме. serde_json — это официальный serde-миксин для JSON, так что каждый раз, когда нужно что-то парсить, люди обращаются именно к нему. Конечно, есть и другие библиотеки, специализующиеся на парсинге JSON, например simd-json, но популярность у них, мягко говоря, удручающая. serde_json значительно популярнее: на момент написания от него зависят аж целых 26916 крейта, а от simd-json — всего 66.

Это делает serde_json хорошей мишенью (не как у Jia Tan) для оптимизаций. Велик шанс того, что многим из тысяч пользователей переход на simd-json позволил бы добиться ускорения, но, пока они этого не делают, более мелкие оптимизации — лучше, чем совсем ничего, и такие улучшения — глобальный выигрыш для экосистемы.

Примечание: основная часть изложенного в статье относится к реализации SMT компании Intel, также называемой гипертредингом (hyper-threading). Она основана на научной статье компании, опубликованной в 2002 году.

Привет, Хабр! Сегодня мы поговорим о том, почему BI-платформам нужен движок, какие сложности создает ClickHouse для аналитиков, когда речь действительно заходит о больших данных, зачем нужно оптимизировать SQL и о многих других вещах, которые часто остаются «за горизонтом» в дискуссиях о BI и хранении данных. Говоря другими словами, я хочу рассказать о том, как мы разрабатывали ДанКо — новый движок, который лежит сегодня в основе Visiology 3, а главное — каким образом ДанКо позволяет достичь высокой производительности в аналитических задачах (в некоторых случаях показывая ускорение вплоть до х100)! Эта статья будет полезна тем, кто еще не сталкивался с задачей организации хранения аналитических данных компании, а также интересна тем, кто как раз, наоборот, уже делал это.

Привет, Хабр!

Очень важно не только писать хороший код, но и использовать все возможности инфраструктуры на максимум. Именно с этой целью в этой статье рассмотрим, как правильно использовать инструменты кэширования внутри Kubernetes и как настроить CDN для максимума производительности Python-приложения.

Самая распространённая конфигурация из мануалов по настройке:
gunicorn --workers 3 wsgi:app

Какое количество воркеров оптимально?
Считается формулой: (Количество ядер процессора)*2+1

А также, у Sync воркеров есть Gthread класс:
gunicorn --workers 5 --threads 2 wsgi:app
Указывая параметр тредов, воркеры автоматически становятся класса Gthread.

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

Здесь нам и помогут кастомные сборщики мусора.

Недавно VMware раскрыла информацию о том, когда наступит end of general support VMware vSphere 7.0, которой сейчас пользуется большая часть рынка. Это произойдет 2 апреля 2025 года. После этой даты для пользователей больше не будет доступных обновлений и патчей продукта, в том числе по информационной безопасности, а поддержка прекратится, когда подойдет к концу срок действия сертификата на нее.

Мы в Orion soft разобрались, что значит конец VMware для российских компаний, с какими последствиями столкнутся те, кто остается на версии 7.0, и что делать, чтобы их избежать.

Многие, наверняка, сталкивались с мемом this is fine, или оригинальным комиксом. Так выглядит типичный день для многих дежурных сотрудников. Оперативные дежурные получают много оповещений, и работа со слишком большим количеством оповещений может привести к усталости от оповещений — чувству истощения, вызванному реагированием на оповещения, которые не имеют приоритета или четких действий. Убедиться в том, что оповещения действенны и точны, а не являются ложными срабатываниями, крайне важно, потому что если дежурные сотрудники постоянно получают ложные уведомления, они могут перестать обращать на них внимание и игнорировать даже важные сообщения. С этой целью в Cloudflare многочисленные команды проводят периодический анализ оповещений, каждая команда разрабатывает свои собственные панели мониторинга для отчетности.

Привет, Хабр! Меня зовут Александр Гавриленко, я занимаюсь интеграциями продуктов в инфраструктурах заказчиков Orion soft. За последние 2 года количество задач, связанных с организацией устойчивой виртуальной инфраструктуры на 2 и более территориально распределенных ЦОДа (со связностью L2), значительно выросло.

Поэтому сегодня я хочу начать разговор про обеспечение катастрофоустойчивости ИТ-инфраструктуры, построенной на базе zVirt. В этой статье я расскажу про поддержку технологии метрокластера, но не в теории, а на практике. В лаборатории Orion soft был собран тестовый стенд с реально работающей схемой резервирования Active-Active. А под катом вы найдете не только полезные схемы и рекомендации, но также результаты тестирования катастрофоустойчивой конфигурации.

Отправляем запрос на 20 000 000 евро, на перестановку 900 ордеров на бирже. Что может пойти не так? 

Сегодня я расскажу, как не терять пару миллиардов клиентских денег, когда уж очень нужно что-то массово сделать на бирже. Этот текст про неявную и, казалось бы, незаметную проблему, которая ждет нас в недрах работы с любыми запросами, которые могут исполниться не до конца – в частности, с HTTP-запросами. Удивительно, как мало об этой проблеме думают и насколько мало инструментов для её решения. 

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

В повествовании будут клиенты, серверы и котики. С котиками всегда интереснее.

Сегодня поговорим о lock-free (или же без использования блокировок) структурах данных и атомарных операциях в Rust.

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

lock-free структуры данных позволяют нескольким потокам одновременно читать и изменять данные без блокировок.

Часть 1

В этой части я приведу ещё несколько примеров того, как нам мешает скачивание обновлений внутри приложений.

Пример 1: обновления macOS

Ни для кого не секрет, что обновления macOS огромны. Иногда это раздражает даже дома, но на Южном полюсе ситуация гораздо хуже.

Размер патча минорного обновления macOS обычно имеет размер от 0,5 до 1,5 гигабайтов. Патчи с крупными обновлениями иногда занимают до шести с лишним гигабайтов. Дополнительные инструменты, например Xcode, часто весят несколько гигабайтов.

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

Привет, Хабр! Меня зовут Кирилл, и я — архитектор инженерных систем в «Инфосистемы Джет». «При чем тут машинное обучение?» — спросите вы. Действительно, применимость ML к инженерной инфраструктуре — направление более чем свежее, и на Хабре еще никто эту тему не поднимал (кажется!).

Но сначала я расскажу предысторию. Инженерная инфраструктура в большинстве случаев является критически важной для функционирования дата‑центра. Ее безотказная работа — основной критерий при разработке проекта будущего ЦОД. Повышение энергоэффективности и надежности эксплуатации — не менее важная проблема, будоражащая умы инженеров на протяжении последних лет.

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

Часть этого поста я написал, всё ещё находясь в Антарктиде, но уеду, ещё не закончив его.

Я просматривал свои старые черновики постов и понял, что этот почти завершён.

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

В течение 14 месяцев работы в Антарктиде доступ в Интернет у меня был только через крайне ограниченное число спутниковых каналов, предоставленных Антарктической программой США (United States Antarctic Program).

В начале поста нужно дать особое примечание:

Хотя я был ИТ-сотрудником United States Antarctic Program, всё, о чём я буду говорить в этом посте, основано или на публично доступной информации, или на моих личных наблюдениях как обычного участника программы, живущего во льдах.

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

При приёме на работу я подписал условия, ограничивающие публичное раскрытие непубличной информации о материалах, связанных с информационными технологиями. Я намерен полностью соблюдать эти ограничения. Такие ограничения типичны для сдельной работы на правительство США.

Маловероятно, что я смогу ответить на дополнительные вопросы по темам, обсуждаемым в этом посте. Я тщательно старался писать максимально подробно, не допуская при этом раскрытия непубличной информации о правительственных ИТ-системах.

Данная информация отражает мой личный опыт нахождения в Антарктиде с августа 2022 года по декабрь 2022 года в Мак-Мердо, а затем с декабря 2022 года по ноябрь 2023 года на Южном полюсе.