Стоит сервер:
Intel Core i7-6700K
ОЗУ 32гб
Windows 2008 R2 x64 которая установлена на NVME накопитель samsung ssd 970 evo plus
стоят 2 sata SSD в зеркале Samsung ssd 860 Pro, на них стоит база sql размером в 150гб

На этом сервере стоит SQL 2008 r2 + 1с сервер x64 + 1c клиенты и x86 и x64 (8.3.11.3133).
Все подключаются по RDP к базе 1с.
Все работает быстро до момента когда подключаются больше 40 человек и база моментально медленно начинает работать раза в 5-10. Прошу некоторых выйтииз базы и база раздупляется. Опять заходят больше 40чел. тормоза, выкидываю отключенные сеансы, опять помогает, и снова больше 40 чел и тормоза. При этом памяти свободной много, sql выделил 16гиг из 32гб, процессор на 10-15% загружен.
До этого сервер был более медленный и такого небыло, база была на двух HDD 500гб WD BLACK.

Испробовал разные варианты (Все не перечислю):
переустановкой 1с разных версий и разрядностей;
настройки разных значений в sql базе по популярным рекомендациям в инете;
настройки разных значений в кластере 1с и в реестре в основном из официальных источников 1с;

Ничего не помогает :(
Помогите, пожалуйста, решить проблему!

(147) чего странно-то? Нагрузки нет - вот и тест быстро выполнился.

(149) я вчера делал тест, вообще небыло пользователей, показал около 10 балов

(143) Диски сейчас при 35 работающих пользователях
https://ibb.co/DbK4ND5

снова тест сделал... тест еще чуть лучше показал 39 балов. пользователей в базе активных 37.
я антивирус Eset Endpoint 5 перед этим убил, наверное он так влиял на этот тест. Посмотрю как сейчас будет работать

(151) Вообщем без стороннего вмешательства вы будете просто перебирать настройки.
Меня интересует две вещи : Включен ли протокола «Общая память» (Shared Memory) в MS SQL Server и  второе используется ли это связка с 1С - это проверить можно в sql запросом (в инете много ищите).
Указано ли в кластере, в Параметрах информационной базы Где поле "Сервер баз данные" : lpc:<nameserver>\<namesql> ?

(150) значит есть какая-то паразитирующая нагрузка.
Например, все что ты нам рассказываешь про работу на железе - не правда, и на самом деле всё на виртуалке крутится, которая на одном железе с другими виртуалками - на которых иногда возникает своя нагрузка.
Или какая-то программа/утилита запускается.
Ну и (151) "Вообщем без стороннего вмешательства вы будете просто перебирать настройки. "

(152) антивирус кстати да. На старом сервере он был?

(153) используется, проверял

(154) нет виртуалок у меня

(155) был

(158) Может исключения были настроены

в антивирусе даже делал исключение на проверку папки с БД

на старой базе небыло исключений в антивирусе

на старом сервере (161)

Простую вещь скажу, но проверь: режим энергосбережения на "высокую производительность" выставлен?

(163) Когда антивирус удалял еще и выставил высокую производительность, столяа Сбалансированая - может это и повлияло

Проверил на старом сервере при установленом антивирусе.
В режиме электропитания сбалансированом 11 балов в тесте гилева
В режиме высокой производительности - 25 балов
Значит наверное, что проблема была в этом. Посмотрим как на живой базе будут ли тормоза

(164) а на старом изначально стояла "высокая", да?

(166) нет, тоже сбалансированая

Во-во, а когда в БИОСе C-States отключите, еще +25% скорости будет.

Все равно зависание, 40 чел зашел и тормоза
https://ibb.co/K0z2wv6
Удаление антивируса и высокая производительность электропитания результата не дали

в perfmon не могу разобраться куча все и на что смотреть не понимаю

(170) попробуй отключить журнал регистрации

(170) Поэтому подключайте коллег.Вам предлагали уже

(171) +100
или в старый формат перевести

А есть возможность провести эксперимент?
Подключить к серверу 1С хотя бы десяток пользователей не через терминал по RDP, а обычным образом со своих локальных компов.
Когда общее количество подключенных (и тех кто по RDP и тех, что обычным образом подключаются) достигнет 40, посмотреть на скорость.

Уж очень сильно сомнительно, что проблема в 1С. Не встречал я такой резкой (в разы) просадки производительности строго на одном и том же количестве пользователей. Либо производительность падает линейно и постепенно. Либо она падает, в ходе роста нагрузки, не связанной напрямую с количеством пользователей (то есть например, и два пользователя могут повесить базу, если одновременно начнут массовое перепроведение документов и расчёт регламентов).

(171) где его отключить? подскажите

Провел другой эксперимент...
запустил около 30 копий 1с с базой sql на своем rdp и паралельно было около 25 пользователей rdp с открытыми базами. и тормозов небыло

Проблемы с журналом регистрации маловероятны, т.к. проявились бы сразу на резком росте нагрузки на процессор или диск, генерируемой процессами менеджера rmngr, отвечающим за сервис ЖР.

Хотя попробовать можно.

сейчас 43 пользователя rdp и пока не тормозит, хз из-за чего тормоза, но точно что когда меньше 40 пользователей никогда небыло тормозов

Может пора взяглнуть не деятельность пользюков или одного генератора?

(143) тьфу BOOST

(175) >> где его отключить?

Конфигуратор - Администрирование - Настройка журнала регистрации... - Не регистрировать - ОК.

Если не путаю, то операция требует монопольного доступа к базе. Всех придётся выгнать.

Перевод в последовательный формат делается там же, внизу окошка есть гиперссылка "Изменить формат".

(176) нещитово! Вот если-бы в этих сессиях запустил обработку которая с некоторыми паузами что-то создавала, записывала, проводила, удаляла и т.п.

опять тормозит, 44 пользователя.
Буду пробовать разделять, sql на другую тачку ставить

(183) Не SQL, а терминал. SQL+1C-сервер должен остаться на одной машине.

(0) все не читал.. база в рэйде ? Скорость может резко упасть, если один из винтов в контейнере падает

(183) А причем тут SQL ? Аргументы то какие ? Метод перебора пошел.

(184) понял, попробую

(184) при этом темп дб лучше перенести на другой диск

На старом сервере видеокарта была?

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

(139) Могу только повторно послать в (98)

(176) каждому пользователю РДП выделяет ресурсы сервера, потому 40 сеансов с одного пользователя РДП << 40 сеансов разных пользователей РДП

(189) да, была дискретная простенькая nvidia, на новом встроенная intel

(188) темп дб на диске С который nvme шустрый и так же не загруженый

(190) написал 2 спецам, которые предложили свою помощь, жду ответа на почте

(193) Вынеси тонкого клиента из RDP, может действительно проблема в видеоподсистеме

Все кто что-то про тонкий клиент написали в ветке, попали в перепись бакланов )

