Доброго времени суток, уважаемые 1С-ники и админы.
Есть проблема, с которой никак не могу справиться, нужна помощь коллективного разума.

Итак, дано:
1. Сервер: Dell PowerEdge R815 (AMD Opteron 6276 2.3GHz, 4 процессора, 128 ГБ ОЗУ). SAS диски 10000 об/мин.
2. ОС: Windows Server 2008 R2 x64
3. СУБД: MS SQL Server 2012
4. Там же установлен сервер приложений 1С (8.3.10.2466). С SQL-сервером общаются в режиме Shared memory. Количество ИБ на процесс = 1.
5. Клиента 1С ERP пользователи (их на данный момент не более 10) запускают с сервера терминалов. Сеть между терминалкой и сервером БД - 1Гбит через коммутатор.
6. SQL-серверу выделено 90 ГБ ОЗУ (причём, что интересно, раньше он выедал классически всю выделенную ему память. Сейчас же, после последней перезагрузки, не более 500МБ). Параметр Maxdop = 1. Cost threshhold of parallelism=15. Maximum worker threads-2048. Модель восстановления БД Simple.
7. Мониторинг производительности показал что дисковых очередей значительных нет. Блокировок нет. Buffer Cache Hit Ratio стабильно в районе 100%.
8. Тест Гилёва в попугаях показал 18 пернатых (если кому интересно).

Собственно проблема заключается в том, что при открытии списков и проведении документов приходится ждать по 10-30 секунд. При этом единственное, что я заметил, резко возрастает в мониторинге значение параметра Batch requests/sec и вместе с ним SQL Re-Compilations/sec.
Развернул из выгруженного DT-шника БД у себя на рабочей машине (совсем офисная станция) в файловый вариант - всё летает. Мгновенно любые операции выполняются.

Подскажите, пожалуйста, что где подкрутить/посмотреть чтобы исправить ситуацию. Выслушаю любые рекомендации, т.к. устал уже в стенку вторую неделю долбиться.

ну и тормоза только с сервера теримналов? а если открывать с той машины, где сервер стоит?

(0) Кстати... Помнится мне, чтоб был как-то релиз сервера SQL, который принципиально не желал отъедать больше полугига оперативы, какие бы настройки у него не стояли. Может, стоит его обновить до последней редакции?

(33) этот процессор плох даже не тем что частота у него не очень высокая а тем что он 2011 года. Но в любом случае это не основная причина твоих "тормозов".

ну и общие дельные советы тут http://alkosfera.com/blog/o-bystrodejstvii-nastrojke-oborudovaniya-dlya-1s-i-ne-tolko/

Если только 10ть пользователей, можно попробовать перенести сервер 1с и SQL на машину c Core i5/i7 с частотой больше 3,5Ггц и 8Гиг оперативы (если есть конечно )- сиквелу отдать 6 остальное 1с и системе и посмотреть что в этом случае будет. Сильно боюсь что Оптерон не тот выбор для ERP

(35) Нагрузки по сети нет. Пробовал делать всё локально (клианта запускать на сервере БД) - всё то же. Антивирусов нет там. Экономии электричества нет. Аксимальная производительность в плане электропитания.
(38) Те же тормоза и локально На сервере БД.
(39) Это не тот вариант. Во-первых, до недавнего времени и этот экземпляр SQL-сервера отъедал отведённые ему 90 гигов. Также есть идентичный сервер (железка) с идентичным экземпляром SQL-сервера, с такими же настройками по памяти, он кушает хорошо, 90 гигов.
(40) Согласен

(6) Про rls, где настраивается вот тут посмотри: https://youtu.be/s7IPFswRX1I

Попробуйте все настройки сервера приложений поставить по умолчанию. Пускай в одном процессе все работают. Сервер приложений, надеюсь, 64 битный?

Вспомните на каком железе наши пращуры запускали УПП в далеком 2005м (PIII-800 или P4-1800) и как оно тормозило тогда. Вангую что какой-нибудь Core I3-8350K в паре с Samsung 960Evo/Pro уделает этот Оптерон в пух и прах

(44) В одном процессе они работали сначала, когда я ещё не взялся за проблему. И тогда было всё по умолчанию. Сервер приложений да, 64-х битный.

запусти (23)

(47) да нет там блокировок раз память не кушает и загрузки процов нет. Просто платформа сервера старая.

