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

Управление мощностями: в поисках идеального баланса - 1

Здравствуйте! Меня зовут Иван Давыдов, я занимаюсь исследованиями производительности в Яндекс.Деньгах.

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

Здесь можно увлечься, и микросервисов станет слишком много, вследствие чего станет сложно управлять ими и обеспечивать их отказоустойчивость. В итоге на каждом сервере станет «кучковаться» десяток приложений, которые борются за общие ресурсы. Получится «большая семья», а в большой семье клювом не щёлкай!

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

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

Apache Kafka и RabbitMQ: семантика и гарантия доставки сообщений - 1

Подготовили перевод следующей части многосерийной статьи, где сравнивается функциональность Apache Kafka и RabbitMQ. В этой публикации речь идёт о семантике и гарантии доставки сообщений. Обращаем ваше внимание, что автор учитывал Кафку до версии 0.10 включительно, а в версии 0.11 появился exactly-once. Тем не менее, статья остаётся актуальной и полна полезных с практической точки зрения моментов.
Предыдущие части: первая, вторая.

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

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

Блокировки интернета в России уже есть — это данность, с которой мы живем и должны жить дальше. А раз так, нужно разбираться, как это устроено технически, что может и не может провайдер. Филипп Кулин (schors) давно начал собирать информацию по этому поводу, участвовал в нормативной работе, ходил на разные совещания. В итоге сейчас больше него о блокировках в России знает только Роскомнадзор, но это не точно. Под катом краткая сводка актуального состояния дел.

О спикере: Филипп Кулин (schors) генеральный директор ООО «Дремучий лес» — небольшого российского хостера, занимающегося в основном shared-хостингом.
Читать полностью »

У нас в True Engineering на одном проекте назрела необходимость в смене версии PostgreSQL с 9.6 на 11.1.

Зачем? База данных на проекте уже объемом 1,5 Tb и растет. Перформанс – одно из основных требований к системе. А сама структура данных эволюционирует: добавляются новые колонки, меняются существующие. Новая версия Postgres научилась эффективно работать с добавлением новых колонок с дефолтным значением, так что не нужно городить кастомных костылей на уровне приложения. Ещё в новой версии добавили несколько новых способов партиционирования таблиц, что тоже крайне полезно в условиях большого объема данных.

Итак, решено, мигрируем. Конечно, можно поднять параллельно со старой новую версию сервера PostgreSQL, остановить приложение, через dump/restore (или pg_upgrade) переместить базу и снова запустить приложение. Нам это решение не подошло из-за большого размера базы, к тому же, приложение работает в боевом режиме, и на даунтайм есть считанные минуты.

Поэтому мы решили попробовать миграцию с помощью логической репликации в PostgreSQL с помощью стороннего плагина под названием pglogical.

В процессе «проб» мы столкнулись с весьма обрывочной документацией по этому процессу (а на русском языке её вообще нет), а также некоторыми подводными камнями и неочевидными нюансами. В этой статье мы хотим изложить свой опыт в виде Tutorial.

Бесшовная (почти) миграция между мажорными релизами PostgreSQL с помощью логической репликации - 1

TL;DR

  • Всё получилось (не без костылей, о них и статья).
  • Мигрировать можно в рамках PostgreSQL версии от 9.4 до 11.x, с любой версии на любую, вниз или вверх.
  • Даунтайм равен времени, которое требуется вашему приложению, чтобы переподключиться к новому серверу БД (в нашем случае это был перезапуск всего приложения, но в дикой природе, очевидно, «возможны варианты»).

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

Всем привет!

Сегодня мы хотим рассказать о том, как команда сервиса бронирования отелей Ostrovok.ru решала проблему роста микросервиса, задачей которого является обмен информацией с нашими поставщиками. О своем опыте рассказывает undying, DevOps Team Lead в Ostrovok.ru.

Пробы и ошибки при выборе HTTP Reverse Proxy - 1

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

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

При этом изменение объема используемых ресурсов (увеличение или уменьшение) происходит в таких ЦОДах дискретно, с заранее определенными коэффициентами. Например, при коэффициенте 2 мы можем получить такой ряд конфигураций:

  • 2CPU, 8 GB RAM, 40GB storage;
  • 4CPU, 16GB RAM, 80GB storage;
  • 8CPU, 32GB RAM, 160GB storage;

Однако, для множества задач эти конфигурации оказывается экономически неэффективными, часто клиентам достаточно некоей промежуточной конфигурации, например, — 6CPU, 16GB RAM, 100GB storage. Таким образом, мы приходим к пониманию, что вышеуказанный универсальный подход к выделению ресурсов ЦОД оказывается неэффективным, в особенности при интенсивной работе с большими данными (например, быстрые данные, аналитика, искусственный интеллект, машинное обучение). Пользователи в таких случаях хотят иметь более гибкие возможности управления используемых ресурсов, им необходима возможность независимого друг от друга масштабирования используемых процессоров, памяти и хранилищ данных, сетевых каналов. Конечной целью этой идеи является создание гибкой компонентной инфраструктуры.

Будущее инфраструктур центров обработки данных - 1

Рис. 1. Дата-центрированная архитектура ЦОД.
Читать полностью »

Наверное, каждый из вас без проблем может собрать компьютер — найти и заказать правильные комплектующие, распаковать-установить-настроить, поднять нужный софт. Но представьте, что вы эти занимаетесь каждый день, да ещё и не один год подряд. Работа мечты или адская кухня? Нет, можно, конечно, ради интереса сменить род деятельности, испытать всё на своей шкуре… А можно спросить у Артёма Смирнова из HYPERPC, и он всё расскажет!

Как производят лучшие компьютеры в России? Интервью с Артёмом Смирновым из HYPERPC - 1
Читать полностью »

Совсем недавно (почти 4 месяца назад) вышла новая Haiku (далее — просто BeOS, ибо проект гораздо удачнее ReactOS — настолько, что разница между Haiku и BeOS уже пренебрежимо мала).

Конечно же, мне давно уже надоели все эти Windows и *nix; хотелось попробовать чего-то новое, поэтому я не мог не пройти мимо этого проекта. Да и недавно прочитанный киберпанк-роман Александра Чубарьяна давал понять, что BeOS — крайне мощная вещь. Кстати, если кто тоже его читал, думаю, Вы догадываетесь, как Яндекс выбрал имя Алиса для своего голосового помощника.
Читать полностью »

Привет! Я Дима, и я довольно давно и плотно сижу на Python. Сегодня хочу показать вам отличия двух асинхронных фреймворков — Tornado и Aiohttp. Расскажу историю выбора между фреймворками в нашем проекте, чем отличаются корутины в Tornado и в AsyncIO, покажу бенчмарки и дам немного полезных советов, как забраться в дебри фреймворков и успешно оттуда выбраться.

Tornado vs Aiohttp: путешествие в дебри асинхронных фреймворков - 1

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

Gotta Go Fast: Building for Speed in iOS. Part 2 - 1

Sometimes you can find yourself in a situation where your app cannot perform well. So here are some instruments you can use and best practices you can implement to make things better.Читать полностью »


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