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

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

Предыстория

Уже пару лет я собираю коллекцию одноразовых вейпов, полученных от друзей и членов семьи. Поначалу я только извлекал аккумуляторы для «будущих» проектов (это точно не синдром Плюшкина), но в последнее время одноразовые вейпы стали гораздо более продвинутыми. Не хотел бы я быть юристом, которому придётся доказывать, что устройство с разъёмом USB C и перезаряжаемым аккумулятором можно классифицировать, как «одноразовое». К счастью, в ближайшее время я не планирую подаваться в юриспруденцию.

В прошлом году я разбирал одну из этих технологичных сосок для взрослых и заметил нечто любопытное: вместо обычной чёрной капли, которой заливают ASIC (Application Specific Integrated Circuit), я увидел небольшую интегральную схему с маркировкой «PUYA». Не буду винить читателей, если это название не вызвало у вас того же восторга, что и у меня — большинство людей никогда его не слышало. Эта компания больше всего знаменита своими флэш-чипами, но впервые я узнал о них из поста Джея Карлсона о самом дешёвом флэш-микроконтроллере. Это довольно мощные крошечные микроконтроллеры ARM Cortex-M0+.

За последний год у меня скопилось довольно много таких одноразок с PY32; это были разные модели вейпов одного производителя. Я не буду бесплатно рекламировать табачный бренд, но выражу благодарность проектировщику за маркировку на отладочных контактах!

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

Привет! С вами Кабанов Олег — ведущий ML-инженер Flocktory.

В этой статье расскажу об опыте внедрения YandexDB в качестве хранилища для ML Online Feature Store. А также о том, как нам удалось ускорить загрузку данных в 40 раз и убрать влияние на скорость чтения данных при обновлении.

Привет, Habr! На связи эксперты команды сервиса WatchDog — Дмитрий Коновалов и Геннадий Переломов.

В ВТБ, у нашего основного заказчика, мы развиваем сервисы автоматизации сопровождения баз данных. Одной из ключевых СУБД в инфраструктуре является PostgreSQL. Поддержка её в актуальном состоянии требует периодических мажорных обновлений, которые остаются одной из самых трудоёмких задач для DBA, особенно в ночные или выходные технологические окна.

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

Этот небольшой этюд служит как бы продолжением статьи "Проценты использования процессора — это ложная метрика". Мы попытаемся копнуть чуть поглубже и более детально разобраться как работает гиперпоточность (или гипертрединг, как его иногда называют).

По работе я постоянно имею дело с серверами; при этом их владельцы всегда хотят знать, когда серверы используют свои ресурсы максимально. Вроде бы, это простая задача? Достаточно настроить top или другой инструмент мониторинга системы, посмотреть на процент использования сети, памяти и CPU, и наибольшее значение покажет, насколько близко сервер находится к пределу своих возможностей.

Например, эта машина потребляет 50% ресурсов CPU, поэтому, вероятно, способна выполнять вдвое больше своих задач.

Однако когда владельцы пытаются реально проецировать эти значения, то оказывается, что процент использования CPU на самом деле растёт не совсем линейно. Но насколько непрямой может быть зависимость?

Чтобы ответить на этот вопрос, я выполнил кучу стресс-тестов, мониторя при этом объём выполняемых ими работы и отображаемый системой уровень использования CPU, а затем по результатам построил графики.

Команда Go for Devs подготовила перевод статьи о том, как оптимизировать использование памяти в Go-приложениях. Автор делится двадцатью приёмами — от выбора ресивера метода и правильной инициализации slice до кастомного управления памятью и профилирования с pprof. TL;DR: мелкие улучшения складываются в заметный прирост производительности и стабильности.

Привет, Хабр! Systemd — скелет современного Linux. Он управляет не только службами, но и таймерами, монтированием, логированием... Понимать его = значительно повысить эффективность администрирования системы.

Данное руководство — исключительно технические аспекты: архитектура, юниты, cgroups, работа с журналами. Только команды и конфиги.

Привет, Хабр! На связи Виталий, дежурный системный инженер дата-центра в Selectel.

Продолжаем тему, поднятую в наших предыдущих публикациях, где мы говорили об уплотнении серверов линейки ChipCore и усмирении Ryzen^TM в мини‑корпусе. Сегодня углубимся в специфику размещения по‑настоящему мощного оборудования. Напомню, нашей главной целью было эффективно использовать стандартные 19‑дюймовые серверные стойки для размещения систем, собранных из высокопроизводительных десктопных компонентов. Очевидно, что для решения этой задачи, разработки собственного корпуса не избежать.

