Имя: Пароль:
1C
 
Как увеличить скорость проведения документов?
0 SherifSP
 
18.09.17
12:47
Здравствуйте мистяне, интересует вопрос оптимизации записи данных в регистры. База УПП 1.2.14, платформа 8.2, 40 пользователей, в регистре "ПартииТоваровНаСкладахУпр" порядка 30 миллионов записей, "ПартииТоваровНаСкладахБух" - 20 миллионов записей, "ПартииТоваровНаСкладахНал" - 17 миллионов записей, документ "РеализацияТоваровУслуг" с 40 позициями проводится 17 секунд, из них 12 секунд занимает запись данных в эти регистры, как можно увеличить скорость записи в регистры?
1 SherifSP
 
18.09.17
12:47
+ (0) База SQL 2008R2
2 SherifSP
 
18.09.17
12:50
+ (0) Свертку базы не рассматриваю
3 Dmitrii
 
гуру
18.09.17
12:53
Если Вы уверены, то учет ведется корректно и регистры закрываются корректно по набору измерений, то никак. В таком случае есть только два варианта:
1. свёртка базы, следствием которой станет сокращение таблиц.
2. апгрейд железа для повышения общей производительности. Тут нужен анализ узких мест для принятия более конкретных оптимальных решений.
4 nicxxx
 
18.09.17
12:54
Железо поменяй. Диски SSD поставь, например вот такие "HP ProLiant 400GB SAS 12G MU SFF SC DS SSD (872374-B21)". У нас работают уже 4 года, ни одного сбоя и скорость хорошая.
5 nicxxx
 
18.09.17
12:54
Лог и данные разнеси по разным дискам. Базу tempdb тоже на отдельный диск.
6 SherifSP
 
18.09.17
12:55
(4) Говорят SSD диски не долговечны?
7 Dotoshin
 
18.09.17
12:56
(2) А Отложенное проведение документов рассматриваете?
http://blog.1c-ei.ru/2009/10/blog-post.html
8 qeos
 
18.09.17
12:57
(6) бекапирование помогает
9 SherifSP
 
18.09.17
12:57
(5) Вот это попробую, спасибо
10 Вафель
 
18.09.17
12:58
Там запрос кривой в УТ10/УПП
11 mistеr
 
18.09.17
12:59
(0) Регистры закрываются? Бардака нет в партиях?
12 SherifSP
 
18.09.17
12:59
(8) База 870 гб, фул бекап 50 минут и бекап 90 гб по сети проблематично перекачивать
13 Dotoshin
 
18.09.17
13:00
(9) Еще можно сам файл базы данных на разные диски разнести, sql2008 вроде позволяет.
14 SherifSP
 
18.09.17
13:00
(11) Бардак есть, но не серьезный
15 nicxxx
 
18.09.17
13:00
Недолговечны бытовые, за 3000 рублей 120 гигабайт. Ты цену этого сначала посмотри:) Говорю же, 4 года уже работают. Ни одного перемещенного сектора. Конфа на основе БП 3.0, типовые документы не используем. Размер _AccRgAT3675 = 110 млн записей, _AccRgED677 = 191 млн. Документы проводятся параллельно в фоновых процессах, никаких таймаутов не набюдаем.
16 mistеr
 
18.09.17
13:00
(0) Профилируй запись. Может там с индексами проблемы, может перестроить нужно.
17 Dotoshin
 
18.09.17
13:01
(12) То есть бэкапы вы совсем не делаете, я правильно понял?
18 Вафель
 
18.09.17
13:01
Небытовые от бытовых отличаются только объемом заразервированного пространства
19 Джинн
 
18.09.17
13:02
(10) Косяк со списанными товарами обычно закрывают прямо в момент внедрения.
20 Yuri 83
 
18.09.17
13:10
(0) А такое время проведения просто при работе пользователей же?
21 Вафель
 
18.09.17
13:11
А может это блокирвоки просто? Очень похоже
22 RS2017
 
18.09.17
13:15
(10) утверждается, что именно запись длится 12 секунд.
(21) Может быть, но тогда проблема должна исчезать при монопольной работе.
23 SherifSP
 
18.09.17
13:22
(17) Делаем, но не перемещаем по сети
24 SherifSP
 
18.09.17
13:23
(21) Блокировок нет
25 RS2017
 
18.09.17
13:26
Документ проводится в текущем периоде? по какой период рассчитаны итоги в регистрах?
26 d4rkmesa
 
