Высокая производительность *

3 факта о DS Proxima:
- L4 балансировщик с контролем состояния компонентов кластера на L7
- салатовый корпус, который светится в темноте
- уже в Реестре Минпромторга России

А 25 марта мы вместе с OCS Distribution приглашаем вас на вебинар, на котором расскажем, кому необходим балансировщик и какие задачи он решает, разберём сценарии внедрения и обсудим, каких зарубежных производителей смело можно импортозаместить.

Зарегистрироваться нужно тут, присоединяйтесь!

Через час подключайтесь к вебинару о сетевых дисках для выделенных серверов

В 12:00 мск начнем вебинар «Как работать с сетевыми дисками для выделенных серверов». Поговорим о новой фиче выделенных серверов Selectel — сетевых дисках. Обсудим ее с двух точек зрения — технической и продуктовой, а еще расскажем, как создавать сетевые диски и подключать их к серверам.

Смотреть на YouTube →

Смотреть во ВКонтакте →

Программа вебинара

• Введение в работу с сетевыми дисками: зачем они нужны и какое развитие ждет этот сервис;

• Архитектура сетевых дисков и демо подключения диска к хосту или группе хостов.

Кому будет интересно

• Системным администраторам;

• DevOps-инженерам;

• Техлидам.

Спикеры расскажут, как работают сетевые диски для выделенных серверов. Объяснят, как устроена архитектура сервиса, покажут подключение диска к хосту или группе хостов Proxmox, а также пример использования в частной виртуализации. Готовьте вопросы: эксперты обязательно на них ответят в конце вебинара.

Подключиться к трансляции →

Как не надо использовать Assert, если реализуете подход Design by Contract

Использовать Assert вместо if err != nil { return err}

Одно из неправильных применений Assert — это замена им проверки, которая действительно должна быть и на которую нужно реализовать реакцию в коде.

Выполнять вычисления при вызове Assert

Еще одна распространенная и трудно выявляемая ошибка — это выполнение вычислений и присваивание значений переменным прямо при вызове Assert, которые могут быть упразднены при оптимизации кода компилятором:

•  e.g. Assert(i++ > 0, “осторожно, не факт, что в релизе i увеличится”),

•  Assert(call_to_f1(), “осторожно, не факт, что call_to_f1() будет вызвана в релизе”).

Удалять Assert, несмотря на то, что это часть описания контракта

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

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

В реализации пакета Go 1.23 fmt-функция Printf всегда возвращает err = nil. И практически все игнорируют возвращающееся значение ошибки, тогда как могли бы проверять постусловие assertion.Assert (err == nil). Так, рано или поздно в последующих версиях можно научить код реагировать на err, отличный от nil.

Как правильно применять assertions, если реализуете подход Design by Contract для улучшения производительности кода в продакшене? Читайте в статье →

В начале года я опубликовал статью про гибридное кэширование.

Прошло уже больше месяца, а стабильная версия nuget-пакета Microsoft.Extensions.Caching.Hybrid так и не вышла.

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

Начну с последнего — каких изменений я не ожидаю

Изменение состава и сигнатур текущих методов. Если следить за выходом новых версий пакета Microsoft.Extensions.Caching.Hybrid, можно заметить, что методы объекта HybridCache не меняются уже давно. Из этого можно сделать вывод, что в стабильной версии мы увидим тоже самое, что наблюдаем сейчас.

Какие изменения я ожидаю увидеть

Удаление объекта из кэша по тегам. На момент написания статьи метод RemoveByTagAsync вообще не имел реализации. Сейчас в версии 9.2.0-preview.1.25105.6 он реализован и вполне себе работает, так что в релизную версию явно войдёт.

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

  await cache.GetOrCreateAsync(
    "someKey",
    async ct => await SomeFuncAsync("someKey", ct),
    options,
    ["tag1", "tag2", "tag3"],
    cancellationToken);

  await cache.GetOrCreateAsync(
    "someKey",
    async ct => await SomeFuncAsync("someKey", ct),
    options,
    ["tag1", "tag4"],
    cancellationToken);

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

И тут у меня два варианта развития событий: или логика поменяется и теги будут перезаписываться всегда — независимо от того, берётся объект из кэша или хранилища. Или при написании программы нужно будет следить, не передаём ли мы разные наборы тегов.

Microsoft создала первый в истории человечества квантовый чип на топопроводниках. Это фундаментальный прорыв в технике и физике.

Microsoft потратила 20 лет на исследования и создала новый класс материалов — топопроводники. Топопроводники создают новое состояние материи — не твёрдое, жидкое или газообразное, а топологическое. Топологические кубиты не ограничены законами термодинамики и электродинамики. С ними человечество сможет создать квантовый компьютер с миллионом кубитов — он сможет решать задачи, которые занимают тысячи лет даже на современных суперкомпьютерах. Это не просто исследование: у Microsoft уже есть рабочий чип на топопроводниках — Majorana 1.

