Разрабатывая функционал прослушивателя для группы доступности, мы общались со многими клиентами, и поняли, что есть пара сценариев, в которых может потребоваться наличие нескольких прослушивателей для одной группы доступности.
Рецензенты: Thomas Kejser, Curt Peterson, James Podgorski, Christian Martinez,
Mike Ruthruff
Перевод: Александр Гладченко
Технические редакторы перевода: Алексей Халяко, Ирина Наумова
Функциональность Receive-Side Scaling (RSS) впервые появилась в Windows 2003. Это нововведение было призвано повысить возможности масштабируемости операционной системы Windows, и этим предоставить новые возможности по обслуживанию большого сетевого трафика. Такой трафик характерен для систем, где SQL Server обслуживает OLTP нагрузку. Подробное описание того, какие усовершенствования RSS получила операционная система Windows 2008, можно узнать из отчёта - Receive-Side Scaling Enhancements in Windows Server 2008 и в блоге - Scaling Heavy Network Traffic with Windows.
Данная статья относится к
следующим версиям SQL Sever: 2008, 2008 R2, 2012 и 2014. Первый вариант статьи
был опубликован в 2011г.
Примечание: в данной статье
под количеством процессоров подразумеваются не сокеты, а представленные в
системе логические процессоры. Рекомендации статьи применимы в тех случаях,
когда для сервера баз данных доступно более восьми логических процессоров.
В зависимости от того, для каких нужд SQL Server использует память, дизайн ядра сервера баз данных предусматривает возможность секционирования распределения памяти. В процессе разработки SQL Server можно было выбирать схему секционирования исполнителя по процессорам, узлам или глобально. Некоторые связанные с распределением памяти функциональные модули SQL Server используют модуль распределения CMemPartitioned. Этот модуль секционирует память по процессорам или NUMA узлам, что может способствовать повышению параллелизма и производительности.
Автор: Боб Дорр – главный эскалационный инженер поддержки SQL Server
По материалам статьи: How It Works: SQL Server 2012 Database Engine Task Scheduling
В течении последних лет в разных источниках были описаны алгоритмы работы планировщика SQL Server. В частности, в статье «The Guru’s Guide to SQL Server Architecture and Internals» есть глава, написанная разработчиком планировщика (Sameer) и Кеном Хендерсеном. Автор этой статьи иранее описывал некоторые технические детали алгоритмов планирования задач SQLServer.
Эта статья посвящена некоторым изменениям, которые появились в SQL Server 2012. Статья не претендует на охват всех нюансов (коих слишком много), вместо этого будет частично проиллюстрирована работа алгоритма в его современной реализации, что позволит вам лучше понимать поведение планировщика SQLServer . Автор допускает по тексту несколько вольную трактовку в описании алгоритмов, преследуя цель избавить статью от лишней официальности.
Тенденции развития аппаратных средств вычислительной техники оказывают влияние на то, как мы проектируем и разрабатываем программное обеспечение. Для сегодняшнего состояния рынка, персональные компьютеры с большим числом процессоров больше не редкость - это действительность.
Наличие таких возможностей как симметричная многопоточность (SMT), много-ядерные процессоры, слабо совместимые модели, память и процессоры с горячей заменой - становятся все более важны для достижения требуемых уровней производительности систем, их масштабируемости и администрирования. Есть две основные проблемы, связанные с проектированием программного обеспечения для современных аппаратных средств: недостаток хороших инструментов и неадекватный опыт разработчиков. Сервера базы данных пытаются использовать новые возможности серверных платформ, т.к. они стали доступны. Обычно сервер базы данных содержит встроенный уровень поддержки платформы, который скрывает от большинства разработчиков сервера базы данных специальные сообщения от аппаратных средств. SQL Server в предыдущих версиях имел довольно простой уровень поддержки платформы с ограниченной функциональностью. В SQL Server 2005 мы создали новый уровень поддержки платформы, который позволяет максимально задействовать параллелизм, секционирование и размещение. Этот уровень называется SQLOS. SQLOS - операционная система непривилегированного режима, которая встроена в иерархию дизайна сервера баз данных, точно также, как в эту иерархию входят аппаратные средства, на которых запускается сервер. Основные объекты SQLOS, это узлы, планировщики и задачи. SQLOS может подстраиваться и корректироваться под имеющуюся аппаратную конфигурацию сервера, на который он устанавливается. Это реализуется за счёт довольно сложного дизайна API, который позволяет разработчикам получать максимум преимуществ аппаратной платформы при написании программ, как на высоком, так и на низком уровне. Имеется встроенная поддержка размещения, параллелизма, и администрирования. SQLOS позволяет существенно поднять производительность и масштабируемости SQL Server 2005. В новой версии DBA получили возможность балансировать нагрузку SQL Server между компонентами имеющейся аппаратной конфигурации, в соответствии со своими бизнес задачами. В процессе разработки SQLOS мы получили очень много ценной информации и наметили ряд возможных усовершенствований на будущее.
По материалам статьи Slava Oks: SQL Server 2005 NUMA support & troubleshooting
SQL Server 2005 был разработан с учётом того, чтобы использовать в своей работе возможности и интерфейсы NUMA, которые поддерживаются современными серверными платформами и операционной системой Windows. Есть несколько проблем, о которых Вы должны знать при попытке запуска SQL Server на поддерживающих NUMA платформах.
В этой статье я хотел бы сделать обзор поддержки NUMA в Windows и SQL Server, описать их возможные конфигурации, и дать несколько советов относительно разрешения возможных проблем.
В последнем июньском SQL Server 2005 CTP реализовано большинство из необходимого для поддержки NUMA, так что Вы уже можете опробовать эти возможности и лично убедиться в том, как поддержка NUMA используется на практике. Если Вас больше интересует поиск и устранение проблем, без необходимости вникнуть в причины проблемы, Вы можете сразу перейти к разделу разрешения проблем в этой статье.
Уровень изложения материала: я ожидаю, что Вы имеете представление о классической архитектуре ccNUMA, и поэтому я не буду вдаваться в её подробности и объяснять её принципы.
По материалам статьи Slava Oks: Configuring SQL Server 2005 for Soft NUMA
Недавно, в статье http://blogs.msdn.com/slavao/articles/441058.aspx я рассмотрел вопросы обеспечения поддержки NUMA на программном уровне. На этой неделе один из наших клиентов столкнулся с интересной проблемой. Клиенту необходимо было балансировать загрузку процессоров в рамках одного экземпляра SQL Server. Приложение клиента было гетерогенным. Часть запросов этого приложения была схожа с запросами эталонного теста TPCH, а другая часть предназначена для загрузки данных. В распоряжении клиента имеется NUMA система, с 2 узлами по четыре процессора в каждом. Клиент хотел оставить под загрузку данных два процессора, а остальные процессоры предоставить для исполнения запросов. Возможно ли это реализовать?
По материалам статьи Slava Oks: Be Aware: Using AWE, locked pages in memory, on 64 bit
Мы уже говорили о механизме Windows AWE на 32-х битной платформе и как SQL Server его использует. Сегодня я хотел бы пробежаться по AWE и связанным с ним механизмам на 64-х битной платформе.
Многие наверняка удивлены тем, что механизм AWE здесь все еще используется и оказывается полезным и на 64-х битных платформах. Вы уже знаете, что этот механизм состоит из двух частей, распределяющих физическую память и отображающую её на VAS данного процесса. Преимущество механизма распределения состоит в том, что если физическая память распределена, то операционная система уже не сможет её затребовать, пока использующий её процесс не будет завершён или это процесс освободит память, вернув её операционной системе. С помощью такого подхода приложение может управлять и даже полностью предотвращать листание. Преимущество механизма mapping/unmapping в том, что одна и та же физическая страница может быть отображена на разные участки VAS. Как Вы догадываетесь, на 64-х битных платформах в unmapping нет необходимости, поскольку VAS мы имеем достаточно, чтобы вместить всю имеющуюся физическую память.
По материалам статьи Slava Oks: Be Aware: IA64 Stack Size
Тема стека в операционной системе Windows всегда вызывает интерес. С ней связано много интересных технических проблем. В какие-то моменты Вы думаете, что полностью понимаете всё о стеке, но потом внезапно обнаруживаете ещё одну тайну.
По материалам статьи Slava Oks: SQLOS Caching
Эта статья рассказывает о том, как изменился механизм кэширования в SQL Server 2005.
Отличия в кэшировании SQL Server 2000 и SQL Server 2005
Управление памятью SQL Server 2005 отличается от SQL Server 2000 более сложной структурой кэширования. В SQL Server 2000 реализовано два основных кэша: кэш страницы данных, называемый Buffer Pool, и кэш процедур, кэш планов исполнения запросов. Buffer Pool и кэш процедур очень сильной связаны между собой. Например, кэш процедур использует механизм выселения буферного пула, чтобы управлять его размером, не смотря на то, что оба кэша имеют собственные политики оценки. Использование связанных BP и кэша процедур значительно упрощает механизм кэширования SQL Server 2000, с которым мы, как правило, имеем дело при разрешении проблем.
Эта модель очень хорошо работала в SQL Server 2000, но она непригодна для SQL Server 2005. С появлением в SQL Server 2005 новых функциональных возможностей и новых требований, появилась необходимость увеличения числа кэшей. Связь всех кэшей с Buffer Pool стала не только проблематичной, но даже и невыполнимой. Стало очевидно, что мы должны создать общую структуру кэширования. Ключевой идеей этой структуры является однородный механизм и общая политика оценки.
По материалам статьи Slava Oks: A look at Windows Virtual Memory mechanisms (continuation of "A look at Virtual Address Space - VAS")
Как я обещал в прошлый раз, это будет следующая статья о памяти. Как Вы помните, моей целью является демонстрация того, как в SQL Server устроено управление использованием памяти. Но для читателя, чтобы в этом хорошо разобраться, я думаю важно также уяснить, как управляет памятью операционная система Windows. Важно понимать детали такого управления памятью, однако сейчас я хочу, чтобы Вы поняли заложенные в это концепции! В некоторых случаях я нарочно буду пропускать подробности, потому что в данном случае они не очень важны, и многие из них могут отличаться в разных версиях операционной системы. И так, позвольте приступить!
По материалам статьи Slava Oks: SQLOS's memory manager: responding to memory pressure
При настройке SQL Server очень важно понимать, как он реагирует на вытеснение памяти. Я уже посветил довольно много времени описанию разных типов вытеснения памяти. В этой статье Вы узнаете, почему это так важно. Вытеснение памяти можно классифицировать двумя основными группами: вытеснение VAS и вытеснение физической памяти. Вытеснение физической памяти может быть спровоцировано операционной системой, мы назвали его внешним, или оно может быть спровоцировано процессом, такое вытеснение мы называем внутренним.
SQLOS использует специализированную структуру, которая занимается обслуживанием любого из типов вытеснения памяти процесса. В основе этой структуры находится Resource Monitor (RM). RM контролирует состояние внешних и внутренних индикаторов памяти. Когда один из них изменяется, RM отслеживает состояние всех индикаторов. При этом соответствующее оповещение отображает состояние индикатора. Такое оповещение рассчитано на то, что оно будет разослано всем клеркам памяти (Memory Clerks).
По материалам статьи Slava Oks: Tracking VAS in Yukon, cont...
Некоторые из Вас, возможно, скучали, читая мою предыдущую статью "Обзор Virtual Address Space - VAS". Я понимаю, что тема VAS до этого была многократно освещена множеством авторов и ей было уделено много времени, и Вы наверняка знаете об этом больше, чем даже хотелось бы знать. Однако, наберитесь, пожалуйста, терпения. Я хочу дать достаточный предварительный обзор темы, что бы читатель смог легко ориентироваться в предлагаемом ему материале. Мне хотелось бы показать ту часть внутренней организации операционной системы, без которой будет сложно охватить тему, о которой Вы хотите узнать побольше: "Управление памятью в SQL Server". Поэтому я продолжу эту тему в следующий раз.
По материалам статьи Slava Oks: A look at Virtual Address Space - VAS
Память представляет собой набор разделяемых между приложениями, их компонентами и операционной системой ресурсов. Нужно чётко себе представлять, что происходит при обращении к каждому конкретному ресурсу памяти. Очень часто, разработчики, пользователи или администраторы баз данных ошибочно считают, что при обращении к разным ресурсам памяти используется один универсальный раздел памяти. Такое представление было справедливым для DOS, когда всё было просто и не существовало даже понятия виртуальной памяти, а приложения не разделяли ресурсы компьютера между собой. С тех пор многое изменились.
По материалам статьи Slava Oks: Tracking VAS in Yukon
Когда разработчики приступили к работе над следующей версией SQL Server - Yukon, они осознавали, что развитые средства поддержки являются одним из ключевых моментов успешности проекта. Своей целью автор ставит охват тем, описывающих "нижние" уровни организации СУБД, которые многим из Вас, как он уверен, действительно интересны, то есть это управление памятью и планирование ресурсов. В этой статье представлен беглый обзор того, как можно контролировать и диагностировать виртуальное адресное пространство - Virtual Address Space (VAS), используемое SQL Server. Автор надеется, что Вы понимаете что такое VAS и как оно организовано в Windows. Надеясь на Ваше терпение, автор постарается побыстрее описать всю исходную информацию, что бы в ближайшем будущем мы могли подробно поговорить о менеджере памяти SQL Server.
Представленный ниже запрос можно выполнять на сервере периодически, чтобы отслеживать возможные отклонения, связанные с VAS. Постоянное отклонение VAS от нормы может указывать на потенциальную проблему. Не смотря на то, что Yukon умет восстанавливаться после вытеснения VAS намного лучше, чем SQL Server 2000, если в реальности существует утечка памяти, спровоцированная внешними компонентами загруженными в наше VAS, поделать с этим будет практически ничего нельзя...
По материалам статьи Slava Oks: Changes in dbcc memorystatus in Yukon
Вероятно, Вам доводилось использовать в SQL Server 2000 команду dbcc, выдающую информацию о состоянии памяти. В Yukon разработчики изменили выводимую dbcc memorystatus информацию, чтобы учесть изменения в дизайне нового менеджера памяти, которые автор описал в предыдущих статьях.
Первая часть выводимых данных представляет собой информацию о полном объеме памяти, используемой SQLOS, SQL Server и менеджером памяти.
По материалам статьи Slava Oks: Look at Memory Leaks - Classify and Identify
В своей предыдущей статье автор говорил о типах вытеснения памяти. Сейчас он хотел бы обратиться к близкой теме - "Утечка Памяти". Прежде, чем продолжить изложение материала, автор хочет предупредить Вас, что он рассчитывает на то, что читатель знаком с механизмами и принципами управления памятью в Windows.
По материалам статьи Slava Oks: Memory Pressure - Classified
До этой статьи автор затрагивал те темы, которые довольно широко обсуждались. Теперь он хотел бы поговорить об экзотической теме, это "вытеснение памяти". С виду эта тема выглядит простой, но в действительности дело обстоит совсем не так.
По материалам статьи Slava Oks: SQLOS's memory manager and SQL Server's Buffer Pool
В SQL Server 2005 менеджер памяти SQLOS состоит из нескольких компонент, таких как: Узлы памяти (Memory Nodes), Клерки памяти (Memory Clerks), Кэши памяти (Memory Caches) и Объекты памяти (Memory Objects). На Рисунке 1 изображёны компоненты менеджера памяти и их связи:
