В общем вопрос в следующем:
Есть 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.