Вход | Регистрация
    1  2  3
1С:Предприятие :: 1С:Предприятие 8 общая

Жутко тормозит база при пользователях от 40 и больше

Жутко тормозит база при пользователях от 40 и больше
Я
   gendalfbbk
 
16.10.19 - 14:59
Стоит сервер:
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с;

Ничего не помогает :(
Помогите, пожалуйста, решить проблему!
 
 
   gendalfbbk
 
201 - 17.10.19 - 15:58
(200) незнаю - это только мои наблюдения были что тормоза появлялись только от 40 подключений
   Sapiens_bru
 
202 - 17.10.19 - 16:20
(199) Это всего лишь лишние 48 тысяч записей в одной таблице итогов (2*2000*12), в масштабах 150гб базы ниочём. И точно не может влиять на всякие открытия форм и тормоза в целом.

Ежов, не поделишься как удалось найти эту штуку? Или просто таблица итогов подозрительно большая оказалась?
   gendalfbbk
 
203 - 17.10.19 - 16:27
(202) обработка есть МинимальныеДатыРегистров.epf
С помощью нее нашел
   H A D G E H O G s
 
204 - 17.10.19 - 16:50
(202) При проведении документов по данному регистру они начинают струячить в таблицы итогов на каждый месяц, но не в этом суть. Там есть промежуточная вставка в tempDb (временная таблица), что ведет к деградации производительности в целом. Запросики мелкие, легкие, но их тыщи на ровном месте.
   H A D G E H O G s
 
205 - 17.10.19 - 16:51
Хоспади, там обработка тоо.
https://yadi.sk/d/LJ2xEA5Zj6pz9w
   H A D G E H O G s
 
206 - 17.10.19 - 16:53
Я уже предлагал на на самом главном форуме запретить писать в РН датой, меньше чем 2000 год ну или какая-то дата начала учета на платформенном уровне, но мне там доблестные коллеги сказали (не 1С, а вот эти вот самые 1Снеги), что есть дата запрета редактирования, а кто ее не ставит - у того тцмо.
   Sapiens_bru
 
207 - 17.10.19 - 17:41
(204) Думал может я чего не знаю. Но нет.

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

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

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

А при чем временные таблицы вообще не понял. Итоги по вложенным запросам делаются. А база на ут 10.3 почти наверняка на автоблокировках, а даже если нет то без rcsi
   rphosts
 
208 - 18.10.19 - 02:30
(207) на автоматических и с rcsi в базоводе для контроля остатком монопольно блокировалась-бы вся таблица, так что авто+rcsi = злое зло!
   rphosts
 
209 - 18.10.19 - 02:31
(199) а теперь проверяем что все какие положено регламентные выполняются!
   Sapiens_bru
 
210 - 18.10.19 - 04:33
(208) Опять не понимаю. Объяснишь?

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

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

думаю, что поможет/
   gendalfbbk
 
212 - 18.10.19 - 09:14
(211) ограничен, в шапке темы написал, что 16 гиг. И каждую ночь сервер перезапускается
   gendalfbbk
 
213 - 18.10.19 - 09:14
(211) в день от силы 5-6гиг съедает
   gendalfbbk
 
214 - 18.10.19 - 15:58
Проблема осталась :(
Но пользователь    Sapiens_bru
помог мне выявить проблему - не оптимизированный и неправильный код в конфиге, часть кода писалась еще лет 8 назад, когда пользователей было меньше, как и сама база была маленькая - очень много запросов к базе выполняется.
   sitex
 
215 - 18.10.19 - 16:14
(214) Оптимизируй код раз нашел проблему.
   Rovan
 
216 - 18.10.19 - 16:35
(214) и если продолжить мысль, то на 30 пользователях это кривой код с кучей запросов выполняется быстрее, чем на 40
- вероятно не хватает памяти 1С-серверу (rphost) под кэширование
   gendalfbbk
 
217 - 18.10.19 - 16:54
(215) Это работа не моя, а программиста, ему уже передал задачу - работает над кодом. (216) думаю частота памяти не справлялась с запросами 40 пользователей, а кол-во памяти хватает
   rphosts
 
218 - 18.10.19 - 17:09
(210) хоть внутри оракул и версионник, но по дефолту он (как и сиквел) - ReadCommited а не ReadCommitedSnapshot (Isolation), но при работе с 1С у Postgre/Oracle на автоматических блокировках Serializable с минимальной гранулярностью - таблица.
   rphosts
 
219 - 18.10.19 - 17:09
(217) а ты кто?
   gendalfbbk
 
220 - 18.10.19 - 17:17
(219) Сисадмин
   rphosts
 
221 - 18.10.19 - 17:21
(220) поиск узких мест - скорее работа одинэснега как-бэ.
   rphosts
 
222 - 18.10.19 - 17:21
+ (221) т.к. найти часто даже не половина дела а значительно меньше.
   rphosts
 
223 - 18.10.19 - 17:34
gendalfbbk, слушай, а может тебе в одинэснеки-оптимизаторы перепрофилироваться?
Подумай!
   Sapiens_bru
 
224 - 18.10.19 - 18:15
Настроил счётчики.
Диск простаивает.
Попадание в буфер у sql 99.98%
Памяти хватает.

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

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

Абсолютно точно причину не выявил. Может латчи, может ограничения системной шины или таймингов памяти.
Грешу на спам запросами, надо эту лажу исправлять.
Посоветовал не рубить в следующий раз сеансы, а попросить пользователей закрыть формы, вызывающие спам и посмотреть будет ли результат.
   Sapiens_bru
 
225 - 18.10.19 - 18:25
(218) Прости, это поток сознания какой то, а не объяснение.

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

На Постгри же автоматический режим работает только в read commited. Впрочем как и управляемый. Но в отличии от управляемого(где программист сам ставит упр.блоки) в автоматическом режиме 1С вынужден просить Постгри поставить таблок.
И да, версионник в качестве СУБД сразу хоронит многопользовательскую работу 1Са , если блокировки автоматические.
Но к mssql rcsi это никак не относится
   Sapiens_bru
 
226 - 18.10.19 - 18:32
(212) зря сервер перезапускается. Каждую ночь он должен делать обслуживание ИБ и продолжать работать дальше.
Перезапуск надо настроить не для сервера, а для серверных процессов 1С. Тогда в случае проблем с памятью те сами будут перезапускается и никто этого даже не заметит.
   gendalfbbk
 
227 - 18.10.19 - 23:24
(221) я думал проблема сервера который я настраивал, а оказалось, что проблема самой базы.
   gendalfbbk
 
228 - 18.10.19 - 23:24
(223) немного не мое
   gendalfbbk
 
229 - 18.10.19 - 23:26
(226) ночью обслуживание делается. ну а перезапуск я сделал - так как когда то давно помогало от тормозов базы на старом сервере)
   рокот
 
230 - 19.10.19 - 12:20
Мне одному кажется что куча нескладушек? Если тормоза из-за неоптимального кода, то почему на старом сервере их не было? Почему тормоза резко начинаются на пользователях больше 40, а не раньше позже?
 
 Рекламное место пустует
   Sapiens_bru
 
231 - 19.10.19 - 12:54
(230) Это просто. Люди не любят загадочной фигни. Обязательно должно быть объяснение. Например молния бъет в землю - значит на небе живёт бог грома. Потому что вообразить полуголого мужика с молнией в руках проще, чем продумать и экспериментально доказать существование электронов.

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

Всё нужно проверять практикой и ставить опыт, поэтому я и не пишу что нашел причину. Так это или нет покажет опыт. Я нашел вероятную причину и предложил простой способ её обхода. Даже не обязательно устранять, чтобы проверить.
   s-n-a-y
 
232 - 19.10.19 - 13:33
Я все не читал, просто интересно, писал ли кто-нибудь, что проблема возможно в скорости сети? просто тут написано про 40+ rdp-подключений и что дело не в железе
   gendalfbbk
 
233 - 19.10.19 - 13:34
(230) после перехода на новый сервак и кол-во пользователей увеличилось. Возможно поэтому и небыло таких тормозов. Как я и говорил у меня мало опыта в настройке SQL + 1C, я бы сказал почти нет.
   gendalfbbk
 
234 - 19.10.19 - 13:36
(232) сеть не занята, и я писал ранее, что тормозит только одна база, можно параллельно на терминале делать другие операции и даже запустить другую базу (у меня файловые базы еще есть), поэтому дело не в RDP
   rphosts
 
235 - 20.10.19 - 10:28
(225) вот тут более подробно расписывается http://sqlcom.ru/dba-tools/sql-server-and-snapshot-isolation-level/ начиная с "Как работает версионность". С автоматическими блокировками получаешь или грязное чтение или монопольную блокировку всей таблицы.
   Фрэнки
 
236 - 20.10.19 - 11:06
(234) дело именно в RDP
Просто периодически такие сообщения в сетях всплывают, что стоял старенький сервер и с RDP все прекрасно работало, но решили его заменить на более современный, более мощный и под большее число одновременно открытых сеансов. А после замены и установки всего ПО с нуля на новый сервер вдруг оказывается полная и ничем необъяснимая хрень в этом самом RDP

При таком количестве пользователей системы (40 и больше) никуда не денетесь и придется все-таки отделить СУБД от 1С-Сервера, а затем и Терминал-Сервер от 1С-Сервера и будет полная трехзвенка. Но и тогда нужно будет испытывать мучения с установкой и настройкой софта таким образом, чтоб при работе с 1С-приложениями не тормозили RDP-сессии.
   Фрэнки
 
237 - 20.10.19 - 11:09
И затем, в конце-концов, окажется, что Терминал-Сервер будет работать удовлетворительно не на обновленном серверном ПО, а на устаревшей и никак необновляемой несерверной Виндой 7.
   shuhard
 
238 - 20.10.19 - 11:21
(236) не факт,
150гб база при кривой настройке rphost и сиквела, а за 3 дня ТС ни чего внятного про настройку не выдал,

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


заставьте ТС снять счётчики или забаньте, чтобы не мучился =)
   ДенисЧ
 
