Рубрика «высокая производительность» - 30

Высоконагруженный сервис для вычислений на GPU - 1

Привет! Я руковожу разработкой платформы Vision — это наша публичная платформа, которая предоставляет доступ к моделям компьютерного зрения и позволяет вам решать такие задачи, как распознавание лиц, номеров, объектов и целых сцен. И сегодня хочу на примере Vision рассказать, как реализовать быстрый высоконагруженный сервис, использующий видеокарты, как его разворачивать и эксплуатировать.
Читать полностью »

Пробуем preload (PHP 7.4) и RoadRunner - 1

Привет! 

Мы часто пишем и говорим о производительности PHP: как мы ей занимаемся в целом, как мы сэкономили 1 млн долларов при переходе на PHP 7.0, а также переводим разные материалы на эту тему. Это вызвано тем, что аудитория наших продуктов растёт, а масштабирование PHP-бэкенда при помощи железа сопряжено со значительными затратами — у нас 600 серверов с PHP-FPM. Поэтому инвестирование времени в оптимизацию для нас выгодно.

Прежде мы говорили в основном об обычных и уже устоявшихся способах работы с производительностью. Но сообщество PHP не дремлет! В PHP 8 появится JIT, в PHP 7.4 — preload, а за пределами core-разработки PHP развиваются фреймворки, подразумевающие работу PHP как демона. Пора поэкспериментировать с чем-то новым и посмотреть, что это может нам дать.

Так как до релиза PHP 8 ещё далеко, а асинхронные фреймворки плохо подходят для наших задач (почему — расскажу ниже), сегодня остановимся на preload, который появится в PHP 7.4, и фреймворке для демонизации PHP — RoadRunner.

Это текстовая версия моего доклада с Badoo PHP Meetup #3. Видео всех выступлений мы собрали в этом посте.Читать полностью »

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

Как AWS «варит» свои эластичные сервисы. Масштабирование серверов и базы данных - 1

Облако AWS это мегасуперсложная система, которая эволюционно развивается с 2006 года. Часть этого развития застал Василий Пантюхин — архитектор Amazon Web Services. Как архитектор он видит изнутри не только конечный результат, но и сложности, которые преодолевает AWS. Чем больше понимания работы системы, тем больше доверия. Поэтому Василий поделится секретами облачных сервисов AWS. Под катом устройство физических серверов AWS, эластичная масштабируемость БД, кастомная база данных Amazon и методы повышения производительности виртуальных машин с одновременным уменьшением их цены. Знание архитектурных подходов Amazon поможет эффективнее использовать сервисы AWS и, возможно, даст новые идеи по построению собственных решений.
Читать полностью »

Мы в поте лица готовим очередную мажорную версию Tokio, асинхронной среды выполнения для Rust. 13 октября для слияния в ветку оформлен пул-реквест с полностью переписанным планировщиком задач. Результатом станет огромное улучшение производительности и уменьшение задержки. В некоторых тестах зафиксировано десятикратное ускорение! Как обычно, синтетические тесты не отражают фактическую выгоду в реальности. Поэтому мы также проверили, как изменения в планировщике повлияли на настоящие задачи, такие как Hyper и Tonic (спойлер: результат замечательный).

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

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

Говорим о новых архитектурах как крупных мировых производителей, так и стартапов — waferscale-чипах, тензорных процессорах и устройствах на базе графов.

Подборка по теме:


Чипы для ML — рассказываем о новинках - 1Читать полностью »

Вы просили показать реальные примеры использования наших корпоративных SSD-накопителей и профессиональные тесты. Предоставляем вашему вниманию подробный обзор наших SSD-накопителей Kingston DC500R и DC500M от нашего партнера Truesystems. Эксперты Truesystems собрали реальный сервер и эмулировали абсолютно реальные задачи, с которыми сталкиваются все твердотельные накопители корпоративного класса. Давайте почитаем, что у них получилось!

По вашим заявкам: профессиональный тест SSD-накопителей Kingston DC500R и DC500M - 1
Читать полностью »

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

Почему надо создавать модули для nginx - 1

Вообще все в nginx — это модули, которые когда-то кем-то были написаны. Поэтому писать модули под nginx не только можно, но и нужно. Когда это необходимо делать и зачем, расскажет Василий Сошников (dedokOne) на примере нескольких кейсов.

Поговорим о причинах, которые побуждают писать модули на C, об архитектуре и ядре nginx, анатомии HTTP-модулей, о C-модулях, NJS, Lua и nginx.conf. Это важно знать не только тем, кто разрабатывает под nginx, но также тем, кто использует nginx-конфиги, Lua или другой язык внутри nginx.

