В общем вопрос в следующем:
Есть 2 сервера IBM 3850 x5, соединенные в один сервер.
Конфигурация: 8 CPU E7-8860, 160 Logical CPU (80 физических ядер).
512 Gb RAM
Тестовая база расположена на внешнем хранилище, подключенному через 4 FC HBA Emulex
Стандартный нагрузочный тест 1С проваливается на всем пространстве процессоров - индекс 0.77 при 100 пользователях.
Если отключать использование процессоров - то на 20 ядрах (18 из Numa 0 + 2 из Numa 1) получается 320 пользователей с индексом 0.91

Соответственно реальная работа тоже впечатляет. До какого-то количества реальных пользователей (назовем х) загрузка процессоров - 8-15%
Проскакиваем какой-то порог (допустим х*1.1) - средняя нагрузка вырастает до 80%.
Памяти занято порядка 100Gb.

ОС: Windows 2008 R2 Enterprise SP1 + патчи на неправильное распределение процессоров по Kernel groups
SQL : MS SQL 2008 R2 Datacenter + Update Pack 7


В каком направлении копать?

PS Похожий сервер, но в варианте 1 сервера - и послабже процами (суммарно 64 ядра) позволяет работу одновременно х*1.4 пользователям при средней загрузке процессоров от 15 до 35% (пиками до 60%)

Модератор: Тема перенесена из форума "Microsoft SQL Server".

Конфигурация "Стандарный нагрузочный тест" http://www.1c.ru/news/info.jsp?id=12192
"...СНТ выполняет типовой бизнес-процесс "Продажи в УПП", автоматически увеличивая количество виртуальных пользователей до тех пор, пока оборудование не перестанет справляться с создаваемой нагрузкой и производительность не выйдет за рамки допустимых значений. Таким образом, СНТ позволяет оценить производительность серверной части системы на предопределенной последовательности действий, типичных для большинства информационных систем, построенных на платформе "1С:Предприятие 8". ..."
Если коротко, тест запускает клиентские сессии 1С, в которых создаются записываются и проводятся три вида документов (в SQL это запросы вида INSERT, DELETE, UPDATE), данные не пересекаются, взаимоблокировок нет. Каждая клиентская сессия выполняет несколько таких циклов с замером времени выполнения каждого. Оценка оптимального количества клиентских сессий происходит по
методике APDEX http://gilev.ru/1c/apdex/

Насчет цены - цена чего интересует?

rigus1. На сервере предприятия 1с достаточно процессов создано (жедательно по количеству ядер или хотябы кратно им)?
2. Возможно имеет смысл ограничить возможный паралелизм запросов в sql (а то ядер у вас больно много)
2. Нужно найти бутылочное горлышко
что показывают счетчики? (Очереди на дисках)
Что вернет
SELECT *
FROM sys.dm_os_wait_stats
ORDER BY 3 DESC ;
1. Количество процессов - от 30 до 40
2. MaxDOP = 1
очереди на дисках < 0.05
Дисковая подсистема не загружена в силу своей мощности
Первые 3 значения из результатов запроса:
LAZYWRITER_SLEEP 115078 30600099 3620268 38976
SOS_SCHEDULER_YIELD 3371661 5728459 325 5706013
REQUEST_FOR_DEADLOCK_SEARCH 1013 5060843 5128 5060843

rigus3. И еще для базы temp вы создали нужное количество файлов (равное или кратное количеству ядер)?
Да
Количество файлов данных tempDB равно количеству физических ядер.

на боевой базе статистика обновляется 1 раз в сутки
На тестах - включаешь все ядра - тест провален, включаешь 20 ядер - тест летает
Боюсь что дело не в статистике.

rigusА кеш пробовали чистить (по ссылке там есть)?

declare @CurrentSizeOfTokenCache int
SELECT @CurrentSizeOfTokenCache = SUM(single_pages_kb + multi_pages_kb)
FROM sys.dm_os_memory_clerks
WHERE name = 'TokenAndPermUserStore'

if @CurrentSizeOfTokenCache>20*1024
DBCC FREESYSTEMCACHE ('TokenAndPermUserStore')

Вообще вам надо на http://www.sql.ru/forum/actualtopics.aspx?bid=1
и/или техподдержку 1с а вдруг подскажут.


SELECT SUM(single_pages_kb + multi_pages_kb)
FROM sys.dm_os_memory_clerks
WHERE name = 'TokenAndPermUserStore'
результат : 824
Из того раздела переместили сюда.

Вопрос тогда еще один есть:
Какой нибудь стресс тест SQL , а-ля TPC-C, только с возможностью скачивания не подскажете?
Необходимо все таки отделить проблему - кто виноват - 1С или MS SQL