239 - 20.10.19 - 11:21
(236) Как раз отделять в первую очередь душно терминал. А 1с-сервер и субду держать вместе (на одном логическом компе) как можно дольше.
   rphosts
 
240 - 20.10.19 - 11:26
Был случай когда кто-то из админов включил буферизацию пакетов.. т.е. пока не насобирается пакетов на 32 кб что-ли - ничего никуда не отправлялось. Тормозило ощутимо, хотя вроде что за финя 32кб
   shuhard
 
241 - 20.10.19 - 11:50
(240) угу
и MTU на NIC легко может гешефт испортить
   tesseract
 
242 - 20.10.19 - 23:07
(236)
>>А после замены и установки всего ПО с нуля на новый сервер вдруг оказывается полная и ничем необъяснимая хрень в этом самом RDP

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

40 юзеров - ну это не много, если SQL регулярно хоть индексы дефрагить. Опять же нагрузка и просмотр чего там накосячили прошлые "дети маминой подруги".
   gendalfbbk
 
243 - 29.10.19 - 11:58
Проблема осталась. кол-во запросов немного сократили, но это не помогло. Все равно тормозит резко база когда или 41 или 42+ пользователь в базе работают.
Могу показать сбор счетчиков, чуточку разобрался в perfmon. Только укажите какие собирать.
   gendalfbbk
 
244 - 01.11.19 - 10:54
Пока решил проблему возвратом на старый сервер.
Либо что то с железом либо я криво настроил
   ansh15
 
245 - 01.11.19 - 11:29
(244) Попробуй многопоточный тест(нашего коллеги по форуму) http://fragster.ru/perfomanceTest/
И на старом компьютере и на новом. Сравнить, при скольких одновременных потоках начнется падение производительности. Только желательно без пользователей, иначе они вообще работать не смогут.
   StanLee
 
246 - 01.11.19 - 11:44
(0) почему rdp и скуль на одном сервере?
вот пример:
1. сервер RDP xeon x3440, 32 гига, диски ssd, 43 юзера сейчас сидят, память занята 14 гигов, проц почти не занят, 1С на тонком клиенте
2. сервер SQL xeon e5-2609, 128 гигов, диски ssd, всего сидят около 70 юзеров в базе, память занята 70 гигов, загрузка проца 15-50%
думаю у тебя диск дрючится по-черному, и подкачкой и работой скуля, и проца не хватает, разделяй серверы
   StanLee
 
247 - 01.11.19 - 11:46
почему админы всегда пытаются поставить "как им кажется достаточное железо", которое нифига не достаточное, у стольких клиентов уже на таких админов насмотрелся, жуть и печаль :(
   Vstur
 
248 - 01.11.19 - 11:56
(247) бюджет-с :-)
  1  2  3

Список тем форума
Рекламное место пустует  Рекламное место пустует
Миста — веселый ресурс со своими эксклюзивными тараканами Ymryn
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.