Majorana 1 оснащён восемью топологическими кубитами. Компания планирует использовать его в исследованиях, которые в будущем позволят создать чип с 1 млн кубитов. Новый процессор производится Microsoft в США. Это стало возможным благодаря тому, что он выпускается в небольших объёмах. В компании считают, что квантовый чип появится в облаке Azure до 2030 года. Однако для этого чип должен иметь хотя бы несколько сотен кубитов.

«Слово о нагрузочном тестировании: курс на успешную миграцию»

📅 13 февраля, 16:00

А как тестируете вы?
📈13 февраля на онлайн-митапе обсудим преимущества и недостатки различных методов проведения нагрузочного тестирования. На примере реального кейса миграции СУБД представим нашу собственную методику оценки производительности информационных систем!

👨‍💻 Спикеры мероприятия:

— Роман Севрук, менеджер по развитию решений СУБД

— Александр Зубков, инженер по автоматизации нагрузочного тестирования

— Алексей Сатин, архитектор инфраструктурных решений

✅ Регистрируйтесь на онлайн-митап, чтобы узнать, как выбрать подходящий способ оценки производительности, минимизировать риски возникновения проблем и оптимизировать расходы на нагрузочное тестирование. 

PGConf.Russia 2025 ждёт доклады

Мы ищем тех, кто горит PostgreSQL так же, как и мы. Если вы администратор баз данных, разработчик, архитектор или DevOps-инженер, и в вашей работе PostgreSQL играет важную роль – нам есть что обсудить.

PGConf.Russia 2025 пройдёт 31 марта – 1 апреля в Центре международной торговли в Москве и онлайн. 

О чём рассказать?

Возможные темы для докладов на PGConf.Russia 2025:  

• Практический опыт администрирования PostgreSQL, оптимизация производительности и автоматизация задач.

• Архитектурные решения для обеспечения отказоустойчивости и масштабирования PostgreSQL: резервное копирование, восстановление, кластеризация, шардирование.

• Инструменты и методики эффективной миграции на PostgreSQL с других СУБД или устаревших версий.

• Опыт использования новых возможностей и расширений PostgreSQL, их применение и перспективы.

Почему сто́ит выступить?

PGConf.Russia 2025 — это:

• Большая аудитория. 1 500+ увлечённых профессионалов, готовых учиться, обмениваться опытом и задавать каверзные вопросы. 

• Признание и уважение. Ваш опыт ценен для сообщества. Выступление на PGConf.Russia – это возможность заявить о себе, повысить профессиональный статус и получить заслуженное признание.

• Бесплатное участие и размещение. Мы ценим вклад спикеров. Для докладчиков участие в конференции и размещение – за наш счёт.

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

Как подать заявку?

До 23 февраля 2025 года зайдите на сайт PGConf.Russia 2025 и нажмите кнопку «Подать доклад». Заполните название и аннотацию доклада, выберите формат, если нужно, оставьте дополнительный комментарий для программного комитета.

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

⚡️ ПОЧЕМУ JAVA ТАКАЯ БЫСТРАЯ?

Есть много языков, которые не компилируется в машинный код, а исполняются на виртуальной машине или интерпритаторе - C#, Python, JavaScript и так далее, но самый быстрый из них Java.

😮 Почему?
В начале 2000-х на рынке JVM существовало несколько ключевых игроков:

• Sun Microsystems HotSpot

• IBM J9

• Oracle JRockit

• Excelsior JET

Но в декабре 2006 года, с выходом Java 6, HotSpot вырвалась вперед, разгромив конкурентов, благодаря JIT-компиляции.

🤔 Как работает JIT?
Just In Time компиляция — это механизм, который компилирует часто исполняющиеся участки кода в машинный код во время выполнения программы, что значительно ее ускоряет.

Рассмотрим метод:

public void exampleMethod(int value) {
    if (value > 0) {
        // Исполняется часто
        System.out.println("Positive value");
    } else {
        // Исполняется редко
        System.out.println("Non-positive value");
    }
}

1. При первом вызове exampleMethod JVM интерпретирует байт-код

2. Если exampleMethod вызывается многократно с положительными значениями, JIT-компилятор определяет это как "горячую точку"

3. После достижения порога вызовов этой точки с условием value > 0 компилируется машинный код для метода

4. Если позже будет вызван метод с отрицательным значением (что не ожидалось), произойдет uncommon trap, и управление передастся интерпретатору для обработки этого случая

☕️ То есть, JVM в рантайме определяет путь, который чаще всего проходит программа, и именно этот путь компилируется нативно и максимально оптимизируется.

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

👨‍💻 Джуниор

Для точности ваших математических библиотек принимайте «Ульп». «Ульп» — и тесты не страшны!

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

