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

Всем привет. Данная статья не более чем эксперимент. Тем более, что сейчас есть тренд на запуск баз данных в контейнерах т.к. это действительно производительнее и нет лишнего оверхеда в сравнении использования технологий, которые используют виртуализацию. Во многих статьях есть поле манипуляций — это выводы на основе одного бенчмарка или когда надо доказать и обосновать, что принятое решение самое лучшее. В рамках статьи будет проверка работы clickhouse запускаемый в qemu‑kvm, firecracker, containerd.

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

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

groups = [[] for _ in range(n_groups)]

for element in elements:

groups[element.group].append(element)

Он и в самом деле линеен (то есть асимптотически оптимален), и мы всё равно должны выполнять доступ к произвольным индексам, так что кэш здесь нам ни в чём бы не помог.

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

Здравствуйте. Меня зовут Олег Юрченко.

Здесь моя рецензия на эту книгу: «Клеппман М. Высоконагруженные приложения. Программирование, масштабирование, поддержка. — СПб.: Питер, 2018.»

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

Содержание книги соответствует второй части оригинального названия «Designing Data‑Intensive Applications. THE BIG IDEAS BEHIND RELIABLE, SCALABLE, AND MAINTAINABLE SYSTEMS».

Можно утверждать, что многие «THE BIG IDEAS BEHIND...» рассмотрены с подробной библиографией. А вот название перевода вводит в заблуждение каждым словом. В книге только идеи, а не это вот всё.

Но главной идеи в книге нет. Мартин Клеппман не знает про основной способ устранения зависимости нагрузки на сервер баз данных от размера базы данных, главной проблемы с быстрорастущими базами данных. Эта идея важнее всего написанного в этой книге, я её объясню с примером из моей практики.

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

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

Сначала про способ решения проблемы быстрорастущих данных, а потом мои комментарии по трём главам книги. 

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

Недавно я писал статью - что такое 50% cpu? На системах с hyperthreading 50% cpu по метрикам означает, что большая часть ресурсов сервера уже использована. То есть cpu>50% - это уже "желтая зона", и мы ожидаем замедление всего, чего можно. Но я никогда не думал до экспериментов, что падение может быть столь катастрофическим.

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

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

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

Redis — хранилище из семейства нереляционных (NoSQL) баз данных. Redis является очень быстрым хранилищем данных благодаря своей архитектуре in-memory. Он идеально подходит для задач, требующих быстрого доступа к данным, таких как кэширование, очереди сообщений, сессионная информация и многое другое. Go также известен своей высокой производительностью за счет компиляции в машинный код и эффективного управления памятью.

Привет, Хабр! Не так давно столкнулся с задачей разработки альтернативного решения для ограничения сетевого трафика. Такая задача возникла в рамках разработки системы лицензирования для продукта класса NGFW (Next Generation Firewall). Используя такую систему ограничений можно было бы предусмотреть несколько видов лицензий на коммерческое использование продукта, где в зависимости от уровня приобретенной лицензии можно было бы предоставлять полную, либо урезанную функциональность продукта в части его производительности. В этой статье хочу поделиться опытом решения данной задачи.

Около трёх лет у меня возникали проблемы с моим обучающим сайтом Mess With DNS: периодически у него заканчивалась память и он перезагружался по OOM.

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

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

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

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

Если у вас на машине стрелочка показывает, что у вас осталась половина бака, то у вас точно осталась половина бака? На самом деле больше, так как современные машины врут и топлива еще немного есть, даже когда стрелка на нуле - забота об альтернативно одаренных водителях. А если сервер показывает 50% cpu, то сколько ресурсов у нас осталось?

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

Когда был создан SMTP, он работал, передавая данный в открытом виде, поскольку тогда мы ещё не разработали решение для безопасной передачи данных, то, что мы называем сейчас «безопасность транспортного уровня» (transport layer security, TLS). Когда TLS наконец-то был готов, нам потребовалось придумать способ поэтапного внедрения TLS. Был создан STARTTLS, предлагающий шифрование «по возможности». По сути, почтовый сервер отправителя мог спросить почтовый сервер получателя: «Поддерживашь ли ты шифрование?», и, если ответ был положительным, устанавливалось TLS-соединение с использованием сертификата, предоставленного сервером. Если нет, использовалось SMTP-соединение с передачей данных в открытом виде.

Любой, кто знаком с темой сетевой безопасности, увидит здесь проблему. Активно действующий злоумышленник, осуществляющий атаку «атакующий посередине» (attacker-in-the-middle, AitM), может подставить свой собственный ответ, указывая, что шифрование не поддерживается, и обманом заставить отправителя использовать открытый текст, что позволит злоумышленнику перехватывать сообщения. Это классическая атака понижения версии.

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

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

• Уязвимость к hash flooding.
• В случае защиты от hash flooding случайными seed порядок итераций становится недетерминированным, что мешает при тестировании снэпшотов, создании воспроизводимых сборок и так далее.
• При вставке может требоваться рехэширование, что в наихудших случаях создаёт для больших хэш-таблиц ужасные задержки.
• Многократное увеличение больших распределений памяти без фрагментации сложно реализовать в целевых платформах wasm, потому что трюки с виртуальной памятью недоступны, а для страниц невозможно выполнить unmapping.
• Векторные команды в wasm ограничены, а команды AES отсутствуют. Это делает многие хэш-функции ещё более медленными.

Статья про то как заставить работать React Server Components внутри Electron приложения с помощью Next.js при этом не запуская локальный сервер и не открывая порты. С возможностью публикации стандартными инструментами. А также исследование зачем все это надо.

Когда создаешь новое приложение, особенно если оно должно быстро обрабатывать данные, использование библиотеки asyncio — это хороший выбор. Она позволяет работать с неблокирующими библиотеками, asyncpg и aiohttp. Однако чаще всего программисты работают с уже существующим кодом, который использует блокирующие библиотеки. Поэтому большую часть времени может занять адаптация и модернизация старого кода, так как асинхронный код не дружит с синхронным (им мешает GIL).

GIL (Global Interpreter Lock) — это механизм, который предотвращает одновременное выполнение нескольких потоков в Python. Это означает, что даже если у вас есть многопоточное приложение, только один поток может выполнять Python-код в любой момент времени. Поэтому можно запускать дополнительный поток для выполнения операции ввода-вывода.

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

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

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

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