LogrusASPetr Litovchenko,

Выключите хипертрейдинг в БИОСе, так чтобы система показывала 80 процессоров, то есть столько же сколько и ядер.
Вырубали - абсолютно та же картина.
Путем отключения части процов в биосе довели число ядер до 64. Картина теста осталась характерной для данного сервера - на 100 юзерах тест индекс 0.72-0.77.
Хотя по идее картина должна соответствовать второму серверу, описанному в 1-м посте.

rigusПроверьте электропитание в windows - что выставлена максимальная производительность, а не сбалансированный.
А то может умный windows понижает частоту/отключает ядра для экономии электричества.
Выставлена максимальная производительность как в Windows, так и в UEFI (IBM Bios).
Execute disable bit - отключен.

Программист 1сPetr Litovchenko, хм доделали стандартные тесты - незнал.

Цена сервера конечно интересна.

ps Крайний вариант - пишите в техподдержку 1с, достанете их и они вам помогут.
В GPL прайсе от IBM - порядка 150.000$

AHDPС таким соотношением используемой памяти к общей памяти tempdb вообще не должна использоваться. А вот конфигурацию дисковой системы и расположения на них файловыг групп следует озвучить. Судя по всему затык именно там.
Файловая группа - одна, Primary
Расположена на внешнем дисковом массиве Enterprise класса
Дисковые очереди не превышают 0.5 по PerfMon

LogrusASAHDP,

Вы с pagefile.sys не путаете?

А если размер базы у ТС меньше 512 гиг, то диски можно вообще выкинуть?
Не путаю.
Размер тестовой базы на которой крутится тест - 13Gb
Размер занятой RAM варьируется от 40 до 108Gb (Зависит от того, сколько раз запускали тест до рестарта сервиса скуля, и то не напрямую.)

soljo_ua тынц посмотрите настройки нумов
У нас Hard-Numa. В силу некоторых особенностей реализации 1С дробить сервер на Soft-NUMA и ставить Network Affinity - нельзя.
(Управляемые блокировки и автонумерация при работе с одной базой из разных серверов приложений слетит на раз).
Всего на сервера 8 Hard-Numa.
Numa0,1 - принадлежат Kernel group 0 (40 CPU)
Numa2,3 - принадлежат Kernel group 1 (40 CPU)
Numa4,5 - принадлежат Kernel group 2 (40 CPU)
Numa6,7 - принадлежат Kernel group 3 (40 CPU)
Данная статья излазана вдоль и поперек, максимум что можно попробовать(но не смогли настроить) - это разбить 8 Hard-NUMA на 16 Soft-NUMA.

AHDPPetr Litovchenko,
Enterprise class не отменяет принципы работы СУБД и самих дисков. Самый простой способ это проверить - создать рам диск и положить файлы БД на него.
И выполните совет XenoX - "разделите" процессоры на обслуживающие процессы 1С (по одному на rphost), обслуживающие SQL и оставьте операционной системе. Переключение ядра с процесса на процесс совсем не бесплатно!
Больше вам пока советовать нечего, т.к. не понятно где крутится сервер самой 1С, и что же всётаки так нагружет процессоры.

rigus,
Зачем давать tempdb количество файлов большее чем количество независимых физических дисков!?

LogrusAS,
Описался, должно было быть "tempdb не должна использовать диски". Ну и уточнение, за вычетом некоторых моментов. А вот соотношение размера базы к размеру необходимой памяти бывает и меньше 1.

Согласен относительно общей теории построения СХД.
Насчет RAM-надо попробовать. Но!
СХД выдает в максимуме 1 гигабайт в секунду на чтение или на запись - без разницы
Разница с диском в РАМ кажется несущественной.
Сервер СП - 40 процессов
Процов - 160, соответственно загружены не все.
Но тест не проходит все равно.

AHDPВот и думайте... 1 Гиг в секунду в потоке, устоявшаяся скорость - какая? А рандомное чтение/запись? На checkpoint сколько дисковых операций потребуется? Здесь и должна прявиться разница между РАМ диском и массивом жёстких дисков.
Вот поэтому я и попросил вас уточнить параметры ваших замеров. А то не понятно, что это за "средняя нагрузка" и 80% чего? А так получается, что у вас излишние вычислительные мощнсти для этого теста и недостаточность в дисковой подсистеме.
ЗЫ И зачем вам 160 кусков tempdb если у вас свободных процессоров для её обработки минимум на 25% меньше!?
Каким тестом рекомендуете проверить указанные параметры?
На checkpoint сколько дисковых операций потребуется? - как это определить?
На ТемпДБ - 80 файлов фиксированного размера без автороста по 10Гб + 1 темплог стартовым размером 20Гб (Количество физических ядер равно 80).