Для этого достаточно договориться о единице измерения. Расстояние между соседними числами обозначается как 1 ульп (ulp — unit in the last place). Относительно него и будем оценивать погрешность вычисления математической функции. Поделим расстояние от результата до эталона на то, что является одним ульпом — то есть на расстояние от эталона до соседнего числа той же точности. Стандарт libm требует, чтобы ошибка не превышала 0,5 ульпа с учетом округления. 

Мы договорились о единицах измерения. Но остался еще один вопрос: с чем же мы сравниваем результаты? Откуда брать эталон в квазибесконечной точности? Здесь помогут системы компьютерной алгебры — прикладные программы для символьных вычислений и числовых операций произвольной точности.

Из таких систем ученые особенно любят Maple или Scilab, инженеры — Mathcad или Matlab, а разработчики — Sollya, поскольку эта библиотека имеет удобный C-интерфейс и ее можно вызывать прямо из тестов libm.

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

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

Читать статью →

Система управления проектами для удаленных команд Virex теперь доступна!

Коммуникация, задачи, аналитика, гибкость — всё это про Virex.

Система управления проектами Virex начинается с простоты. Все проекты в одном месте. Все ключевые данные, задачи и прогресс проекта одном экране.

Матрица задач в Virex гибкая. Вы можете настроить процесс работы под себя: бэклог, задачи в процессе и завершённые задачи — всё это легко управляется и визуализируется.

Лента активности Virex: больше не нужно искать, кто, что и когда сделал. Все изменения в проекте собраны в одном месте.

Встроенные чаты для каждого проекта. Общайтесь со своей командой прямо в Virex.

Заходите в Virex прямо сейчас!

https://app.virex.studio

Один из пользователей сервиса Highload.fun Joad Nacer прогнал все задачи через GPT O1 и получил интересный результат:

По 2024 году результат расположился на 20 месте с 3,574 очками, как я понимаю код был на C++. В целом нормально, но я, непрофессиональный кодер на C#, разместился на 23 месте, так что я бы оценил кодерство ИИ на уровне студента 1-го курса непрофильной специальности.

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

Корифеи мне конечно объясняли что мол приложению нужно "прокачаться" перед запуском и даже научили пользоваться бенчмарком для .NET, но забавность еще и в том, что на одной машине бенч может показывать одни результаты, а на другой - другие. И нет, я не про разницу в железе, а о том, что Метод1 на одной машине стабильно быстрее Метода2 на 10%, а на другом ПК - разница просто отсутствует.

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

Первая. Перестановка переменных местами:

int a = 0;
int b = 0;

и следом вариант

int b = 0;
int a = 0;

производительность меняется.

Вторая. Использование for/while:

for(int i = 0; i < 100; i++);
int i = 0; while(i < 100) i++;

еще с 90-х меня учили что в Си-подобных языках конструкции for/while по сути взаимозаменяемы, но в C# почему-то while в некоторых ситуациях оказывается быстрее.

Третья. Обнаружена пару дней назад:

int time = time * 10 + sec - 2;
sec++;

код выше работает медленнее чем

int time = time * 10 + sec++ - 2;

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

Раз в год-два мне приходится вспоминать, что Python — не C++.

В этот раз я наткнулся на случай, когда отформатировать и склеить колонки результата запроса на стороне PostgreSQL и распарсить Python-ом оказалось эффективнее, чем запрашивать колонки как отдельные значения.

Конкретнее, при переходе от этого запроса:

SELECT * FROM o_relations ORDER BY id DESC LIMIT %(limit)s

к этому:

SELECT CONCAT(entry_id::text, '|', tag_id::text) AS ids FROM o_relations ORDER BY id DESC LIMIT %(limit)s

скорость извлечения данных увеличилась примерно в 4 раза.

Причиной тому тяжёлая конвертация данных из формата С в формат Python внутри Psycopg.

За подробностями можно сходить ко мне в блог: https://tiendil.org/ru/posts/fun-case-of-speeding-up-data-retrieval-with-psycopg

50 оттенков кеширования: от in memory к многоуровневому redis-кластеру — Леонид Ченский / Ural Digital Weekend 2024

Опубликовали запись доклада секции «Разработка» с Ural Digital Weekend 2024.

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

Сначала Леонид кратко поговорил о проблеме быстрой отдаче сроков доставки. А далее о том, как c каждым годом они адаптировали архитектуру и какие решения для этого использовали.

Итерация 1: in memory cache.

Итерация 2: удаленный шардированный кэш-кластер (redis vs memmcached).

Итерация 3: N-уровневый кэш.

Итерация 4: шардированно-реплицированный multi-DC кэш-кластер Redis.

В конце выступления спикер подвел итог и поговорил об альтернативах KV.

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/2ik4N

