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

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

Всё начинается с потребности в быстродействии и масштабируемости. C несколькими потоками можно обрабатывать больше операций одновременно.

В этой статье мы рассмотрим, как синхронизировать потоки в Java.

Доброго времени суток, харбачитатель.

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

Привет, Хабр. На связи Михаил, я бэкенд-разработчик в Clevertec. Моя работа связана с проектом, который начинался с создания личного кабинета клиента и развился в экосистему, растущую вместе с бизнесом. На его примере я расскажу, как можно изменять подход к CI/CD, чтобы не тормозить рост проекта и оптимизировать работу команды.

Привет! Меня зовут Антон Васильев, я работаю инженером технической поддержки компании Arenadata и нередко сталкиваюсь с довольно каверзными задачами и багами. Одной из них была проблема оптимизации механизма UPSERT в Greenplum 6. В этой статье я хочу рассказать, как эта задача может быть решена.

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

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

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

Привет! Меня зовут Паша Сушин. Уже больше десяти лет я занимаюсь в Яндексе развитием платформы YTsaurus — нашего внутреннего инструмента, который в марте 2023 года вышел в опенсорс и теперь доступен всем на GitHub по лицензии Apache 2.0. 

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

Есть у нас флагманский продукт под названием «Единый клиент», с которым работают десятки энтерпрайз-клиентов, оперирующих в нем сотнями миллионов записей. Продукт массивный, обвешанный аналитикой и различными сложными сервисами. В какой-то момент большая часть клиентов захотела получить общий uptime в 99,9%, чего сложно достичь без резервирования решения. И мы начали погружаться в эту тему практически с нуля.

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

Часто задается вопрос: как эффективно и быстро обработать огромные объемы информации? Ответом на этот вызов стала концепция MapReduce, разработанная в недрах Google.

MapReduce — это парадигма программирования, созданная для обработки и генерации больших объемов данных с использованием параллельных распределенных алгоритмов. Основная фича проста: сначала данные разбиваются на небольшие части (фаза Map), а затем результаты этих частей агрегируются в финальный результат (фаза Reduce).

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

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

Если вы посмотрите на общую раздутость современного софта, загружаемые 100 гигабайтные игры, ежегодную Nvidia X090 дающую +20% год от года, и 20-ядерные процессоры, то со стороны может показаться, что оптимизация производительности неважно чего, будь то игры или другой софт, казалось бы, утратила свою актуальность. В эпоху безнаказанной производительности аппаратной части можно расплескивать хоть половину этой мощи, и пользователь этого даже не заметит. Это все может и верно, если вы не делаете игру. Почему же тогда на этих двадцати ядрах, фризит и тормозит (хорошо что не вылетает часто) игра выпущенная два года назад?

Почему тормозит я вам не скажу: возможно разработчики, которые делали её (на не самом новом движке, надо сказать) просто делали игру и не задумывались о рядовых игроках, которые сидят на пятилетнем железе, хотя даже пятилетнее железо уделывает приставки текущего поколения. Возможно это другая причина - когда твоя рабочая машина с 64 гибайтами оперативки и 4080 на борту тянет редактор, то беспокоиться об игроках можно начинать после патча первого дня.

При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает. Или звуковая подсистема, так она вообще своей отдельной жизнью живет в своих приоритетных тредах, мы просто кидаем туда меседжи с настройками и номером фрейма, чтобы засинхронизировать это с картинкой. Это сложно, но решаемо, но звук не привязан к картинке.

Привет, меня зовут Руслан Савченко, я руководитель службы разработки динамических таблиц в Yandex Infrastructure и преподаватель в Школе анализа данных. Сегодня я поделюсь актуальными инсайтами о том, как ломаются большие системы и как их траблшутить. Думаю, это будет полезно разработчикам и студентам, которые интересуются Site Reliability Engineering. Вообще, мало где сейчас обучают SRE, хотя в индустрии такие задачи очень востребованы.

В основе статьи — материалы SRE Week, открытого интенсива ШАДа по работе с большими нагруженными системами.

Привет, Хабр! В предыдущем тексте мы рассмотрели все существующие матричные расширения. Возникает вопрос: ждать ли в ближайшее время новых расширений для матричных операций? Ответ — да, они разрабатываются прямо сейчас для архитектуры RISC-V. Новость может вызвать удивление, ведь в обзоре уже есть целых два матричных расширения RISC-V. Но оба эти расширения — кастомные, и, конечно же, в консорциуме RISC-V International задумались о разработке стандартного решения. 

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

Продолжаем тему блокировок на сервере СУБД. Сегодня «нелогичные» блокировки. Нелогичные в кавычках, потому что с точки зрения пользователя они выглядят как обычные логические (Записки оптимизатора 1С (часть 6). Логические блокировки MS SQL Server в 1С: Предприятие), но природа их совсем другая.

Кто ходил на собеседования по устройству на работу, тот знает, спрашивают там всякое и странное. Нередко можно встретить задачу SQL по нахождению сотрудников с максимальной зарплатой в отделе. Причем ваш потенциальный начальник считает, что у этой задачи есть только одно «правильное решение», то, про которое он прочитал в Интернете. Так ли это?

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

Меня зовут Слава Усов. В 20 лет я уехал в свою первую экспедицию на Шпицберген, потом в Антарктиду и с тех пор пожил и поработал практически на всех континентах. От ученого до операционного менеджера в Африке и на Ближнем Востоке.

Матричное расширение ISA CPU… Что это и что оно делает? Уже из названия понятно, что это расширение позволяет ускорять операции над матрицами на CPU. Но задумывались ли вы когда-нибудь, какие они бывают, когда появились, кто и как их создает?

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

Матричные расширения появились не так давно — чуть более трех лет назад. Несмотря на это, они есть у каждой уважающей себя процессорной архитектуры, в том числе и у относительно молодой открытой RISC-V. Почему их так много и чем они отличаются? Поддерживаются ли разреженные матрицы? Об этом и многом другом вы узнаете из статьи. Приготовьтесь, будет интересно и (спойлер!) без многоэтажных формул. 

В новом переводе от команды Spring АйО вы узнаете, как аннотация @Transactional помогла решить проблему с утечкой соединений и обеспечила стабильность системы.

Привет! Меня зовут Игорь, я разработчик и эксперт по Java в Skillbox.

В этой статье поделюсь своим видением организации идеального рабочего места.

За рабочим местом я провожу минимум 8 часов 5 дней в неделю и 2–3 часа дополнительно выделяю для учёбы, игр или сёрфинга в интернете.
Согласитесь, это довольно много.

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

Важно: даже самое комфортное рабочее место не заменит вам регулярной физической активности! Добавляйте перерывы в работе за ПК, занимайтесь спортом, гуляйте на свежем воздухе, заботьтесь о своём организме и он вам ответит взаимностью.