AHDP А то не понятно, что это за "средняя нагрузка" и 80% чего?
Речь идет исключительно о загрузке процессора.
т.е. на пороге х пользователей - загрузка ЦПУ средняя по всем процам - 10-15%, х*1.1 - 80%

AHDPPetr Litovchenkoпропущено...

Речь идет исключительно о загрузке процессора.
т.е. на пороге х пользователей - загрузка ЦПУ средняя по всем процам - 10-15%, х*1.1 - 80%

Вы нас пытаетесь запутать. У вас средняя загрузка всех процессоров составляет 80% или какого-то одного из 160? Подозреваю, что общая. И скорее всего часть процессоров забита за 100%, а остальные стоят. Я уже устал у вас спрашивать про рассшифровку загрузки процессоров.
Я сожалею, если сложилось такое впечатление.
В случае включения боевой базы - заняты одинаково все процессоры.
Средняя нагрузка 80% взята именно в момент работы количества реальных пользователей большего, чем количество процессоров на SQL сервере. И именно при превышении некоего порога количества реальных пользователей.
Соответственно, при работе теста заняты далеко не все процессоры - тут вы правы.
Занято только то количество, которое в данный момент отдано под sql server.
Просто ставить эксперименты на боевой базе более нет желания.
Так что возвращаясь к тесту, он просто показывает дикую разницу в результатах между задействованными скулем всеми 160 процессорами и урезанными до 22 процессоров.
На процессоры дает нагрузку процесс sqlserver.exe

И все таки - какой именно программой рекомендуете проверить диски на параметры, указанные Вами?

XenoXТак а вы определили, "кто" (какой процесс) больше всего грузит систему?
sqlservr.exe
Сервер полностью отдан под MS SQL.

Программист 1сAHDPВерсия платформы и что за апдейты установлены на сервер? Что говорит профайлер?Кстати здравая мысль. Попробуйте разрные версии платформы - что-то изменится?
Версия платформы - 8.1, дальше не помню просто.
Апдейты установлены все.

rigusPetr Litovchenko,
Кстати в вашем СХД диски какие и сколько?
т.к. для того чтобы система не упиралась в диски нужно десяток обычных дисков на 1 ядро. либо ssd
а с учетом что у вас 80 ядер то дисков в системе должно быть не меряно!!!
http://www.sql.ru/forum/actualthread.aspx?tid=851583
СХД - IBM DS8100, 64 SAS HDD
СХД выделена только под скуль.

XenoXДаже не знаю....
Нужно смотерть, что творится с количеством считываний/записей на sql
Ловить профайлером длительные операции....
В общем анализировать, на чем затыкается сам скуль...

Если нагрузка резко возрастает после перехода планки в N пользователей, которые активно пишут и изменяют данные то....

опять таки попробуйте пустить такое же количество только читающих пользователей, что будет с загрузкой?
На нашем количестве боевых пользователей профайлер за короткое время выдаст такую гору информации, что парсить ее нужно будет неделями, к сожалению.
Вот именно, что вся проблема в резком возрастании загрузки процессоров при проходе определенной планки числа пользователей.
Соседний сервер это переваривает без проблем, у него конфигурация в 2.5 раза хуже по процам и в 2 раза по памяти.

ScareCrowможет вы таки посмотрите счетчики производительности винды?
Единственный счетчик, который привлек внимание:
SYSTEM\context switches/sec - от 45.000 до 186.000
Дисковые очереди на диски с базой =0,05
На ТемпДБ - от 0,05 до 1.4

AHDPPetr Litovchenkoпропущено...

Единственный счетчик, который привлек внимание:
SYSTEM\context switches/sec - от 45.000 до 186.000
Дисковые очереди на диски с базой =0,05
На ТемпДБ - от 0,05 до 1.4

http://www.sql.ru/articles/mssql/02021801MonitoringPerformanceSQLServer.shtml - о чём вам я уже говорил. Стакой низкой дисковой очередью очень большое подозрение, что вы упёрлись в производительность работы СУБД под вашей нагрузкой на этой настройке железа.

Вы сможете сделать тест, разместив файлы базы на РАМ диске?

Попробуем прогнать тест, разместив ТемпДБ и файлы тестовой базы на РАМ диске.
Но уже не сегодня.
Насчет фразы: упёрлись в производительность работы СУБД под вашей нагрузкой на этой настройке железа. - извините, не совсем понял смысл:(