В (3) писали про DFSS. На 2008-ом оно ещё не рулило дисками, но уже вполне себе могло мешать рабочим процессам.

(80)    H A D G E H O G s
Благодарность за найденную ошибку в базе. Проблема в минимальной дате денежных средств, стояло на 2 денежных от 0017 года.
Сегодня программист наш поправить и сделает пересчет. Надеюсь в этом проблема была. Завтра буду смотреть

А какая связь с 40 или 43 пользюками?Запускали по регистру выборку без расчитанных итогов?

(200) незнаю - это только мои наблюдения были что тормоза появлялись только от 40 подключений

(199) Это всего лишь лишние 48 тысяч записей в одной таблице итогов (2*2000*12), в масштабах 150гб базы ниочём. И точно не может влиять на всякие открытия форм и тормоза в целом.

Ежов, не поделишься как удалось найти эту штуку? Или просто таблица итогов подозрительно большая оказалась?

(202) обработка есть МинимальныеДатыРегистров.epf
С помощью нее нашел

(202) При проведении документов по данному регистру они начинают струячить в таблицы итогов на каждый месяц, но не в этом суть. Там есть промежуточная вставка в tempDb (временная таблица), что ведет к деградации производительности в целом. Запросики мелкие, легкие, но их тыщи на ровном месте.

Хоспади, там обработка тоо.
https://yadi.sk/d/LJ2xEA5Zj6pz9w

Я уже предлагал на на самом главном форуме запретить писать в РН датой, меньше чем 2000 год ну или какая-то дата начала учета на платформенном уровне, но мне там доблестные коллеги сказали (не 1С, а вот эти вот самые 1Снеги), что есть дата запрета редактирования, а кто ее не ставит - у того тцмо.

(204) Думал может я чего не знаю. Но нет.

Для примера у себя воспроизвел. Сделал документ на 0019 год. Никаких проблем.
"Ну естественно!", подумал я и установил период расчета итогов с 0018 года(в этот момент 1Су поплохело, тот стал считать итоги на каждый месяц за 2000 лет)

Затем провожу документ 0019 года и да, он висит секунды 2, делает свои 24000 записей в таблицу итогов
Провожу документ от 2019 года и вполне логично вижу движения только по 2019 году и текущим итогам.
Чуда не происходит.