18.09.17
13:28
(0) Регламенты SQL все настроены, обновление статистики, реорганизация и перестроение индексов? Единственно, смущает что  "1.2.14", там многое чего было переписано. Копать с данному случае нужно именно в списание партий, в УПП есть всем известное место (http://catalog.mista.ru/public/191732/). Если активно используются отчеты по данному регистру, то это также может вызвать замедление. Можно рассмотреть вариант вынесения аналитической базы для отчетов отдельно тем или иным способом.
27 SherifSP
 
18.09.17
13:29
(25) В текущем, итоги рассчитаны по конец прошлого месяца
28 Heckfy
 
18.09.17
13:33
(27) Запись в регистры через НаборЗаписей() делается?
29 SherifSP
 
18.09.17
14:23
(28) Да
30 Heckfy
 
18.09.17
14:27
Замени на МенеджерЗаписи()
31 Вафель
 
18.09.17
14:32
И что есть прирост? можно тесты увидеть?
32 Heckfy
 
18.09.17
14:34
Я думаю, ТС с нами результатами поделится. :)
33 SherifSP
 
18.09.17
14:35
(31) Позже скрины выложу
34 _Дайвер_
 
18.09.17
14:47
(10) Серийный убийца программист писал его? xD
35 Джинн
 
18.09.17
14:51
(34) Не. Писалось в те времена, когда и возможности движка скромнее были, и скилы по его применению даже у нуралиевских товарищей попроще были. А потом не стали оптимизировать и оставили как исторически сложилось.
36 dezss
 
18.09.17
15:07
(12) раз все настолько серьезно, рассмотрите вариант 10Гб сетки между серваками.
37 lodger
 
18.09.17
15:24
(12) во имя работы с такими объемами обычно ставят зеркало силами SQL на еще один сервер. тогда каждая запись\отменазаписи кроме своей базы улетает в актуальное зеркало.
время восстановления работы от падения главного сервера до входа юзеров равно времени необходимому админу для переключения 1сины с одного скуля на другой (переписать пути) и в скуле отменить регистрацию из ведущей базы.
38 dezss
 
18.09.17
15:25
(37) и тут внезапно падает второй сервер.
не-не-не, бэкап лучше иметь даже в случае зеркалирования
39 lodger
 
18.09.17
15:33
(38) с чего бы упасть второму серверу? для надежности и исключения влияния причин падения первого на второго можно вынести его в соседнюю серверную\цод\континент\планету.
40 Злопчинский
 
18.09.17
15:37
(39) ну как же
Первый на первой виртуалке
Второй на второй виртуалке
И тут омон железный сервак забрал
41 dezss
 
18.09.17
15:38
(39) если они закупались одновременно, то шанс, что одновременно упадет дисковая подсистема есть. Зеркалирование хорошо именно для скорости восстановления. Но вцелом дорогое оно. По сути, держать еще один такой же сервер, который будет использоваться только как зеркало, не обоснованная трата.
10Гб сетку проще сделать, тем более, что в ней будет сразу несколько серверов+хранилище, например
42 Сияющий Асинхраль
 
18.09.17
15:46
Если нужно существенное увеличение скорости имеет смысл отказаться от партионного учета и перейти на РАУЗ...
43 RS2017
 
18.09.17
15:53
(42) а он был в 1.2?
44 John83
 
18.09.17
16:04
(35) разве в относительно последних релизах не исправили?
что-то мне помнится, что там в запросе надо было исправить на Склад В (&Склад) или как-то так
вроде когда-то смотрел в не совсем свежей УТ 10.3 - там такого не было
45 Heckfy
 
20.09.17
11:46
(33) Хотелось бы все таки увидеть скрины! :) :) :)
46 Михаил Козлов
 
20.09.17
12:01
Не знаю, есть ли в УПП: не пробовали не списывать партии при проведении (оперативно), а делать это регламентным заданием?
47 Heckfy
 
22.09.17
10:38
(33) Таки все еще хочется увидеть скрины!!!
48 Palant
 
22.09.17
11:23
Знакомая проблема. У меня проводилось больше минуты, правда это было в 2008 году.

Анализ показал, что 99% времени пожиралось на расчет себестоимости по партиям.

Пришлось отключать при обычном проведении документов расчет себестоимости, оставить только количественные остатки. Но уже ночью с помощью специального алгоритма дописывать/исправлять в данные документы движения по расчету себестоимости. Именно дописывать/исправлять, т.к. обычное перепроведение документов за расчетный период занимало больше одной ночи.
49 Вафель
 
22.09.17
11:26
(47) Скрины чего ты хочешь увидеть? У набор записей и у менеджера внутре одинаковая неонка (по заявлениям 1с)
50 Heckfy
 
22.09.17
11:31
(49) Монитора производительности. :)
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа. Фредерик Брукс-младший