(47)
***total***    963606.0    100.0
LAZYWRITER_SLEEP    303250.0    31.5
SLEEP_TASK    89881.0    9.3
HADR_FILESTREAM_IOMGR_IOCOMPLETI    60230.0    6.3
QDS_PERSIST_TASK_MAIN_LOOP_SLEEP    60012.0    6.2
QDS_CLEANUP_STALE_QUERIES_TASK_M    60012.0    6.2
XE_TIMER_EVENT    60090.0    6.2
LOGMGR_QUEUE    59987.0    6.2
REQUEST_FOR_DEADLOCK_SEARCH    60069.0    6.2
FT_IFTS_SCHEDULER_IDLE_WAIT    60012.0    6.2
DIRTY_PAGE_POLL    60058.0    6.2
SQLTRACE_INCREMENTAL_FLUSH_SLEEP    60136.0    6.2
BROKER_TO_FLUSH    29857.0    3.1

Всё остальное в результирующей таблице по нулям

Вот тут, кстати, не раз упоминалась ущербность серверных процессоров AMD и в частности Opteron, для задач 1С.

Хорошо. А как же быть тогда что в файловом варианте на том же AMD Opteron всё работает быстрее некуда? Или тут какие-то другие технологии работают?

(50) Вроде уже давно известно, что в файловом варианте, но с _одним_ пользователем базы 1С "летают".

(51) А в SQL с одним?

(52) Заметно замедляются. Но уже с двумя и более пользователями в базе вы заметите, что люди работают, а не ждут окончания транзакции соседа.
Ну и да, в (41) верная ссылка, стоит задуматься. Процессор i7 7700K стоит 25 000 рублей, поставите туда 64GB RAM и будет вам нормальный сервер приложений. Не такие великие деньги для фирмы.

(0) Ограничь потребляемую память скуля. Скуль на одном сервере с 1С?

(54) Он же написал "6. SQL-серверу выделено 90 ГБ ОЗУ"

(54) "4. Там же установлен сервер приложений 1С (8.3.10.2466). С SQL-сервером общаются в режиме Shared memory. "

(54) Ну чтоб сразу скушал под себя свои ресурсы + приоритет выстави высокий.
ТемпДби на отдельном диске?
(56) в (33) написал что свободно 100

(57) Да, TempDB На отдельном SAS диске, 8 файлов.
Свободно 100 потому, что не ест SQL-сервер больше 500 мегабайт почему-то

(58) Выстави минимум и максимум потребляемой памяти одинаковый, выстави отложенный запуск служб и перезагрузку сделай. Скуль должен сразу свою оперативу забрать

Ещё + наблюдение. При операциях чтения/записи документов и списков, один из процессов rphost активизируется и грузит почти на полную катушку одно ядро из 64-х. Понятно, что 1С нифига не знает о паралелльности, но всё же.

(60) Ищи неоптимальный код. Возможно, что какой-то из запросов в документе читает 100500 никому не нужных данных. Или сами запросы неоптимальны с точки зрения сервера БД.

16ти ядерный 6276 имеет кэш L3 1Мб на ядро. В результате серверу 1с работает именно с этим одним мегабайтом. Найдите этот процессор в однопоточном тесте http://browser.geekbench.com/processor-benchmarks  и убедитесь что процессор медленнее чем Intel Core 2 Quad Q9450. А потом уже ищите неоптимальный код, настройки скуля и т.д.

Не потянет 7ми летний проц сегоднящние приложения даже в мультипоточном тесте, он соответствует примерно Intel Core i7-940

сколько процов кушает SQL?

(62) Кеш третьего уровня один на все ядра. По вашему 1С вместо оперативы использует кеш?

(60) распараллеливания поток 1С не делает. Если загрузился в один рпхост, то все так и будет

(58) Темповые таблицы 1С формирует в бешеном количестве. Нам помогло перенос базы tempdb на RAMDisk размером 50 ГБ. Резко увеличилась скорость работы. Но это было видно по монитору доступа к файлу базы tempdb

Поставь у рабочего сервера (в кластере серверов 1С) по 1 ИБ и по 1 соединению на 1 РП, ядра будут активнее использоваться

+(67) http://3.bp.blogspot.com/-m6HZyM3FSRg/VJLI83mv2DI/AAAAAAAAAHA/LT1fjB0bOYc/s1600/83_2.JPG речь о полях с картинки, где стоят цифры 1 и 25: ставь 1 и 1