В одной из недавних статей узнал про сайт HighLoad.fun, было интересно решить несколько задач и забраться в лидеры. Если кто-то любит highload задачи, то зову принять участие. Общался с автором проекта HL в телеграме - отзывчивый добродушный человек, планируется версия сервера 2.0 с новыми плюшками. Может и выглядит как реклама, но моя заинтересованность чисто спортивная, я решаю такие задачи сколько себя помню, это как кроссворды для меня, а без конкуренции нет желания улучшать результат. В секции C++ конечно соревновательный дух активнее, но я пишу на C# и там результатов не так много.

Как обрабатывать 5 млн изменяющихся форм в минуту с SLI 99.99% — Кирилл Грищук

Опубликовали запись доклада секции «Разработка» с Ural Digital Weekend 2024.

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

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/qHW9

Как мы сделали высокоскоростной RPC с помощью RDMA для собственного SDS — доклад на IT-конференции GoCloud Tech 🦾

На конференции GoCloud Tech расскажем, почему выбрали RDMA RoCE v2 — программный блок для потоковой передачи данных. Посмотрим на внутреннее устройство транспорта с позиции разработчика. Покажем, как изменилась производительность RPC между сервисами SDS. Обсудим недостатки и перспективы решения.

Приходите послушать доклад и обсудить тему в неформальной обстановке.

🕚 Когда: 24 октября с 17:40 до 18:05

📍 Где: онлайн и офлайн в Москве в лофт-пространстве Goelro

👉 Зарегистрироваться на GoCloud Tech

Полезное в блоге:

• Что нового слышно о шине CXL: заметки с саммита по вычислениям, памяти и хранению данных

• Математика прекрасного. Как создать красивую картинку, если ты дилетант, художник или нейросеть?

• Зачем нужна R&D-команда: взгляд разработчика

Новые курсы Яндекс Практикума для специалистов с опытом

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

«Эксплуатация и разработка в Kubernetes» — за 3 месяца освоите и примените на практике технологии оркестрации контейнеров. Программу составляли инженеры и тимлиды, которые давно работают с Kubernetes. Благодаря этому, вы будете учиться только тому, что на самом деле пригодится в работе. Ближайший старт — 17 октября.

«Apache Kafka для разработки и архитектуры» — 3-месячный курс для тех, кто хочет влиять на масштабируемость и надёжность систем. С этой технологией вы будете работать с более сложными продуктами и сможете повысить грейд. Есть бесплатная вводная часть. Ближайший старт — 21 ноября. 

«Архитектура программного обеспечения» — за 6 месяцев освоите лучшие практики архитектуры и научитесь решать сложные архитектурные задачи. Есть бесплатная вводная часть. Ближайший старт — 24 октября и 28 ноября.

«Мидл Android-разработчик» — 5-месячная программа для Android-разработчиков с опытом. Курс фокусируется на углублении технических навыков, изучении передовых паттернов и технологий, а также на освоении инструментов и методов, применяемых в реальных проектах. Ближайший старт — 14 ноября.

«Apache Kafka для разработки и архитектуры» — новый курс Яндекс Практикума

Навыки работы с Apache Kafka нужны всем, кто хочет влиять на масштабируемость и надёжность систем. На курсе «Apache Kafka для разработки и архитектуры» за 3 месяца вы научитесь использовать эту технологию, чтобы применять её в работе. 

Курс подойдёт специалистам с опытом: бэкенд-разработчикам, архитекторам, DevOps-инженерам и инженерам данных. Нужно знать Java, Python или Golang, понимать принципы работы с базами данных SQL и NoSQL, базово разбираться в архитектуре распределённых систем и уметь работать с Linux.

Преимущества курса:

• Обучение конкретно Apache Kafka, не в рамках более общего курса;

• Комплексное погружение в инструмент, а не просто знакомство с основами;

• Практические задания в каждом уроке и проекты по окончании спринтов;

• Воршкопы с экспертами, которые помогут разобрать наиболее сложные вопросы.

  Вы научитесь:

• Настраивать Apache Kafka для своих задач и оптимизировать производительность;

• Интегрировать Kafka с внешними системами;

• Работать с производителями и потребителями сообщений;

• Проектировать и реализовывать потоковые пайплайны данных;

• Обеспечивать надёжность и отказоустойчивость систем;

• Настраивать мониторинг кластеров Kafka и управлять им.

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

→ Узнать о курсе подробнее и начать обучение

Сергей Ким, руководитель команды разработки WMS и активный пользователь Яндекс Лавки, рассказал, про внутренний мир Лавок. 

Обсудили: 

• как Яндекс управляет лавками, узнаёт о товарных остатках и рассчитывает время курьеров, чтобы вовремя доставлять все заказы; 

• о чём можно узнать с помощью проактивных пушей изменений и периодического пула всего сразу;

• как перекладывать JSON с минимальным лагом. 

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

Фотонный процессор в России: что за чудо и с чем его едят?

