Имя: Пароль:
1C
 
На sql - миллисекунды, сервер 1с - клиент 3 минуты
0 mr_K
 
05.03.19
14:10
Регистр сведений. Одно измерение, 2 ресурса. Простой запрос на выборку измерений с условием по 1 из ресурсов. Индексов по ресурсам нет. В профайлере запрос в sql выполняется влет, несколько миллисекунд. Результат на клиенте я получаю через несколько минут. Хотя еще вчера я и на клиенте получал результат через несколько секунд.
1 mr_K
 
05.03.19
14:12
Сервер 1с, а вместе с ним и бд - перезагружали. Выгрузка-загрузка - слишком долгий вариант для несколько сот гигабайтной базы. Что еще можно сделать?
2 RomanYS
 
05.03.19
14:12
Сеть?
3 VladZ
 
05.03.19
14:13
(0) Мало информации. Возможно "еще вчера" у тебя не было данных. А сегодня их - вагон и маленькая тележка.
4 mr_K
 
05.03.19
14:15
(2) Админы говорят, что ок
(3) Там и вчера и сегодня овер 1кк записей в этом РС. Смысл в том, что сегодня на sql запрос выполняется влет. А вот результат до клиента едет крайне долго. Тут проблема не в этом запросе, его просто было проще всего в профайлере отловить. Вообще все жутко тормозит с утра.
5 RomanYS
 
05.03.19
14:17
(4) Проверить локально на сервере "админы говорят"
6 RomanYS
 
05.03.19
14:18
Проверить толстый и тонкий клиент
7 VladZ
 
05.03.19
14:19
(4) Проверить загрузку сети на сервере, загрузку диска на сервере и загрузку процессора.
8 mr_K
 
05.03.19
14:19
(7) все в пределах нормы. т.е. около 0%
9 ДенисЧ
 
05.03.19
14:19
Ммм... Лимон записей на клиента тянуть?
10 VladZ
 
05.03.19
14:23
В итоге, какую проблему нужно решить: "Вообще все жутко тормозит с утра."  или "Результат на клиенте я получаю через несколько минут." ?
11 mr_K
 
05.03.19
14:25
(9) это условие в запросе. я просто на нем тестировал перфоманс)
(10) мне кажется это связанные вещи. все тормозит, один из запросов, больших, выполняется по полчаса, вместо нескольких секунд. у него в условии сабжевый подзапросик простенький. начал его анализировать.
12 mr_K
 
05.03.19
14:26
(9) так как условие НЕ В (искомая выборка). Чтобы на клиенте получить из миллиона - несколько штук.
13 RomanYS
 
05.03.19
14:27
(12) так получи их на сервере сразу
14 VladZ
 
05.03.19
14:27
(11) "все тормозит," - проверь среднюю длину очереди диска на сервере, проверь регл.задания, посмотри кто кого блокирует (возможно, взаимоблокировки мешают работать).
15 mr_K
 
05.03.19
14:39
запустили локально этот запрос. так же несколько минут выполнялся. в течении этого времени сеть выше 10% не прыгала, CPU - ядро где rphost крутится всегда около 15-20%, с редкими скачками до 60%. очередь к диску - 0.01-0.02.
16 mr_K
 
05.03.19
14:41
Сервер монструзный. База на террабайтном SSD. Памяти 128gb. Так что сервер точно не причем)
17 Rema Dan
 
05.03.19
14:44
(0) Нету текста запроса. Нету описания измерений региста. Нету описания процесса проверки на клиенте (консоль запросов? отладчик?). Нету количества выбираемых запросом данных.
Вангую, что постов через 50 выяснится, что выбираются пол миллиона записей со ссылками на справочник в консоле запросов и платформа для каждого из них получает представление.
18 fbear
 
05.03.19
14:44
А если перезапустить процесс сервера 1С?
19 dk
 
05.03.19
14:56
чтобы проверить торможение сети или сервера скуля замени все данные на Количество(*)
на сервере точно такой же запрос выполнится (условно), а на клиента всего 1 число полетит
20 mr_K
 
05.03.19
14:59
(17) Выбиралась ссылка, угадал. Заменил на представление - стало пошустрее, около минуты.
(18) Весь сервер перезагружали.
(19) так миллисекунды
21 Вафель
 
05.03.19
15:08
может представления данных вытягиваются так долго?
22 timurhv
 
05.03.19
15:09
(20) Вы через типовую консоль делаете? Она вообще дико тормозная под УФ при больших объемах, я от нее из-за этого отказался.
(21) Кстати да, в модуле же теперь можно свое представление формировать, поди вчера добавили и забыли.
23 Greeen
 
05.03.19
15:10
[пальцем в небо] попробуйте на sql статистики обновить
24 singlych
 
05.03.19
15:15
В консоли помести результат в ВТ и выполни без временных таблиц, посмотри скорость.
25 unregistered
 
05.03.19
15:19
Проверьте сеть, выполнив команду ping с указанием большого размера отправляемого пакета. Параметр -l 65000. 1С-ка обменивается пакетами нестандартно большого размера. Бывает, что при обычных проверках сети проблем не возникает, а большие пакеты теряются.
26 Rema Dan
 
05.03.19
15:32
(20) Вероятнее всего с запросом всё нормально. И с сервером тоже всё номально. Проблема в процессе проверки запроса.
27 H A D G E H O G s
 
05.03.19
15:42
Сегодня словил плюху, типовой, тупейший запрос по распределению взаиморасчетов по документам, уходил в бесконечность, генерируя 100 загрузку ядра и блокировку всех, кто хочет провести распределить расчеты взаиморасчетов (а это печать ТОРГ12, там чето на авансах завязано).
В итоге, у меня все было забито runnable потоками, SOS_SCHEDULER_YIELD ожиданиями, клиент выяснил, что SQL пользует только 4 ядра из 16 щедро для него отведенных, ибо Standart Edition, а я получил немного
https://lurkmore.co/SCP

И че, и так и не победил. Ребилд индексов, обновление статистики, очистка процедурного кеша, checkdb таблиц, ничего.
Переписал запрос на 2 пакетных запроса и заработала.

Хрен знает.
Причем Query Compiled план все нормально показывал, а фактический план я, конечно, так и не дождался.
28 ДенисЧ
 
05.03.19
15:44
(27) У меня такое один раз было, когда шёл запрос к плану счетов, а субконты не ВЫРАжались. За один месяцу нормально, за другой - полчаса...
29 Cyberhawk
 
05.03.19
16:24
*овнокод в обработке получения представления - такое бывает. Например, получение значений через точку от ссылки.
А платформа на это дело ставит неявную блокировку.
30 cons24
 
05.03.19
16:39
(0) если "вчера работало,а сегодня нет" и "быстро в sql, но медленно в 1с" - получается проблема в 1с.
Перезагружать вы её уже перезагружали. Почистить scntx попробовать...