Проц в утиль

(67) (68) Так и сделано было. Вычитал в какой-то статье.

(64) речь про Opteron 6276, а не Core I9

(0) попробуй прикрутить performance dashboard и глянуть в ней, где тормоза. Понятный и бесплатный инструмент, решили при помощи него массу проблем с производительностью. На 2012 SQL правда не ставил, но вроде поддерживается.

УПП на этой же платформе 1С крутится?

Нет, там что-то постарее. У нас другие админы УПП занимаются, поэтому ничего сказать по этому поводу не могу

(74) Может проблема в платформе... Чуть по-новее платформа тоже rphost загружает жутко, а Sql сидит на месте.

+(75) Причем загружает rphost так, что потом у пользователя вываливается ошибка о нехватке памяти для выполнения операции. И не освобождается при бездействии.

(67) одно соединение на процесс даст неебические тормоза для отчетов, которые формируются через фоновые задания, т.к. каждый раз будет создаваться новый процесс.

полностью поддерживаю (77). Процессы будут постоянно создаваться и завершаться. Минимум 10 соединений на процесс.

(0) а формы списка все тормозят или отдельные? Может они у вас доработаны и там запросы что капец?

(72) Не знал про такой инструмент. Пошел смотреть :)
Может мануал готовый есть по использованию?

(70) поставь

Количество ИБ - 3
Количество соединений на процесс - 64

и смотри, за регламентными заданиями, что бы они не скапливались все в одном рхосте, если скапливаются - его надо убивать

кроме того в свойствах рхоста мониторь параметр "реакция сервера" если больше 0.8 - то это верный признак проблемм в нем, нормальные показатели 0.1...0.3

(81) + методы борьбы с рег заданиями в одном рхосте я знаю только одно - ребут этого процесса

По поводу нагрузки на процессоры. 1С-ка умеет потоки поэтому даже 1 rphost нормально нагружает разные ядра. Но! 1С-ка не умеет работать с NUMA NODES. Тоесть рабочий процесс работает в рамках ядер одного CPU (точнее группы CPU) а распределением новых rphost между группами CPU занимается система. В итоге имея несколько CPU можно получить картинку когда один нагружен под завязку а другие простаивают.
Детальнее тут: http://its.1c.ru/db/metod8dev#content:5903:hdoc:_top:numa

(82) лучше фоновые выносить на отдельный сервер, на клиентские сеансы очень благотворно влияет.

(71) L3 общий для всех ядер

(80) судя по всему, это для 2012
https://blogs.msdn.microsoft.com/sql_server_team/sql-server-performance-dashboard-reports-unleashed-for-enterprise-monitoring/

это для 2008 (нужна небольшая доработка напильником)
https://blogs.msdn.microsoft.com/vascov/2008/09/30/using-performance-dashboard-with-sql-server-2008/

(0) > после последней перезагрузки, не более 500МБ
Мне кажется главная причина тормозов в этом. У меня в файловом режиме при хапуске ЕРП кушает 500, когда открываю справочники/документы доходит до гигабайта, и это только 1 человек. проверьте все-таки максимальный объем памяти под mssql, если он не ограничен попробуйте повысить минимальный.

(85)16KB L1 data cache per core.
64KB L1 instruction cache shared per two cores (per module).
2MB L2 cache shared per two cores (per module).
8MB L3 cache shared per eight cores (per die).
14MB total L3 cache available when using HT Assist.
http://www.cpu-world.com/CPUs/Bulldozer/AMD-Opteron%206276.html

даже в далеком 2011 16 ядер Оптерона проигрывали 4м ядрам i7 -940, что говорить 6 лет спустя...

(89) проигрывали В ЧЕМ???

если Вы посмотрите, то поймете, что есть однотактовые и более большие команды, при чем для этих для процессоров они практически одинаковые, что JMP занимает 1 такт ядра одного, что и другого....

так, что если говоришь А, давай уточняй в чем именно быстрее...