РИА Новости сообщают, что к концу года в России завершат испытания фотонного процессора. Что в нём инновационного и реально ли ждать в нашей стране такое устройство?

Представьте, что вам надо послать сообщение и вы передаёте письмо «Камазом». Почему же не легковой машиной или даже по интернету? Сейчас с вычислительной техникой ситуация плюс-минус аналогичная — информация передаётся с помощью электронов, а ведь у нас есть частицы гораздо легче — фотоны. Массы покоя они вообще не имеют, а значит любые преобразования способны проводить быстрее. Теоретически. А ещё не будет потерь тепла на сопротивление. Вот и получается, что процессор, в котором вычисления проводятся не на электронах, а на фотонах, должен быть быстрее в десятки тысяч раз и с минимальным энергопотреблением.

Теория замечательная. Однако для фотонов придётся заново создавать вентили, которые смогут превращать их в нули и единицы и совершать с ними операции. Пока есть только тестовые образцы.

Сможет ли Россия обогнать весь? Материаловедение сейчас развивается во всём мире, и тот же Росатом вовсю работает над новыми материалами. Так что на данном этапе всё возможно. Тем более, что в этом году мы получим только прототип фотонного процессора со скромными характеристиками. К 2030 году российские учёные обещают разогнать его до 1000 экзафлопс при энергопотреблении в 10 000 раз ниже обычного. Звучит фантастично. А ведь потом встанет вопрос серийного производства...

Закрытие темы "Гипотеза о связи относительного количества ожиданий СУБД и производительности СУБД "

Отношение количества событий ожидания влияющих на производительность СУБД к количество событий ожидания не влияющих на производительность в ходе штатной работы СУБД будет примерно постоянное.

Для проверки гипотезы была проведёна серия экспериментов по 3-м сценарям:

1) Базовая(эталонная) нагрузка.

2) Дополнительная нагрузка на CPU/RAM.

3) Очередь ожидания освобождения блокировки строк/таблиц.

Итог: Гипотеза не подтверждается экспериментальными данными : разница в соотношении между ожиданиями составляет ~3% , при деградации производительности ~34%.

Или другими словами: соотношение между ожиданиями при работе СУБД, в общем случае, не зависит от нагрузки и производительности СУБД и остаётся примерно постоянным для конкретной СУБД.

Таким образом - изменение соотношения между ожиданиями СУБД не может являться индикатором деградации производительности.

Тема закрыта. Статья снята с публикации.

P.S. Однако, в ходе экспериментов, получен интересный побочный результат:

При использовании pgbench c параметром "--connect", отношение количества ожиданий влияющих на производительность, к количеству ожиданий не влияющих на производительность - существенно отличается (~38%).

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

Разверните базу данных на выделенном облачном сервере ⚡️

Преимущества DBaaS на выделенном облачном сервере

• Максимальная производительность,

• Экономическая выгода,

• Быстрый запуск,

• Безопасность.

Сделали все для максимальной производительности ваших баз данных

• Собрали конфигурации серверов с высокочастотным процессором Intel® Xeon® Gold 6240 в односокетной сборке с включенным Turbo Boost и Hyper-threading. 

• Используем специальные планки оперативной памяти ECC REG, рекомендуемые для СУБД.

• Для дополнительной отказоустойчивости добавили дисковую подсистему на сверхбыстрых NVMe SSD дисках компании Intel, собранных в RAID1.

• Оптимизировали настройки всех систем на сервере от BIOS до ОС.

Создайте базу данных →

К вопросу о важности определения понятия "производительность СУБД".

Пусть имеется некий запрос к СУБД, который важно мониторить с точки зрения эффективности и качества работы.

Сценарий 1: запрос выдает N1 строк и выполняется за время T1.

Сценарий 2: запрос выдает N2 строк и выполняется за время T2.

Вопрос: можно ли утверждать о инциденте в случае Сценария 2, если "T2 > T1 И N2 > N1" ?

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

Леонид Ченский про систему кэширования и топ-3 ошибок в кэшировании

Мы встретились с Леонидом Ченским, руководителем группы разработки в Ozon и спикером секции «Разработка» UDW2024. Леонид рассказала про обучение разработчиков, систему кэширования и топ-3 ошибок в кэшировании.

Ссылка на интервью: https://www.youtube.com/watch?v=yNuAjXKfcMg

Ural Digital Weekend 2024 — одна из крупнейших IT-конференций на Урале с насыщенной программой и аудиторией 400+ человек, организованная компаниями Spectr и Тэглайн. Билеты для посещения конференции уже могут приобрести все желающие на сайте Ural Digital Weekend 2024 — https://ural-digital-weekend.ru/. А по промокоду CHENSKYGIFT10 можно получить приятную скидку.

Надежность — не просто слово, а важное дело

