DOTS was a new milestone of development in Unity. Hot debate has not subsided so far. A year ago, I already told about our experience of using earlier versions in production, this year we will see how this technology stack has changed and, as an example of our game, we will consider the solution of tasks inherent in the RTS genre using Unity DOTS.
#MadeWithUnity
Rapid Upgrades With Pg_Upgrade, Bruce MomjianFuenteovejuna
Pg_Upgrade allows migration between major releases of Postgres without dumping and reloading data. It works by installing the new Postgres system tables while continuing to use the data files from the previous version. Pg_Upgrade freezes all rows in the new cluster, copies over transaction logs and IDs from the old cluster, restores the database schema, and finally copies over user data files. This process allows for much faster upgrades than traditional dump and restore methods.
DOTS was a new milestone of development in Unity. Hot debate has not subsided so far. A year ago, I already told about our experience of using earlier versions in production, this year we will see how this technology stack has changed and, as an example of our game, we will consider the solution of tasks inherent in the RTS genre using Unity DOTS.
#MadeWithUnity
Rapid Upgrades With Pg_Upgrade, Bruce MomjianFuenteovejuna
Pg_Upgrade allows migration between major releases of Postgres without dumping and reloading data. It works by installing the new Postgres system tables while continuing to use the data files from the previous version. Pg_Upgrade freezes all rows in the new cluster, copies over transaction logs and IDs from the old cluster, restores the database schema, and finally copies over user data files. This process allows for much faster upgrades than traditional dump and restore methods.
Social Monitoring Tool codename Looking Glass, Patrice PellandFuenteovejuna
The document discusses the progression of a social monitoring incubation project from a Windows Server backend to Windows Azure.
It began as a Silverlight application with code reuse across Windows Phone and iOS. The initial backend used Windows Server and SQL Server but struggled to scale.
It then moved to using Windows Azure web and worker roles with SQL Azure and Azure storage to improve scalability. This allowed for distributed data acquisition and indexing to handle larger datasets.
The final phase utilized multiple Azure services including data aggregators, indexers, blob storage and visualization to create a more scalable, reliable and complex social monitoring solution. Moving to Azure addressed the project's scalability issues in a cost effective way.
Managing replication of PostgreSQL, Simon RiggsFuenteovejuna
This document discusses PostgreSQL replication. It covers the different use cases for replication including high availability, scalability, and protection. It describes the different replication mechanisms in PostgreSQL, including trigger-based and log-based replication. It outlines the developments made to log shipping in different PostgreSQL versions. It focuses on streaming replication introduced in version 9.0, describing the wal sender, wal receiver, and hot standby capabilities. It discusses tools like Repmgr that help manage replication and monitor delays. Future planned features like sync replication and loose coupling of replication are also mentioned.
Developing PostgreSQL Performance, Simon RiggsFuenteovejuna
This document discusses PostgreSQL performance improvements over multiple versions from 7.3 to 8.4. It shows graphs demonstrating significant performance gains in peak read-only and read-write transaction rates. It describes the contributors to these gains as improvements to buffer management, locking, caching, and other internal aspects of the database engine. It also outlines ongoing focus areas and potential for further 10-20% gains in transaction processing and data warehouse workloads through continued optimization.
The Magic of Hot Streaming Replication, Bruce MomjianFuenteovejuna
This document discusses PostgreSQL 9.0's new capabilities for maintaining a current standby server and issuing read-only queries on the standby server. It covers how to configure continuous archiving from the primary server to the standby, and how to configure the standby for streaming replication so it can accept queries. The summary demonstrates streaming replication by creating and inserting a row on the primary which then appears on the standby.
Real time indexes in Sphinx, Yaroslav VorozhkoFuenteovejuna
This presentation introduces Sphinx Search 1.10's new real-time indexes feature. It discusses the problems with plain indexes and how real-time indexes allow indexing and updating data on the fly directly from MySQL. Performance tests show real-time indexes using less disk space and performing better for single and multi-queries compared to plain indexes, especially under load. The presentation demonstrates easy creation and CRUD of real-time indexes and migration tools and strategies.
InnoDB Architecture and Performance Optimization, Peter ZaitsevFuenteovejuna
This document provides an overview of the Innodb architecture and performance optimization. It discusses the general architecture including row-based storage, tablespaces, logs, and the buffer pool. It covers topics like indexing, transactions, locking, and multi-versioning concurrency control. Optimization techniques are presented such as tuning memory configuration, disk I/O, and garbage collection parameters. Understanding the internal workings is key to advanced performance tuning of the Innodb storage engine in MySQL.
Презентация к докладу Александра Азимова, ведущего инженера по эксплуатации сети фильтрации трафика Qrator, который был прочитан 27 апреля 2011 г. на VIP-дне конференции «Российские интернет-технологии» (РИТ++).
Глобальная доступность ресурса определяется на основе взаимодействия автономных систем (АС). Поэтому основным критерием при выборе хостинга, за исключением финансовой составляющей, является уровень связности АС, в которой расположен хостинг, с сетью АС. Однако наличие физических каналов между АС еще не гарантирует пиринговых отношений между ними. Более того, даже наличие пиринга между сервис-провайдерами не означает, что данный физический канал будет использован.
Правила передачи и фильтрации трафика в сети АС реализуются с использованием политик маршрутизации протокола BGP. Несмотря на то, что региональные регистры маршрутизации (ARIN/APNIC/AFNIC/RIPE) поддерживают интерфейсы для регистрации данных политик маршрутизации, эти данные неполны, а зачастую и некорректны. Это приводит к ситуации, когда уровень связности АС пытаются определять, используя косвенные критерии, такие как уровень физических соединений или количество клиентских маршрутов.
В данной работе демонстрируется подход к созданию системы моделирования маршрутизации BGP, которая позволяет идентифицировать в том числе закрытые или некорректные политики маршрутизации. Дополняют данную систему моделирования несколько методов верификации данных, в том числе с использованием механизма BGP Anycast.
В качестве демонстрации возможностей системы приводится анализ уровня реальной связности российского сегмента сети интернет.
Некоторые аспекты влияния сходимости протокола BGP на доступность сетевых рес...HLL
Тема презентации Александра Азимова, ведущего инженера по эксплуатации сети фильтрации трафика Qrator, представленной в рамках конференции HighLoad++ 25-26 октября 2010 г., относится к актуальной области администрирования на междоменном сетевом уровне — моделированию процесса сходимости протокола BGP.
Данный тип моделирования активно применяется при разработке новых механизмов передачи сообщений BGP и при оценке скорости перестроения глобальной сети вследствие возникновения нештатных ситуаций.
В рамках проведенного исследования были получены следующие оценки:
• Время сходимости протокола BGP вследствие объявления нового маршрута BGP-маршрутизатором пропорционально диаметру графа сети относительно рассматриваемого маршрутизатора;
• Время сходимости протокола BGP вследствие удаления маршрута BGP-маршрутизатором пропорционально гамильтонову пути в графе относительно рассматриваемого маршрутизатора.
В рамках исследования был также проведен анализ работы механизма Flap Damping. Данный инструмент BGP разработан для обнаружения, локализации и минимизации влияния на сеть АС нестабильных участков сети. В качестве признака нестабильности участка сети используется «мигающий маршрут»: повторяющиеся объявления и удаления маршрута к некоторому префиксу за короткий интервал времени. Используя полученные оценки времени сходимости протокола BGP, была рассчитана вероятность возникновения «мигающего маршрута» в кольце BGP-маршрутизаторов вследствие единичного удаления маршрута. В соответствии с полученными результатами, был сделан вывод о негативном влиянии механизма Flap Damping на сходимость протокола BGP.
Social Monitoring Tool codename Looking Glass, Patrice PellandFuenteovejuna
The document discusses the progression of a social monitoring incubation project from a Windows Server backend to Windows Azure.
It began as a Silverlight application with code reuse across Windows Phone and iOS. The initial backend used Windows Server and SQL Server but struggled to scale.
It then moved to using Windows Azure web and worker roles with SQL Azure and Azure storage to improve scalability. This allowed for distributed data acquisition and indexing to handle larger datasets.
The final phase utilized multiple Azure services including data aggregators, indexers, blob storage and visualization to create a more scalable, reliable and complex social monitoring solution. Moving to Azure addressed the project's scalability issues in a cost effective way.
Managing replication of PostgreSQL, Simon RiggsFuenteovejuna
This document discusses PostgreSQL replication. It covers the different use cases for replication including high availability, scalability, and protection. It describes the different replication mechanisms in PostgreSQL, including trigger-based and log-based replication. It outlines the developments made to log shipping in different PostgreSQL versions. It focuses on streaming replication introduced in version 9.0, describing the wal sender, wal receiver, and hot standby capabilities. It discusses tools like Repmgr that help manage replication and monitor delays. Future planned features like sync replication and loose coupling of replication are also mentioned.
Developing PostgreSQL Performance, Simon RiggsFuenteovejuna
This document discusses PostgreSQL performance improvements over multiple versions from 7.3 to 8.4. It shows graphs demonstrating significant performance gains in peak read-only and read-write transaction rates. It describes the contributors to these gains as improvements to buffer management, locking, caching, and other internal aspects of the database engine. It also outlines ongoing focus areas and potential for further 10-20% gains in transaction processing and data warehouse workloads through continued optimization.
The Magic of Hot Streaming Replication, Bruce MomjianFuenteovejuna
This document discusses PostgreSQL 9.0's new capabilities for maintaining a current standby server and issuing read-only queries on the standby server. It covers how to configure continuous archiving from the primary server to the standby, and how to configure the standby for streaming replication so it can accept queries. The summary demonstrates streaming replication by creating and inserting a row on the primary which then appears on the standby.
Real time indexes in Sphinx, Yaroslav VorozhkoFuenteovejuna
This presentation introduces Sphinx Search 1.10's new real-time indexes feature. It discusses the problems with plain indexes and how real-time indexes allow indexing and updating data on the fly directly from MySQL. Performance tests show real-time indexes using less disk space and performing better for single and multi-queries compared to plain indexes, especially under load. The presentation demonstrates easy creation and CRUD of real-time indexes and migration tools and strategies.
InnoDB Architecture and Performance Optimization, Peter ZaitsevFuenteovejuna
This document provides an overview of the Innodb architecture and performance optimization. It discusses the general architecture including row-based storage, tablespaces, logs, and the buffer pool. It covers topics like indexing, transactions, locking, and multi-versioning concurrency control. Optimization techniques are presented such as tuning memory configuration, disk I/O, and garbage collection parameters. Understanding the internal workings is key to advanced performance tuning of the Innodb storage engine in MySQL.
Презентация к докладу Александра Азимова, ведущего инженера по эксплуатации сети фильтрации трафика Qrator, который был прочитан 27 апреля 2011 г. на VIP-дне конференции «Российские интернет-технологии» (РИТ++).
Глобальная доступность ресурса определяется на основе взаимодействия автономных систем (АС). Поэтому основным критерием при выборе хостинга, за исключением финансовой составляющей, является уровень связности АС, в которой расположен хостинг, с сетью АС. Однако наличие физических каналов между АС еще не гарантирует пиринговых отношений между ними. Более того, даже наличие пиринга между сервис-провайдерами не означает, что данный физический канал будет использован.
Правила передачи и фильтрации трафика в сети АС реализуются с использованием политик маршрутизации протокола BGP. Несмотря на то, что региональные регистры маршрутизации (ARIN/APNIC/AFNIC/RIPE) поддерживают интерфейсы для регистрации данных политик маршрутизации, эти данные неполны, а зачастую и некорректны. Это приводит к ситуации, когда уровень связности АС пытаются определять, используя косвенные критерии, такие как уровень физических соединений или количество клиентских маршрутов.
В данной работе демонстрируется подход к созданию системы моделирования маршрутизации BGP, которая позволяет идентифицировать в том числе закрытые или некорректные политики маршрутизации. Дополняют данную систему моделирования несколько методов верификации данных, в том числе с использованием механизма BGP Anycast.
В качестве демонстрации возможностей системы приводится анализ уровня реальной связности российского сегмента сети интернет.
Некоторые аспекты влияния сходимости протокола BGP на доступность сетевых рес...HLL
Тема презентации Александра Азимова, ведущего инженера по эксплуатации сети фильтрации трафика Qrator, представленной в рамках конференции HighLoad++ 25-26 октября 2010 г., относится к актуальной области администрирования на междоменном сетевом уровне — моделированию процесса сходимости протокола BGP.
Данный тип моделирования активно применяется при разработке новых механизмов передачи сообщений BGP и при оценке скорости перестроения глобальной сети вследствие возникновения нештатных ситуаций.
В рамках проведенного исследования были получены следующие оценки:
• Время сходимости протокола BGP вследствие объявления нового маршрута BGP-маршрутизатором пропорционально диаметру графа сети относительно рассматриваемого маршрутизатора;
• Время сходимости протокола BGP вследствие удаления маршрута BGP-маршрутизатором пропорционально гамильтонову пути в графе относительно рассматриваемого маршрутизатора.
В рамках исследования был также проведен анализ работы механизма Flap Damping. Данный инструмент BGP разработан для обнаружения, локализации и минимизации влияния на сеть АС нестабильных участков сети. В качестве признака нестабильности участка сети используется «мигающий маршрут»: повторяющиеся объявления и удаления маршрута к некоторому префиксу за короткий интервал времени. Используя полученные оценки времени сходимости протокола BGP, была рассчитана вероятность возникновения «мигающего маршрута» в кольце BGP-маршрутизаторов вследствие единичного удаления маршрута. В соответствии с полученными результатами, был сделан вывод о негативном влиянии механизма Flap Damping на сходимость протокола BGP.
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Сетевая диагностика: новый взгляд сквозь старые щели / Евгений Усков (Qrator ...Ontico
Сетевые аномалии – рано или поздно с ними сталкиваются все, кто так или иначе связан с созданием и эксплуатацией сетевых сервисов.
Природа сетевых аномалий и их проявления могут значительно варьироваться: потери пакетов, увеличение задержек, разрывы TCP-соединений. Но вне зависимости от своей природы сетевые аномалии требуют корректной и зачастую крайне оперативной диагностики.
В рамках доклада будут рассмотрены стандартные утилиты, такие как ping, traceroute, mtr, hping, а также области их применения. Самым значительным ограничением при использовании данных утилит является невозможность определения обратного пути пакета, что может значительно усложнить диагностику.
Также в докладе будут рассмотрены активные методы диагностики сетевых аномалий (Looking glass, RIPE Atlas, NLNOG RING, PlanetLab) и разработанный командой Qrator механизм определения обратного маршрута от любой заданной сети с использованием математического моделирования.
Big data algorithms and data structures for large scale graphsAlexey Zinoviev
Alexey Zinoviev presents graph processing tools and new algorythms for shortest path problem on the DUMP-2014 (popular Ural IT conference)
Keywords: Pregel, Apache Giraph, shortest path problem
Video: http://youtu.be/MGccYYrP9f0
Сети и системы телекоммуникаций. Протоколы маршрутизацииAndrey Sozykin
Презентация лекции "Протоколы маршрутизации".
План лекции:
Место протоколов маршрутизации в моделях OSI и TCP/IP
Маршрутизация по вектору расстояний
Маршрутизация с учетом состояния канала
Протоколы внутренней маршрутизации (RIP, OSPF)
Структура Интернет
Протокол внешней маршрутизации BGP
Facebook has over 500 million active users, with half logging in every day. It processes over 4 trillion feed actions per day and caches over 2 trillion objects. Facebook has scaled to over 1 million active users per engineer, significantly more efficient than other large tech companies. To achieve this scale, Facebook relies on techniques like frequent small releases, dark launching of major changes, and shedding load during outages to maintain reliability as the site grows enormously.
Shared Personalization Service - How To Scale to 15K RPS, Patrice PellandFuenteovejuna
The document summarizes the Shared Personalization Service (SPS) developed by Microsoft to enable explicit and implicit personalization at scale. SPS uses AppFabric caching and SQL partitioning to support 150 million home page visits per month with peaks of 15,000 requests per second. It provides a stateless architecture with no single point of failure and aims for read latencies less than 25ms and update latencies less than 50ms. SPS deploys across multiple regions using caching, databases, and file servers for availability and scalability.
Goal Driven Performance Optimization, Peter ZaitsevFuenteovejuna
The document discusses goal driven performance optimization. It emphasizes setting clear performance goals based on metrics like response time and throughput. Goals should be set for different types of requests and measured regularly. Instrumentation of the system is important to identify bottlenecks and queries that are causing slowdowns. The key is to prioritize optimization efforts on the most important user interactions that are not meeting goals. Taking a goal-driven approach focuses work on the most significant performance issues.
14. Формальная модель
prefix: I
AS_PATH: 𝐴𝑆1 𝐴𝑆2 𝐴𝑆2
LOCAL_PREF: 100
Представим модель сети автономных систем, как ориентированный граф 𝐺 𝑉, 𝐸 :
• V – автономные системы
• 𝑎𝑠1, 𝑎𝑠2 ∈ 𝐸 тогда и только тогда, когда АС 𝑎𝑠1 будет анонсировать маршрут к
префиксу I BGP АС 𝑎𝑠2
• Вес дуги состоит из двух частей:
• Prepend – политика AS_PATH АС 𝑎𝑠1
• Pref – политика LOCAL_PREF 𝑎𝑠2
Pref = 100
AS1 AS2
Prepend = 2
15. Транзитные АС
Пусть 𝐴𝑆𝑃𝑎𝑡ℎ – множество, состоящие из всех
существующих значений атрибута маршрута
BGP AS_PATH в текущий момент времени.
Тогда признаком транзитной автономной
системы будет:
𝑥 ∈ 𝐴𝑆𝑇𝑟𝑎𝑛𝑠𝑖𝑡 ↔ ∃𝑝𝑎𝑡ℎ ∈ 𝐴𝑆𝑃𝑎𝑡ℎ, ∃𝑖 < 𝑝𝑎𝑡ℎ : 𝑥 = 𝑝𝑎𝑡ℎ𝑖
16. «Ядро» Интернета
Множество транзитных АС неоднородно:
• Пропускают только трафик клиентов
• Имеют пиринговые отношения с соседями
1. 𝑃𝑒𝑒𝑟𝑠 0 = 𝑇𝑟𝑎𝑛𝑠𝑖𝑡
2. 𝑃𝑒𝑒𝑟𝑠 𝑖 + 1 =
𝑥 ∈ 𝑃𝑒𝑒𝑟𝑠 𝑖 | ∃𝑝𝑎𝑡ℎ ∈ 𝐴𝑆𝑃𝑎𝑡ℎ, ∃𝑖 < 𝑗 < 𝑝𝑎𝑡ℎ : 𝑥 = 𝑝𝑎𝑡ℎ𝑖&𝑝𝑎𝑡ℎ 𝑗 ∈ 𝑃𝑒𝑒𝑟𝑠 𝑖
3. lim
𝑖→∞
𝑃𝑒𝑒𝑟𝑠 𝑖 = CORE
23. Прикладное применение
• Хостингам: выбор сервис провайдера
• Reverse Traceroute
• Обнаружение LOCAL_PREF циклов
• Определение времени сходимости
• Моделирование механизмов самого BGP
24. Выбор сервис провайдера
Время сходимости Псевдо-транзитные АС
CORE
AS1
AS2
AS3
10 АС до CORE
=
До 5 минут
задержки Больше хопов –
медленнее
соединение
26. Reverse Traceroute
• АС – единая политика маршрутизации
• Reverse Traceroute – знание, как к тебе идет
трафик от других АС
• Если знать, как идет трафик, можно его
балансировать – profit!
27. LOCAL_PREF циклы
• Причина сетевой нестабильности для целевого префикса
• Создание постоянного «шума» из BGP сообщений
• Замедление времени сходимости по всей сети АС
AS3
AS2
AS4
AS5
AS1 AS6
AS7
200
100
100200
28. Переход к G’
• Причина сетевой нестабильности для целевого префикса
• Создание постоянного «шума» из BGP сообщений
• Замедление времени сходимости по всей сети АС
AS3
AS2
AS4
AS5
AS1 AS6
200
200
29. Время сходимости
Рассматриваемые события:
• Объявление маршрута к префиксу I автономной системой X
• Удаление маршрута к префиксу I автономной системой Х
𝐸𝑇𝑢𝑝 = 𝜃 𝑑 × 𝐸𝑡 𝑤𝑎𝑖𝑡 , где d – диаметр относительно
вершины Х в графе G’
𝐸𝑇𝑑𝑜𝑤𝑛 = 𝜃 𝐷 × 𝐸𝑡 𝑤𝑎𝑖𝑡 , где D – длина гамильтонова
пути относительно вершины Х в графе G
30. Система моделирования
Критерии сравнения
SSFNet NS-2 PRIME CBGP Разработанная
система
Реализация политик
маршрутизации
- - + + +
Полнота стека BGP- решений +/- +/- + + +
Модель передачи BGP
сообщений
Пакетный уровень Пакетный уровень Пакетный уровень В виде объектов В виде объектов
Возможность моделирования
сходимости BGP
маршрутизации
+ + + - +
Возможность распределенных
вычислений
+ - + - +
Масштабируемость + + - + +
33. Flap Damping
Зачем?
Снижение нагрузки на сеть BGP
маршрутизаторов от нестабильных
маршрутов, не оказывая влияния на время
сходимости в стабильных участках сети.
38. Flap Damping DoS?
• Yes!
• Не блокируется ни одним существующим
расширением BGP
39. Данные для экспериментов
• List of router registries
http://www.irr.net/docs/list.html
• BGP dumps
http://www.ripe.net/projects/ris/rawdata.html
Автономных систем: 36200
Транзитных систем: 5876
CORE: 1757
Prepends: 15722
40. Результаты
• Разработана модель BGP маршрутизации
• Сформулированы оценки времени сходимости
протокола BGP
• Разработана система моделирования для проверки
теоретических оценок
• Рассмотрены механизмы BGP LOCAL_PREF и Flap
Damping и их влияние на доступность сетевых ресурсов
• Предложен метод для построения Reverse Traceroute