(90) проигрывали в частности в многопоточном процессорном тесте geekbench http://browser.geekbench.com/processor-benchmarks. Проигрывает в однопользовательской работе в ЕРП. Проигрывает потому, что после выхода архитектуры Core в 2006 до появления Райзенов, горячие АМД всегда сливали процам от Интел. Чтобы далее не развивать холивар, оставляю топикстартеру самому решать - что делать менять платформу или крутить настройки SQL, но сам вижу что мой двухядерный I3-8350K +Samsung 960Evo даст 85 попугаев Гилева под SQL, и соответственно ЕРП под одним пользователем летает.

(91) три раза ХА.... бач ориентирован на 3д (в том числе и на игры), там очень много расчетов с плавающей точкой... в 1с таковых не так и много, а в скуле так вообще почти нет....

разумеется заменой проца например на I7 3.8г увеличишь скорость вычислений, но не в 7 раз а раза в 1.5.... и это на одном потоке, а при 20 рхостах разница будет вообще нулевая...

Новости с полей.

Перетащил в качестве эксперимента сервер 1С на виртуалку, хост которой на Intel Xeon E5-2640 2.5GHz 2 процессора. Виртуалке выделено 4 ядра и 10ГБ ОЗУ.

Летает.

Теперь вот думаю - оставить там или прописать на ПМЖ на таком же серваке с таким же Intel'ом?

(93) а интересно, в этой виртуалке тест Гилева тоже запускался? Просто для сравнения.

(92) Вы наверное, просто давно не работали на современных процессорах от Интел :-)

(94) Кстати, нет. Сейчас попробую

(92) "а при 20 рхостах разница будет вообще нулевая..."

Немного не понял, о каких рхостах идет речь. Если о процессах rphost - так их должно быть в количестве одной штуки. Мы же про 8.3 говорим.

Представляю, как бы удивился автор, разверни он свое хозяйство на i7-7700.

(95) А какова разница в производительности сервера 1С предприятия при равной частоте процессора Intel 2017 года выпуска и 2011 года выпуска?

(94) 10.1 набрал. :-)
Я даже не знаю как это расценивать.

(100) И что именно "летает"?

(100) расценивать это как 10.1 попугаев.

(101) Типичные операции, озвученные в (0): открытие списков и проведение документов. Они выполняются так же быстро как и при файловом варианте.

Стресс-тест того же Гилева показал рекомендуемое количество пользователей 126, максимальную скорость 117420 КБ/сек.
Если я, конечно, в нужное место смотрел.

(0) попробуй MS SQL Profiler получи любой тормозной запрос.. получи его текст...разбери запрос по косточкам.

(105) имея текст запроса уже можно напрямую в БД его слать, исключишь влияние 1с сервера..

(103) >> значение параметра Batch requests/sec и вместе с ним SQL Re-Compilations/sec.
Эти параметры также возрастают резко или иное поведение наблюдается? По сравнению с вариантом когда сервер приложений 1С и SQL на одном сервере?

сервер изначально не оптимальный для быстрой работы 1с,
Для начала отключил бы все экономайзеры питания.
Затем проверил настройки рейда, кэширование, размеры буферов, проверил бы батарейку и т.п.
Затем откатил бы ОС и SQL на минимально возможные версии.
Затем я бы жестко распределил ядра и память по процессам, qpi узкое место.
Затем  отключить tcp offload на сетевых картах сервера, если сетевая карта не поддерживает данный контроль, то трафик сильно тормозит.
Затем у скуль сервера привести настройки в соответствии с требованиями 1с
Дальше поправить настройки рабочих процессов, сделать так что бы на каждую базу не зависимо от кол-ва рабочих сеансов, создавался только 1 рабочий процесс(замечено, что ragent замедляется с ростом rphost).

Но лучше этот сервер отдать по терминалы, а для 1с и субд купить новый. Причем лучше 2 сервера, под 1с с максимальным шустрым процом, по субд с максимальной шустрым вводом\выводом.

(108) "проверил настройки рейда, кэширование, размеры буферов" // А что там надобно проверять?

(109) тип рейда, в каком режиме работает кэширование, жива ли батарейка, какой размер страйпа и блока. Обычно это делают админы и не заочно :)

(110) Применительно к 1С админам что-то знать нужно для настройки рейда?

(111) я же написал, тип рейда, в каком режиме работает кэширование, жива ли батарейка, какой размер страйпа и блока.

(112) Или ты не понял, или Я не так изложил мыслю. Админ, допустим, не знает, что в рейде будет база 1С (сервер 1С и СУБД) работать. Какие-то отличия от настройки этого рейда по сравнению с любой другой СУБД есть?