В отличие от прошлых проектов, появилась новая особенность — железо экстремальной производительности с потребляемой мощностью, значительно превышающей стандартные показатели TDP в 180 Вт. Конфигурации на базе процессоров Intel^_® Core^TM i9-13900K или AMD Ryzen^TM 9 7950X с 128 ГБ памяти DDR5 и быстрыми NVMe-накопителями по 2 ТБ — настоящие «печки». Было изначально понятно, что без жидкостной системы охлаждения (СЖО) в этот раз не обойтись.

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

Меня зовут Ескендиров Мурат, я — архитектор сайта в Ви.Tech, IT-дочке ВсеИнструменты.ру. В этой статье расскажу, как мы строили сервис для выдачи карточек товаров, обрабатывающий до 5 миллиардов запросов в сутки, какие архитектурные решения приняли и с какими проблемами столкнулись в процессе. Расскажу, какие решения сработали, а какие до сих пор остаются нашей головной болью.

Сайт «ВсеИнструменты» имеет почти 20-летнюю историю, и, как это часто бывает, за это время он превратился из маленького сайта с парой сотен товаров на PHP, созданного «на коленке», в гигантский монолит с несколькими миллионами уникальных номенклатур.

Несколько лет назад перед сайтом встали в полный рост проблемы, характерные для многих компаний, выросших из «подпартного» стартапа (первый свой заказ компания «ВсеИнструменты.ру» получила во время лекции в МФТИ, тогда один из основателей для его оформления залез под парту) в многомиллиардную корпорацию:

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

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

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

В отличие от старого доброго clickjacking с iframe, здесь никто ничего поверх не накладывает. Всё хитрее: страница сама превращается в ловушку. Менеджер паролей видит поле логина и честно вставляет туда пароль. А пользователь (ну то есть мы с вами) жмёт на кнопку и уверен, что всё нормально. На самом деле клик улетает в невидимый элемент, и данные — вместе с ним. Честно говоря, когда я это увидел на демо, стало немного не по себе.

Есть три главные причины, почему расширения ведутся на такой обман. Во‑первых, некоторые из них слишком доверчиво вставляют пароль сразу, без всякого подтверждения. Во‑вторых, они проверяют только домен верхнего уровня. А если у сайта есть хитрый поддомен — привет, уязвимость. И в‑третьих, далеко не все разработчики заморачиваются с CSP, поэтому любой внедрённый скрипт может вытворять с DOM что угодно.

Проверить страницу самому несложно. Открываете DevTools, смотрите на элементы. Если видите кучу строк с opacity:0 или position:absolute; left:-9999px — повод насторожиться. В Chrome во вкладке Layers это особенно хорошо видно. Для любителей автоматизации есть и короткий скрипт на JavaScript, который подсветит такие штуки.

Всем привет, меня зовут Денис Лимарев, я руковожу разработкой в одной из продуктовых команд Uzum Tezkor. В этой статье разберу несколько оптимизаций запросов к БД, которыми наша команда пользуется при разработке своих сервисов, и опишу подход к оптимизациям запросов в целом. В своих проектах мы используем PostgreSQL версии 14.15, поэтому все запросы я проанализировал на ней, и ваши результаты могут отличаться в зависимости от вашей версии.

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

Как обрабатывать миллионы строк в PHP и не убить память?

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

Когда‑то безопасность строилась вокруг простого правила: если ты внутри сети, значит «свой». Ставим фаервол, заворачиваем трафик в VPN, прикручиваем IDS — и вроде всё под контролем.

Сегодня этот подход разваливается. Удалёнка, подрядчики, BYOD, фишинг — периметр размазан. Атакующему не нужно ломать фаервол: достаточно украсть логин и пароль через поддельную форму входа. И вот он уже «свой».

Истории из ИБ‑практики:

Под катом – анимация, демонстрирующая сборку приложения для macOS в режиме реального времени:

Я расскажу, как она получилась, но для начала обрисую контекст этого проекта.

Компиляция конкретного софта может быть очень длительной просто потому, что в этой программе очень много кода — как, например, в проекте LLVM. Но бывает и так, что сборка идёт медленно по глупым и вполне устранимым причинам. Подозреваю, что большинство сборок просто тормозят из-за ерунды, но проверить это мне пока не удавалось. Поэтому я разработал кроссплатформенный инструмент для визуализации сборок (пока он существует в приватной бета-версии, ссылка в конце статьи). Он работает с любой системой сборки и с любым языком программирования (а не только C/C++/Rust).

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

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

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

Как всё началось

Обычный рабочий день. Я проверял список процессов на сервере (ps aux) и вдруг вижу:

```bash

sshpass ‑p 'Qwerty123' ssh admin@10.0.5.21

Пароль. В открытом виде. В командной строке.

Подошёл к коллеге...