Другое дело если бы там итоги на 3000й год были рассчитаны. Тогда Ой.

А при чем временные таблицы вообще не понял. Итоги по вложенным запросам делаются. А база на ут 10.3 почти наверняка на автоблокировках, а даже если нет то без rcsi

(207) на автоматических и с rcsi в базоводе для контроля остатком монопольно блокировалась-бы вся таблица, так что авто+rcsi = злое зло!

(199) а теперь проверяем что все какие положено регламентные выполняются!

(208) Опять не понимаю. Объяснишь?

Насколько я в курсе - rcsi это управление версиями строк, но в отличии от полноценных версионников ms sql даёт доступ к версиям только в запросе с read commited. В автоматическом режиме блокировок таких запросов в принципе не бывает никогда. То есть версии строк будут создаваться, но никогда не будут читаться. И речи о лишних блокировках не идёт.

Наверное путаешь с Postgre/Oracle , у тех особые отношения с режимом serializable - выполняют откат транзакций для поддержания нужного уровня изоляции. 1С с этим жить не умеет, поэтому вместо serializable использует read commited с табличными блокировками.

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

думаю, что поможет/

(211) ограничен, в шапке темы написал, что 16 гиг. И каждую ночь сервер перезапускается

(211) в день от силы 5-6гиг съедает

Проблема осталась :(
Но пользователь    Sapiens_bru
помог мне выявить проблему - не оптимизированный и неправильный код в конфиге, часть кода писалась еще лет 8 назад, когда пользователей было меньше, как и сама база была маленькая - очень много запросов к базе выполняется.

(214) Оптимизируй код раз нашел проблему.

(214) и если продолжить мысль, то на 30 пользователях это кривой код с кучей запросов выполняется быстрее, чем на 40
- вероятно не хватает памяти 1С-серверу (rphost) под кэширование

(215) Это работа не моя, а программиста, ему уже передал задачу - работает над кодом. (216) думаю частота памяти не справлялась с запросами 40 пользователей, а кол-во памяти хватает

(210) хоть внутри оракул и версионник, но по дефолту он (как и сиквел) - ReadCommited а не ReadCommitedSnapshot (Isolation), но при работе с 1С у Postgre/Oracle на автоматических блокировках Serializable с минимальной гранулярностью - таблица.

(217) а ты кто?

(219) Сисадмин

(220) поиск узких мест - скорее работа одинэснега как-бэ.

+ (221) т.к. найти часто даже не половина дела а значительно меньше.

gendalfbbk, слушай, а может тебе в одинэснеки-оптимизаторы перепрофилироваться?
Подумай!

Настроил счётчики.
Диск простаивает.
Попадание в буфер у sql 99.98%
Памяти хватает.

При этом 30 юзеров генерирует 13 тысяч запросов в секунду.

Причина - программист написал условное оформление с запросом к базе и похоже в цикле.
Конфигуратор не смотрел, хватило ТЖ.

Абсолютно точно причину не выявил. Может латчи, может ограничения системной шины или таймингов памяти.
Грешу на спам запросами, надо эту лажу исправлять.
Посоветовал не рубить в следующий раз сеансы, а попросить пользователей закрыть формы, вызывающие спам и посмотреть будет ли результат.

(218) Прости, это поток сознания какой то, а не объяснение.

Вернёмся к теме. Rcsi это фишка mssql. С автоматическими блокировками 1С это работает прекрасно. Просто потому что никак не работает. Небольшой напряг для tempdb и все.
Дело в том что автоматический режим на mssql вообще никогда не использует read commited. И соответственно снапшоты не читает и таблоки не ставит.

На Постгри же автоматический режим работает только в read commited. Впрочем как и управляемый. Но в отличии от управляемого(где программист сам ставит упр.блоки) в автоматическом режиме 1С вынужден просить Постгри поставить таблок.
И да, версионник в качестве СУБД сразу хоронит многопользовательскую работу 1Са , если блокировки автоматические.
Но к mssql rcsi это никак не относится

(212) зря сервер перезапускается. Каждую ночь он должен делать обслуживание ИБ и продолжать работать дальше.
Перезапуск надо настроить не для сервера, а для серверных процессов 1С. Тогда в случае проблем с памятью те сами будут перезапускается и никто этого даже не заметит.

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

(223) немного не мое

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

Мне одному кажется что куча нескладушек? Если тормоза из-за неоптимального кода, то почему на старом сервере их не было? Почему тормоза резко начинаются на пользователях больше 40, а не раньше позже?

(230) Это просто. Люди не любят загадочной фигни. Обязательно должно быть объяснение. Например молния бъет в землю - значит на небе живёт бог грома. Потому что вообразить полуголого мужика с молнией в руках проще, чем продумать и экспериментально доказать существование электронов.

Людям свойственно придумывать взаимосвязи там где их нет.
База начала тормозить - ищем взаимосвязи. Какие умеем те и найдем.

Всё нужно проверять практикой и ставить опыт, поэтому я и не пишу что нашел причину. Так это или нет покажет опыт. Я нашел вероятную причину и предложил простой способ её обхода. Даже не обязательно устранять, чтобы проверить.

Я все не читал, просто интересно, писал ли кто-нибудь, что проблема возможно в скорости сети? просто тут написано про 40+ rdp-подключений и что дело не в железе

(230) после перехода на новый сервак и кол-во пользователей увеличилось. Возможно поэтому и небыло таких тормозов. Как я и говорил у меня мало опыта в настройке SQL + 1C, я бы сказал почти нет.

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

(225) вот тут более подробно расписывается http://sqlcom.ru/dba-tools/sql-server-and-snapshot-isolation-level/ начиная с "Как работает версионность". С автоматическими блокировками получаешь или грязное чтение или монопольную блокировку всей таблицы.

(234) дело именно в RDP
Просто периодически такие сообщения в сетях всплывают, что стоял старенький сервер и с RDP все прекрасно работало, но решили его заменить на более современный, более мощный и под большее число одновременно открытых сеансов. А после замены и установки всего ПО с нуля на новый сервер вдруг оказывается полная и ничем необъяснимая хрень в этом самом RDP

При таком количестве пользователей системы (40 и больше) никуда не денетесь и придется все-таки отделить СУБД от 1С-Сервера, а затем и Терминал-Сервер от 1С-Сервера и будет полная трехзвенка. Но и тогда нужно будет испытывать мучения с установкой и настройкой софта таким образом, чтоб при работе с 1С-приложениями не тормозили RDP-сессии.

И затем, в конце-концов, окажется, что Терминал-Сервер будет работать удовлетворительно не на обновленном серверном ПО, а на устаревшей и никак необновляемой несерверной Виндой 7.

(236) не факт,
150гб база при кривой настройке rphost и сиквела, а за 3 дня ТС ни чего внятного про настройку не выдал,

итого кривой настройки достаточно без привлечения иных версий



заставьте ТС снять счётчики или забаньте, чтобы не мучился =)