Привет! С вами центр надежности Т-Банка, и мы приглашаем инженеров на SRE-митап.

Где: Москва, офис Space, ул. Грузинский Вал, 7
Когда: 29 июля в 19:00

На встрече вы узнаете:

• как не напрягаясь казаться надежнее, чем есть на самом деле;

• понять, что ест ресурсы в PostgreSQL и как это прекратить;

• построить хранилище логов, если Grep вы уже переросли.

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

О чем расскажут эксперты

Go: Раскрытие потенциала скорости

Я всегда борюсь за скорость. Началось это все с того, как я прочитал книгу “Грокаем алгоритмы” и меня заинтересовало измерение скорости выполнения. Потом, решая задачи на LeetCode я расстраивался, если алгоритм получался медленным. Недавно мне пришла идея написать пост на эту тему, а во время написания изучить этот вопрос получше. Я прочитал не мало статьей, большинство из которых - англоязычные.Так что вот советы по увеличению скорости Вашего приложения на Golang :

1. Выделять ёмкость для среза с помощью make

При создании среза выделяйте ёмкость с помощью make, так Вы избавитесь от перераспределений

2. При возвращении указателя, объявлять его при создании переменной

 func (r Ruleset) Match(path string) (*Rule, error) {
 	for i := len(r) - 1; i >= 0; i-- {
		rule := r[i] //так НЕ надо
		rule := &r[i] //так надо
 		match, err := rule.Match(path)
 		if match || err != nil {
			return &rule, err //так НЕ надо
			return rule, err //так надо
 		}
 	}
 	return nil, nil
}

3. Пишите бенчмарки

Пишите бенчмарки для вашего приложения, так Вы поймете, в каком месте оно работает медленнее всего. Источник для того, чтобы научиться писать бенчмарки: https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go и др.

4. Используйте горутины!

Когда есть возможность, используйте горутины. Например, когда результат 2-х операций не зависит друг от друга, можете использовать горутины. Думаю, доказывать, что таким образом приложение становится быстрее, не надо :)

Привет! Мы проводим SRE Week — открытый интенсив по теме Site Reliability Engineering от Школы анализа данных и экспертов Yandex Infrastructure. 

О чём интенсив

Site Reliability Engineering — область, посвящённая эксплуатации больших и нагруженных компьютерных систем. Если вы хотите делать сервисы, способные выдерживать значительные нагрузки и работать на большом количестве железа, вам придётся столкнуться и с вопросами эксплуатации. 

Программа интенсива

На интенсиве будет пять лекций и один семинар, занятия пройдут с 17 по 22 июня.

На лекциях:

• посмотрим на поломки больших систем, общие принципы, статистику аварий и разберём конкретный инцидент;

• научимся производить диагностику одного сервера и определять ограничения по железу, так как большие системы строятся из отдельных серверов;

• изучим опасности, которые могут поджидать в протоколе, связывающем отдельные серверы, и освоим средства диагностики распределённых систем; 

• обсудим, из чего состоит ежедневная работа в эксплуатации и как организована работа в команде. 

На семинаре:

• научимся настраивать ядро Linux для повышения производительности; 

• разберём на практике несколько реальных проблемных ситуаций, для диагностики которых воспользуемся утилитами с лекций.

Как принять участие

Для участия в интенсиве зарегистрируйтесь по ссылке. Регистрация открыта до 16 июня. Для получения доступа к итоговому практическому заданию нужно пройти отбор до 22 июня и сдать задание до 3 июля. Тем, кто успешно справится, будет выдан сертификат.

Разбор доклада Артёма Арутюняна про Архитектуру и Реактивное Программирование

Топ перлов:

• Реактивное программирование - это программирование на событиях.

• Реактивность нужна между модулями, а внутри - не нужна.

• По одному лишь графу связей можно понять правильно произведена декомпозиция или нет.

Мета: Копилка благодарностей, Новости, Форум

Или я плохо ищу или действительно , тема корреляционного анализа производительности СУБД , еще не исследовалась.

Например было бы очень интересно установить - какой из факторов оказывает максимальное влияние на производительность СУБД или наоборот - как производительность СУБД влияет на показатели СУБД и инфраструктуры :

• Количество соединений

• Утилизация CPU

• Утилизация RAM

• Утилизация I/O

• Количество ожиданий СУБД

• Показатели CPU (iowait и т.п)

• Показатель Cache Hit Ratio

• Объем обработанных блоков shared_buffer

• Что-то еще из огромного списка метрик

Блогер GPU Tester проверил работоспособность бюджетной видеокарты Nvidia GTX 1060 с 6 ГБ видеопамяти в современных играх в разрешении Full HD на ПК с процессором AMD Ryzen 7 7700X с 32 ГБ ОЗУ DDR5 6000 МГц.

