По материалам статьи Slava Oks: Configuring SQL Server 2005 for Soft NUMA
Недавно, в статье http://blogs.msdn.com/slavao/articles/441058.aspx я рассмотрел вопросы обеспечения поддержки NUMA на программном уровне. На этой неделе один из наших клиентов столкнулся с интересной проблемой. Клиенту необходимо было балансировать загрузку процессоров в рамках одного экземпляра SQL Server. Приложение клиента было гетерогенным. Часть запросов этого приложения была схожа с запросами эталонного теста TPCH, а другая часть предназначена для загрузки данных. В распоряжении клиента имеется NUMA система, с 2 узлами по четыре процессора в каждом. Клиент хотел оставить под загрузку данных два процессора, а остальные процессоры предоставить для исполнения запросов. Возможно ли это реализовать?
Как Вы могли догадаться, ответ на это вопрос - использовать программную поддержку NUMA в SQL Server 2005. Мы порекомендовали им настроить SQL Server и клиентские компьютеры так, чтобы реализовать систему из трёх NUMA узлов. (Удивленны? Да, это действительно можно сделать, используя программную поддержку NUMA в SQL Server 2005). Конфигурация имела бы следующий вид: нулевой узел имеет четыре процессора, первый узел имеет два процессора, и последний узел имеет оставшиеся два процессора. Имейте в виду, когда Вы настраиваете программную поддержку NUMA в SQL Server, программное представление узла не должно выходить за рамки реальных узлов, то есть, программный узел не может охватывать несколько реальных NUMA узлов. Клиенты с TPCH запросами настраивались таки образом, чтобы они подключались к нулевому и первому узлам, а приложение загрузки данных настраивалось для работы с последним узлом. После того, как необходимые настройки были выполнены и система была запущена в эксплуатацию, оказалось, что она заработала, как и ожидалось - нагрузка разного типа разносилась на разные процессоры. Важно заметить, что клиент был полностью удовлетворён и восхищен результатом. Ниже приведён пример узла и его конфигурации сети, предложенные нами клиенту:
Конфигурация узлов по привязке к процессорам (affinity).
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90\NodeConfiguration\Node0] "CPUMask"=dword:0000000F [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90\NodeConfiguration\Node1] "CPUMask"=dword:00000030 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90\NodeConfiguration\Node2] "CPUMask"=dword:000000C0
Имейте в виду, что affinity mask для программного узла не может захватывать несколько аппаратных узлов. Например: 000000CF - неправильная маска.
Конфигурация сети, обеспечивающая назначение узлам портов.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\SuperSocketNetLib\Tcp\IPAll] "TcpPort"="1433[0x3],2000[0x4]" "TcpDynamicPorts"="" "DisplayName"="Any IP Address"
Эта конфигурация заставляет SQL Server слушать на двух портах. Один порт обслуживает два узла. Это означает, что отношение узла к портам может быть один ко многим.
Имейте в виду, что в квадратных скобках Вы определяете affinity узлов, а не процессоров, то есть 3 в этом случае означает, что порт 1433 будет принимать запросы для процессов узлов 0 и 1.
Когда порт назначен нескольким узлам, это означает, что подключения к этим узлам будут осуществляться циклически.
После внесения изменений в системный реестр, сервер должен быть перезапущен для вступления изменений в силу. Кроме того, клиенты должны быть настроены для подключения к соответствующим портам. В нашем случае клиенты с TPCH нагрузкой должны быть направлены на порт 1433, а приложение загрузки данных на порт 2000.
SQL Server 2005 поддерживает и более сложную конфигурацию программного NUMA. Ниже представлена информация, которая наряду с примером, была предоставлена мне нашей группой поддержки производительности; она описывает, как настроить SQL Server 2005 для поддержки программного NUMA в общем случае. Пожалуйста, обратите внимание, что фактически Вы можете привязать какой-нибудь NIC к узлу.
Здесь показаны ключи с их значениями по умолчанию, в которых Вы должны изменить значение TcpPort.
|
Таким образом, если нужны 3 порта (2000,2001,1433) на сервере с четырьмя узлами, и так, что бы подключения к порту 2000 обслуживались узлами 0 и 1, подключения к порту 2001 обслуживались узлами 2 и 3, а подключения к порту 1433 обслуживались всеми узлами; используйте следующую установку:
|
Как видно, значения в квадратных скобках, это маски узлов, но не маски процессоров. Упоминавшийся выше ключ реестра позволяет всем имеющимся в системе NIC слушать на всех перечисленных выше портах. Далее, вместо этих установок, если мы хотим управлять подключениями к нескольким сетевым адаптерам, т.е. балансируя нагрузку на разные NIC, мы должны создать зеркальную копию этого ключа.
|
И потом, если мы имеем в системе два NIC, помимо адаптера - заглушки, нам понадобятся ещё два ключа, которые представлены ниже. Обратите внимание, что последняя часть ключа "IP3" зависит от номера NIC.
|
Это означает, что слушать порт 2000 будет только адаптер с адресом 10.192.168.01 и он будет передавать подключения с порта 2000 только на узлы 0 и 1. Подобно ему, ведёт себя и порт 2001.
Ниже представлена конфигурации, которая заставляет восьми процессорную систему с двумя узлами вести себя как система с восьмью узлами. Предполагается, что в системе имеются восемь сетевых адаптеров.
|
Комментариев нет:
Отправить комментарий