Серверы становятся мощнее и больше каждый год. Количество ядер растет, векторные блоки для параллельной обработки масс��вов данных одной инструкцией расширяются, частоты давно уперлись в физические ограничения. Но вычислительная плотность продолжает увеличиваться. При этом производительность памяти и систем хранения растет существенно медленнее. В результате в реальных системах процессор все чаще простаивает, так как технически готов выполнять инструкции, но вынужден ждать, пока данные будут доставлены из хранилища.
Это явление давно известно в архитектуре вычислительных систем как разрыв между процессором и памятью (или Memory Wall). Сегодня он определяет производительность серверов, баз данных, платформ данных и AI/ML-платформ сильнее, чем выбор конкретной модели процессора или видеокарты. А в будущем определит то, какие продукты и решения индустрия будет использовать для решения задачи хранения данных.
Привет! Я Александр Гришин, руководитель по развитию продуктов хранения данных в Selectel. В этой статье я попробую подробно разобрать, что такое этот ваш разрыв между процессором и памятью, как он сформировался, как устроена иерархия памяти в сервере и почему эти ограничения подталкивают индустрию к новым архитектурам и решениям. Погнали!
Центральный процессор и цена ожидания данных
Из курсов по архитектуре ЭВМ известно, что центральный процессор выполняет вычисления, используя данные, полученные из регистров. Регистры — самая быстрая форма памяти в системе, но их объем крайне ограничен и измеряется сотнями байт на ядро.
Любая инструкция, работ��ющая с памятью, в итоге сводится к перемещению данных по цепочке хранения от носителя к регистрам CPU и обратно. Если нужных данных нет в непосредственной близости, процессор вынужден простаивать, ожидая завершения операций загрузки. В результате быстрый и мощный CPU ждет данные из медленной памяти, не выполняя полезной работы. Особенно ярко это проявляется в чувствительных к задержкам нагрузках, таких как OLTP-системы и интерактивные сервисы.
Время, необходимое для чтения, обработки и записи данных от уровня хранения до регистров процессора и обратно, называется latency. Это важный параметр, напрямую влияющий на производительность сервера и всех информационных систем, которые он обслуживает.
Неожиданный для многих факт: более быстрая и емкая память способна дать прирост производительности, сопоставимый или превосходящий апгрейд процессора по частоте. А дело в том, что для профилей нагрузки, связанных с обработкой данных, скорость доступа часто оказывается важнее тактовой частоты CPU.
Для ориентира. Один цикл процессора на частоте 1 ГГц занимает примерно одну наносекунду, а современные серверные CPU работают на частотах порядка нескольких гигагерц, то есть доступ к регистрам занимает меньше единицы наносекунды. На фоне этого доступ к оперативной памяти или диску выглядит на порядки медленнее.
Почему разрыв появился и продолжает расти
Сам по себе разрыв между процессором и памятью (Memory Wall или Processor Memory Performance Gap) — не какое-то модное веяние последних лет. Термин еще в 1994 году ввели Джин Вульф и Салли Макки для описания ситуации, когда производительность процессоров растет значительно быстрее, чем скорость доступа к памяти.
Производительность CPU росла в соответствии с законом Мура. Увеличивалось количество транзисторов, расширялись конвейеры, рос параллелизм и ширина исполнения инструкций. Даже после остановки гонки частот рост вычислительной мощности продолжился за счет многоядерности и векторных блоков.
Тем временем, производительность памяти улучшалась существенно медленнее, примерно 7–10% в год. Это не идет ни в какое сравнение с темпами роста вычислительных возможностей процессоров. В результате для получения данных из оперативной памяти требуются сотни или тысячи циклов CPU. Это приводит к простоям в приложении и как следствие выражается в негативном пользовательском опыте.
Доступ к локальному диску увеличивает задержку еще на порядок. Доступ к сетевому хранилищу или S3 добавляет десятки и сотни миллисекунд. Для современного процессора это эквивалент вечности.
Бесплатное S3-хранилище на 30 дней
Для всех, кто ранее не использовал услугу в Selectel.
Локальность данных и иерархия памяти
Вообще в хранении данных есть две закономерности. Если программа обратилась к определенному адресу памяти, то с высокой вероятностью она в ближайшее время:
обратится к нему еще раз,
обратится и к соседним адресам.
Эти свойства легли в основу ключевого архитектурного решения в вычислительной технике — иерархической структуры памяти.
Идея заключается в размещении небольших, быстрых и дорогих уровней памяти ближе к процессору, а больших, медленных и дешевых — дальше от него. Чем выше уровень иерархии, тем ниже задержка и объем, но выше стоимость хранения каждого байта данных.
Кэши L1, L2, L3 и SRAM
Самый близкий к процессору уровень памяти — кэш первого уровня, или L1 cache. Он реализован на статической памяти SRAM и интегрирован непосредственно в ядро CPU.
Доступ к данным из L1 занимает обычно 1–2 цикла процессора. Объем L1 кэша составляет порядка 32–64 килобайт на ядро и обычно разделяется на кэш инструкций (L1 I-Cache) и кэш данных (L1-D-Cache).
Можно было бы бесконечно увеличивать размер L1 кэша, снижая число обращений к более медленным уровням. Однако просто увеличивать площадь L1 способ крайне дорогой, мало эффективный по площади и энергопотреблению и экономическим соображениям. Поэтому следующим шагом стал кэш второго уровня, чуть по дальше.
L2 cache также реализован на SRAM, но имеет больший объем, расположен немного дальше от транзисторов и как следствие имеет более высокую задержку доступа к данным. Типичные размеры L2 составляют от сотен килобайт до нескольких мегабайт на ядро. Задержка доступа составляет примерно до 10 циклов CPU.
Следующий уровень — это L3 cache. Он обычно разделяется между всеми ядрами процессора и не привязан к конкретному ядру. Физически он расположен еще дальше, а его объем может достигать сотен мегабайт на сокет. Задержка доступа измеряется десятками циклов процессора.
L3 — общая точка конкуренции между ядрами. При высокой конкурентной нагрузке и большом количестве потоков это может приводить к росту задержки и ухудшению p99.
В том числе этим могут объясняться ситуации когда во время тестирования производительности СУБД, сервер с меньшим количеством ядер, но большим отношением объем L3/ядро показывает существенно лучший результат производительности.
Алгоритмы кэширования основаны на вероятности повторного доступа. Адреса с высокой вероятностью обращения удерживаются в L1. Менее горячие данные вытесняются в L2 и L3. Если данных нет ни в одном из кэшей, происходит обращение к оперативной памяти.
Кэши занимают значительную часть площади кристалла CPU. Для некоторых профилей нагрузки оправдан выбор процессоров с меньшим числом ядер, но большим объемом кэша на ядро.
Оперативная память DRAM
Следующий уровень иерархии — это оперативная память, обычно реализованная на DRAM. Современные серверные платформы поддерживают огромные объемы памяти. Серверы на базе AMD EPYCTM P-серии или Intel® Xeon® Scalable способны вместить и 6 ТБ RAM. Это достигается за счет большого числа каналов памяти и поддержки модулей высокой плотности.
Однако физически оперативная память на материнской плате находится еще дальше от вычислительных модулей ядра, чем L3 кэш. И хотя скорость света высока, задержки доступа к данным в DRAM кратно выше и находятся на уровне сотен наносекунд. Для процессора это сотни циклов ожидания.
Использование NUMA-архитектур дополнительно увеличивает задержки при доступе к удаленн��й памяти. В том числе по этой причине есть рекомендация DBA использовать односокетные платформы для latency-чувствительных профилей нагрузки. Однако, это не однозначно верное утверждение. Нужно хорошо понимать профиль нагрузки прежде чем решить что в вашем случае это действительно так.
Но пойдем дальше. При работе с большими наборами данных рано или поздно возникает необходимость выходить за пределы оперативной памяти и использовать дисковое хранение.
Локальные диски и NVMe
Локальные диски дают кратный рост емкости при снижении стоимости хранения. Разумеется, производительность при этом снова кратно снижается.
Объем доступных к покупке NVMe SSD сегодня достигает сотен терабайт. Например, Solidigm выпускает накопители объемом 122.88 ТБ. Они применяются в корпоративных системах хранения, AI-платформах, аналитических системах и платформах данных.
Обычно в сервер можно установить десятки таких дисков, получив несколько петабайт локального хранилища. Однако даже самые быстрые SSD остаются на порядки медленнее оперативной памяти, обеспечивая задержки доступа на уровне десятков микросекунд. Осложняется ситуация еще и тем, что процессор не может обратиться к диску напрямую и данные должны быть предварительно скопированы в оперативную память. Таким образом, для доставки данных с диска в может потребоваться до миллисекунды с учетом всех копирований через оперативную память.
В том числе по этой причине наши DBA в Selectel строго рекомендуют использовать только самые быстрые из доступных вам локальных дисков для WAL при работе с СУБД типа PostgreSQL. Я подробно писал об этом в этой статье.
Сетевые системы хранения
Следующий уровень, сетевые системы хранения данных: сетевые диски, аппаратные СХД, программно-определяемые хранилища вроде Ceph и т. д. Они подключаются к серверам по Ethernet, iSCSI, Fibre Channel, InfiniBand, NVMe over RoCE и аналогичным протоколам, часто с использованием оптики на физическом уровне.
В серверной такие системы выглядят как отдельные стойки для хранения данных, подключенные к основным серверным мощностям. Они позволяют хранить десятки петабайт данных, но кратно увеличивают задержку доступа к данным и общую производительность.
Важно понимать, что процессор не может обращаться к сетевому хранилищу напрямую. Все данные проходят через сетевой стек, контроллеры, драйверы и, разумеется, оперативную память. Таким образом, задержка может достигать десятков миллисекунд.
В качестве примера можно привести Huawei OceanStor Dorado серии 8000/18000 V6. Это высокопроизводительные системы хранения данных на базе флэш-накопителей NVMe, которые предназначены для критически важных бизнес-нагрузок. Они способны обеспечивать до 40 000 000 IOPS при хорошем уровне отказоустойчивости.
Конфигурация таких массивов включает до 32 контроллеров и до 6 400 NVMe SSD, а системный кэш может расширяться от сотен гигабайт до десятков терабайт, что повышает устойчивость к нагрузкам и улучшает эффективность обработки горячих данных.
Но даже при высокой внутренней пропускной способности и низкой задержке доступа к данным они все равно остаются удаленным уровнем хранения по сравнению с локальной DRAM/SSD. Работа с подобными массивами требует прохождения сетевого стека, контроллеров и дополнительной логики.
Объектные S3-хранилища
На самом нижнем уровне иерархии я сегодня расположу объектные хранилища, такие как S3. Это распределенные системы хранения практически неограниченного объема, доступные из любого региона и дата-центра.
Задержка доступа к объектному хранилищу измеряется десятками миллисекунд даже при обращении внутри одного ЦОД. При доступе через интернет задержки могут достигать сотен миллисекунд. По сравнению с регистрами процессора это различие составляет восемь или девять порядков величины. Т.е. почти бесконечность.
Недавно я с коллегой подробно рассказывал, как устроено такое хранилище в Selectel, поэтому не буду долго останавливаться, а просто оставлю ссылку на запись видео.
Тренды в индустрии хранения данных
Классические системы хранения проектировались вокруг парадигм Data Warehouse и shared nothing. Каждый узел кластера хранения обладал собственным CPU, памятью и локальным диском, а данные жестко шардировались между нодами. В качестве примера можно рассмотреть OpenSearch, Teradata, Greenplum, Clickhouse, Vertica и др.
Эта модель хорошо масштабировалась в эпоху, когда объемы данных измерялись терабайтами, а основными задачами были реализация MPP и параллельное выполнение SQL-запросов. Однако сейчас крупный бизнес измеряет данные десятками петабайт, и даже в SMB-сегменте петабайт не является чем-то впечатляющим. По мере роста объемов данных в Big Data и аналитике начали проявляться фундаментальные ограничения такого подхода.
Потребность в увеличении хранилищ данных растет быстрее, чем потребность в более быстрых вычислениях. Объемы данных растут экспоненциально за счет логов, событий, телеметрии, AI/ML и стриминга.
Кроме того, стоимость хранения на локальных SSD стала критичным фактором. В shared nothing архитектуре вычисления и данные жестко связаны. Чтобы добавить CPU, нужно добавлять диски. Чтобы добавить диски, нужно добавлять CPU. Это приводит к избыточным конфигурациям и неэффективному использованию ресурсов.
Наконец, благодаря AI/ML-трендам данные перестали быть только структурированными. Современные нагрузки включают сырые события, полуструктурированные форматы, версии датасетов, логи, фото и мультимедиа, ML-пайплайны, паркеты для аналитики и многое другое.
Переход к shared storage является не модным трендом, а следствием фундаментальных причин. Современные аналитические движки Trino, Presto, Snowflake и BigQuery изначально проектируются вокруг идеи, что данные живут отдельно, а вычисления масштабируются независимо.
Да, маркетинг подает Data Lakehouse как революцию. Но если понимать физику ограничений имеющихся сейчас у нас технологий и тренды растущих потребностей бизнеса, становится понятно, что это скорее логичный, неизбежный и эволюционный переход.
Заключение
Подытожим. Разрыв между процессором и памятью — не абстрактная академическая проблема, а фундаментальное ограничение, которое сегодня определяет реальную производительность серверов, СУБД, аналитических платформ и AI-систем. Следовательно, этот разрыв определяет также продукты, решения и лучшие практики на ближайшие годы.
Подозреваю, в будущем индустрия уйдет от классических монолитных архитектур (PostgreSQL, MySQL, Oracle) к модульным и деконструированным системам. Дело в том, что классическая СУБД создавалась в 70-х годах прошлого века и исторически оптимизировалась под локальный доступ к данным и минимизацию latency внутри одного узла. Но по мере роста объемов данных и увеличения доли обращений к удаленным уровням иерархии памяти, будь то сетевое хранилище или S3, узким местом стали аппаратные ограничения доставки данных к вычислениям. Разделение системы на независимые слои хранения, планирования и исполнения позволяет оптимизировать каждый из них под свой профиль доступа и свою позицию в иерархии памяти.
В этом смысле деконструкция СУБД — шаг в эволюции архитектуры и неизбежное следствие ограничений памяти и хранения данных. В одной из прошлых статей я рассказывал о том, что за описание таких конструктивных подходов в экономике недавно была присуждена Нобелевская премия.
Вероятно, в будущем мы будем все реже видеть классические кластерные СУБД объемом больше десятков ТБ. И все чаще будем встречать гибридные архитектуры, где S3 становится доминирующим источником хранения данных, а вычисления масштабируются быстро и эластично под конкретную задачу. В этом мире по-настоящему производительной IT-инфраструктуры будут выигрывать не самые быстрые процессоры и видеокарты, а самые грамотные архитектуры и оптимальные продукты.