Игра Call of Duty Modern Warfare II на сбалансированных настройках в среднем работает при 76 кадрах в секунду, а Apex Legends на ультранастройках удалось достичь 103 FPS. Шутер Counter‑Strike 2 на высоких настройках показал 145 FPS.

Требовательная Starfield показала средний результат в 25 FPS при вручную подобранных настройках графики, Star Wars Jedi: Survivor и Hogwarts Legacy на низких и средних настройках соответственно показали 33 FPS и 43 FPS. Игра Plague Tale Requiem и Dying Light 2 Stay Human на ультра- и средних настройках графики показали 47 FPS и 54 FPS соответственно, Cyberpunk 2077 на индивидуальных настройках показал 44 FPS, а God of War — 56 FPS.

Видеокарта Nvidia GeForce 1060 была представлена в 2016 году. На сегодняшний день это очень бюджетное решение, которое можно купить в России в среднем за 12 тыс. рублей.

infra.conf 4 июня: обсудим с разработчиками кейсы создания и эксплуатации высоконагруженных систем

Команда Yandex Infrastructure 4 июня проведёт конференцию про создание инфраструктуры и эксплуатацию высоконагруженных систем. Встретимся в Москве и в онлайн‑эфире, чтобы поговорить про платформенную разработку, базы данных и облачные технологии, тестирование и безопасность, ML‑инфраструктуру и опенсорс‑решения.

Только практика от крупных компаний: Авито, Иннотех, Альфа‑Банк, Selectel, СберМаркет и SberDevices, Postgres Pro, Лаборатория Касперского и др.

Среди уже объявленных спикеров:

• Борис Литвиненко, Yandex Infrastructure: расскажет о том, как удобно жить на железе в 2К24 базовой инфраструктуре, о пути сетевого пакета и о специфике обслуживания этой части инфраструктуры. В финале вместе сделаем своё облако с DPDK и попытками преодолеть проблемы монолитной инфраструктуры.

• Дарья Николаенко, Тинькофф: в докладе «Потребитель и железка. Где связь?» расскажет про неочевидные и хитросплетённые зависимости масштабной инфраструктуры и их влияние на выполнение и постановку рабочих задач, а также поделится опытом визуализации и систематизации инфраструктурных компонентов.

• Виктор Корейша, Ozon Tech: расскажет о проектировании собственной S3 поверх Ceph, а также о проблемах, возникших при разработке, миграции и эксплуатации на реальной нагрузке. И, конечно, покажет пути решения и поделится результатами.

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

В Китае в продажу поступил ноутбук MSI Titan 18 Pro в версии 192 ГБ ОЗУ и SSD накопителем на 4 ТБ.

За производительность устройства отвечает 24-ядерный процессор Intel Core i9–14 900HX с 32 потоками, а также мощная видеокарта Nvidia GeForce RTX 4090. Энергопотребление системы достигает 250 Вт.

Ноутбук имеет 18» Mini‑LED экран с разрешением 3840×2400 пикселей и с частотой обновления изображения 120 Гц, а также охватом цветового пространства DCI‑P3 на 100%. Заявленная яркость экрана составляет 1000 нит.

Среди прочих особенностей отмечается наличие аккумулятора ёмкостью 99,9 Вт*ч, 6 динамиков, Wi‑Fi 7 и различных портов для подключения внешних устройств, в том числе двух USB‑C с поддержкой Thunderbolt 4, двух USB-A 3.2 Gen 2 и HDMI 2.1.

В Китае MSI Titan 18 Pro в версии на 192 ГБ и 4 ТБ продаётся за 39,6 тыс. юаней (около 500 тыс. рублей).

1 мая стартует новый формат соревнований на HighLoad.Fun, который напомнит вам о первых HighLoad CUP от Mail.Ru в 2017 и 2018 годах.Смысл соревнования написать HTTP сервер на любом языке программирования который реализует API описанный с помощью Swagger'а, запаковать в Docker контейнер и загрузить в registry платформы, где произойдёт тестирование. Чьё решение быстрее и без ошибок обработает входящий поток запросов — победит.

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

Ссылка на соревнование: https://highload.fun/timed_competitions/authserver

Гендиректор Nvidia Дженсен Хуанг (Jensen Huang) лично доставил свой новый флагманский ускоритель DGX H200 в офис компании OpenAI в Сан-Франциско, подчеркнув тесную связь между двумя гигантами в отрасли искусственного интеллекта.

Хуанга встретили соучредитель OpenAI Грег Брокман и гендиректор компании Сэм Альтман.

DGX H200 – это новейший ускоритель ИИ-вычислений Nvidia, оснащенный 141 ГБ памяти HBM3e. Производитель позиционирует это решение как самый мощный ИИ-ускоритель Nvidia, знаменующий шаг вперёд в области технологий ИИ с производительностью в 1 экзафлопс.

«Много ядер» не имеет смысла

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

Вот тут описывается опыт использования в разных конфигурациях. Вкратце: из‑за поставленного ограничения на тепловыделение в 350 Вт процессор не использует всю имеющуюся у него мощь, так что работа всего на 16 ядрах оказывается равносильна работе на всех 96. Процессор просто сбрасывал скорость при достижении предельного тепловыделения. Нагрузка была в виде сборки всего проекта Хромиум. Плюс ко всему, потребовалось значительно больше памяти, для того, чтобы сборка в принципе работала на таком большом количестве ядер. Для использования всей мощности автору пришлось делать специальную конфигурацию машины.

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

По своему опыту могу сказать: на старенькой машинке Атлон II x4 (2009г) Хромиум собрался за ~40 часов.

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

Метод исследования основан на процессе одновременной и гетерогенной многопоточности (SHMT). Он задействует различные типы процессоров, содержащиеся в современных компьютерах: графический, центральный и тензорный (для работы технологий ИИ).

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

Тестовая установка включала ЦП ARM Cortex-A57, GPU Nvidia и тензорный процессор Google Edge. Благодаря одновременной и гетерогенной многопоточности выполнение расчёта примера кода прошло в 1,95 раза быстрее, а потребление энергии сократилось на 51%.

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

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

Какая облачная конфигурация нужна для работы 1С в связке с PostgreSQL и Microsoft SQL Server

По опыту, нередки 4 варианта:

1. Сервер 1С и managed БД на разных ВМ. Получаем отказоустойчивость и хороший уровень изоляции. Но скорость коммуникации между серверами зависит от сети, особенно, если ВМ в разных зонах доступности.

2. Сервер 1С и ВМ с БД на разных ВМ. У каждой из ВМ полный доступ к ресурсам, что даёт производительность для требовательных задач и возможности тюнинга.

3. Сервер 1С и БД на одной ВМ. Вся обработка данных — на одной машине, что устраняет задержки сети.

4. Сервер 1С и БД на одной ВМ, временные таблицы БД — на RAM‑диске. Так можно ускорить обработку данных, т.к. операции чтения/записи в RAM быстрее, чем на традиционных дисках. Это сокращает время отклика при выполнении операций на временных таблицах.

   Конфигурацию можно оптимизировать:

   • В Microsoft SQL вынести tempdb на RAM‑диск. Если допустимо, рассмотреть вынос других служебных таблиц.

   • Настроить параметры Delayed Durability, Max degree of parallelism, размер автоувеличения файлов БД, shared memory. Если важна персистентность, настроить периодический сброс данных, например, в ImDisk Virtual Disk Driver.

   • В PostgreSQL вынести временные таблицы на RAM‑диск для ускорения обработки, настроить nr_hugepages для сокращения расходов памяти.

   При оценке производительности этой конфигурации тест Гилёва показал более 42 баллов.

На вебинаре 12 марта вместе с «Первым Битом» разберём эти сценарии миграции в облако, дадим рекомендации. Подключайтесь.

В новосибирском Академгородке запустили суперкомпьютер «Сергей Годунов», который назван в честь советского и российского математика с мировым именем.

Монтаж и тестирование системы выполнили специалисты из группы компаний РСК. Оборудование для реализации проекта суперкомпьютера было приобретено на грант, предоставленный Минобрнауки РФ и направленный на обновление приборной базы ведущих научных организаций, в рамках федерального проекта «Развитие инфраструктуры для научных исследований и подготовки кадров» нацпроекта «Наука и университеты».

Суперкомпьютер «Сергей Годунов» создан на основе передовой платформы «РСК Торнадо» с использованием жидкостного охлаждения. Каждый узел системы оснащён двумя процессорами Intel Xeon Ice Lake-SP, имеющими по 38 ядер и работающими на частоте 2,4 ГГц. В момент введения в эксплуатацию общая производительность кластера достигла 54,4 Тфлопс.

Планируется увеличить производительность более чем в два раза, до 120,4 Тфлопс. И.о. директора ИМ СО РАН Андрей Миронов отметил, что новый суперкомпьютер поможет существенно повысить эффективность научных исследований и будет способствовать развитию новых технологий.

Планируемые задачи для новой системы:

• медицинская электроакустическая томография;

• вычислительная аэрогидродинамика и оптимизация турбулентных потоков;

• моделирование сценариев развития системы биосфера-экономика-социум;

• решение обратных задач геофизики прямым методом на основе подхода Гельфанда — Левитана.

Дайджест продуктовых обновлений за январь ?

В начале года мы постарались сохранить немного праздничного настроения и выпустили несколько важных апдейтов. Среди них — свежие серверы на базе Mac mini®, обновленная версия Kubernetes 1.29: Mandala, улучшения в безопасности аккаунтов и другие фичи по заявкам.

Подробнее об апдейтах читайте в полной версии дайджеста ?

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