(113) ну админы часто любят делать 5,6 рейды и прочие их комбинации, 0 рейд - обеспечивает надежность, но фактически замедляет запись, особенно если не работает кэширование записи  в следствии не работающей батарейки, не совпадающий размер кластера с скуль приводит так же к избыточному чтении записи.
в общем админ должен понимать что и зачем делает.

у Гилева была довольно подробная инструкция по дискам

(114) а как проверить, что размер кластера совпадает со скулем?

(115) не хочу быть испорченным телефоном, ищите статей полно.
Например http://sqlcom.ru/dba-tools/disk-partition-alignment/

Какие времена откликов mdf и ldf рабочей базы и темпдб, когда идут эти тормоза?

(108)Простейший тест производительности СУБД(в моем случае - pgbench) показывает результат два раза меньше при снижении тактовой частоты процессора с 3.4 GHz до 1.6 GHz.
Думаю, что "шустрый проц" не такая уж и необязательная вещь для СУБД.

(114) да и 0 раид ну ни как не обеспечивает надежность, надежность обеспечивается с 1 раида и да, не рекомендуйте ту туфту что в (116)

(119) да виноват, ошибся, имелось ввиду зеркало 1 рейд,
про 116 фигня или нет, решает каждый сам для себя.

(108) Экономайзеров питания нет
RAID 10, кэширование включено, батарейки живы.
В откате на минимальные версии смысла не вижу.
Ядра и память имеет смысл жёстко распределять тогда, когда ЦП и память конкретно являются узким местом. У меня далеко не факт что это так.
TCP offload давно отключен. Но это и не при чём, т.к. я уже неоднократно говорил в теме что и без сетевого трафика (локально) тормоза были те же.
1 ИБ на рабочий процесс я делал. Писал об этом выше. Толку ноль.
(116) Начиная с Windows Server 2008 (возможно R2) система сама умеет выравнивание.

(121) попробуй разнести на разные компы 1с и субд, например развернуть на своем компе SQL сервер и проверь как будет работать 1с или наоборот

(122) А я в (93) не это разве сделал?

(121) на тему файловый или sql  вариант использования, в чем разница, что быстрее,  полно статей( у того же Гилева). Поэтому рекомендую почитать.

(123) всю ветку не читал.
и еще посмотри настройки сортировки у тормозящих списков в 1с. Часто бывает что включена сортировка по какой нить колонке типа суммы или контрагента. С какой скоростью открывается дин.список с сортировкой по дате?  Бывало приходилось делать авто сброс настроек сортировки.
возможно твое железо работает на максимуме для клиент-серверного режима. Самый быстрый клиент-сервер почти в 2 раза медленнее файлового режима в один поток.

и еще вопрос, на сервер крутятся другие базы?
я бы постарался снизить общую нагрузку на 1с и субд, за счет отключения "полезных" фоновых заданий. Поотключать у всех баз полнотекстовый поиск, по отключать всякие новости, проверки контрагентов. Если баз много, все эти задания создают очень существенную нагрузку.

В продолжение эпопеи.

Выключил режим отладки на рабочем сервере, все проблемы исчезли.

(127) алилуйя. Хотя на своих продакш серверах и рабочих станциях особо разницы не замечаю. По крайней мере для УПП и БП3.

)))

(127) вообще странно...

(130) Просто он попутно сервер 1С:Предприятия перезапустил - это и дало эффект...

(130) Ничего странного. Отладка тормозит адски. Даже в документации про это есть.

(132) Пруф на документацию, где будет написано на сколько конкретно снижается производительность сервера 1С:Предприятия при включении отладки, будет?

надо тест Гилева сделать с отладкой и без...

(133) http://its.1c.ru/db/v8doc#content:80:1 - кто же тебе напишет, насколько конкретно снизится? Поставь эксперимент.

(135) простое включение отладчика для службы - практически не замедляет работу....

замедляет работу только реальная отладка (трассировка боевой базы), и то не как в сабже. Разумеется можно повесить блокировку таким образом, но сабж не об этом...

(136) Цитата из (135) "замедление рабочего процесса сервера «1С:Предприятия» во время работы, если сервер работает в режиме отладки (ключ -debug)." У нас - замедляло. Чем больше пользователей одновременно работало, тем больше.