(236) Как раз отделять в первую очередь душно терминал. А 1с-сервер и субду держать вместе (на одном логическом компе) как можно дольше.

Был случай когда кто-то из админов включил буферизацию пакетов.. т.е. пока не насобирается пакетов на 32 кб что-ли - ничего никуда не отправлялось. Тормозило ощутимо, хотя вроде что за финя 32кб

(240) угу
и MTU на NIC легко может гешефт испортить

(236)
>>А после замены и установки всего ПО с нуля на новый сервер вдруг оказывается полная и ничем необъяснимая хрень в этом самом RDP

Настраивать надо. От людей привыкших играть в CS:GO и ставить bc кошельки на корп сервер много ожидать не стоит.

40 юзеров - ну это не много, если SQL регулярно хоть индексы дефрагить. Опять же нагрузка и просмотр чего там накосячили прошлые "дети маминой подруги".

Проблема осталась. кол-во запросов немного сократили, но это не помогло. Все равно тормозит резко база когда или 41 или 42+ пользователь в базе работают.
Могу показать сбор счетчиков, чуточку разобрался в perfmon. Только укажите какие собирать.

Пока решил проблему возвратом на старый сервер.
Либо что то с железом либо я криво настроил

(244) Попробуй многопоточный тест(нашего коллеги по форуму) http://fragster.ru/perfomanceTest/
И на старом компьютере и на новом. Сравнить, при скольких одновременных потоках начнется падение производительности. Только желательно без пользователей, иначе они вообще работать не смогут.

(0) почему rdp и скуль на одном сервере?
вот пример:
1. сервер RDP xeon x3440, 32 гига, диски ssd, 43 юзера сейчас сидят, память занята 14 гигов, проц почти не занят, 1С на тонком клиенте
2. сервер SQL xeon e5-2609, 128 гигов, диски ssd, всего сидят около 70 юзеров в базе, память занята 70 гигов, загрузка проца 15-50%
думаю у тебя диск дрючится по-черному, и подкачкой и работой скуля, и проца не хватает, разделяй серверы

почему админы всегда пытаются поставить "как им кажется достаточное железо", которое нифига не достаточное, у стольких клиентов уже на таких админов насмотрелся, жуть и печаль :(

(247) бюджет-с :-)