Примечание: статья написана на основе доклада Василия Сошникова, который постоянно модернизируется и обновляется. Информация в материале довольно техническая и, чтобы извлечь максимум пользы, читателям необходимо иметь опыт работы с кодом nginx на среднем уровне и выше.
Читать полностью »

Подводя итоги нескольких весьма напряженных недель, Intel анонсировала вторую половину своего стека процессоров Core 10-го поколения с низким энергопотреблением. С новым именем Comet Lake, процессоры мощностью до 15 Вт основаны на существующей архитектуре процессора Intel Skylake и 14-нм техпроцессе, оснащены некоторыми дополнениями как для повышения производительности, так и для решения конкретных аппаратных задач. С 6-ти ядерной серией U и 4-х ядерной серией Y, Intel стремится расширить возможности многопоточной производительности в тонком и легком ноутбуке. Новые процессоры дополнят традиционную линейку Intel U и Y. Ядра 10-го поколения будут и в Intel Lake Ice 10 нм, а OEM-производители будут использовать оба семейства продуктов в новых ультрапортативных ноутбуках в этот праздничный сезон.

Intel Comet Lake-U и Comet Lake-Y: до 6 ядер для тонких и легких ноутбуков - 1

В целом, запуск Comet Lake происходит в сложное для Intel время. Компания все еще пытается оправиться от неудач с внедрением 10-нм технологического узла. Несмотря на то, что Intel наконец-то возобновила производство 10 нм, компания пока не в состоянии полностью перевести производство процессоров ведущих поколений на 10 нм. В результате маломощные процессоры Intel этого поколения будут состоять из 14-нм компонентов, основанных на их почтенной архитектуре Skylake, и 10-нм компонентов Ice Lake, включающих новую архитектуру Intel Sunny Cove. 14-нм компоненты нужны, чтобы решить задачи, которые пока не под силу чистому Ice Lake.
Читать полностью »

Zabbix — это система мониторинга. Как и любая другая система, она сталкивается с тремя основными проблемами всех систем мониторинга: сбор и обработка данных, хранение истории, ее очистка.

Этапы получения, обработки и записи данных занимают время. Немного, но для крупной системы это может выливаться в большие задержки. Проблема хранения — это вопрос доступа к данным. Они используются для отчетов, проверок и триггеров. Задержки при доступе к данным также влияют на производительность. Когда БД разрастаются, неактуальные данные приходится удалять. Удаление — это тяжелая операция, которая также съедает часть ресурсов.

Высокая производительность и нативное партиционирование: Zabbix с поддержкой TimescaleDB - 1

Проблемы задержек при сборе и хранении в Zabbix решаются кэшированием: несколько видов кэшей, кэширование в БД. Для решения третьей проблемы кэширование не подходит, поэтому в Zabbix применили TimescaleDB. Об этом расскажет Андрей Гущин — инженер технической поддержки Zabbix SIA. В поддержке Zabbix Андрей больше 6 лет и напрямую сталкивается с производительностью.

Как работает TimescaleDB, какую производительность может дать по сравнению с обычным PostgreSQL? Какую роль играет Zabbix для БД TimescaleDB? Как запустить с нуля и как мигрировать с PostgreSQL и производительность какой конфигурации лучше? Обо всем этом под катом.
Читать полностью »

Написанной мной инструмент командной строки Sloc Cloc and Code (scc), который теперь доработан и поддерживается многими отличными людьми, подсчитывает строки кода, комментарии и оценивает сложность файлов внутри каталога. Здесь нужна хорошая выборка. Инструмент подсчитывает в коде операторы ветвления. Но что такое сложность? Например, заявление «У этого файла сложность 10» не очень полезно без контекста. Чтобы решить эту проблему, я запустил scc на всех исходниках в интернете. Это также позволит найти какие-то крайние случаи, которые я не рассматривал в самом инструменте. Мощное испытание методом грубой силы.

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

Короче говоря, я загрузил и обработал много исходников.

Голые цифры:

  • 9 985 051 репозиториев всего
  • 9 100 083 репозитория хотя бы с одним файлом
  • 884 968 пустых репозиториев (без файлов)
  • 3 500 000 000 файлов во всех репозиториях
  • Обработано 40 736 530 379 778 байт (40 ТБ)
  • Идентифицировано 1 086 723 618 560 строк
  • Распознано 816 822 273 469 строк с кодом
  • 124 382 152 510 пустых строк
  • 145 519 192 581 строк комментариев
  • Общая сложность по правилам scc: 71 884 867 919
  • 2 новые ошибки, найденные в scc

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js