Как увеличить скорость проведения документов? #805021

Здравствуйте мистяне, интересует вопрос оптимизации записи данных в регистры. База УПП 1.2.14, платформа 8.2, 40 пользователей, в регистре "ПартииТоваровНаСкладахУпр" порядка 30 миллионов записей, "ПартииТоваровНаСкладахБух" - 20 миллионов записей, "ПартииТоваровНаСкладахНал" - 17 миллионов записей, документ "РеализацияТоваровУслуг" с 40 позициями проводится 17 секунд, из них 12 секунд занимает запись данных в эти регистры, как можно увеличить скорость записи в регистры?

+ База SQL 2008R2

+ Свертку базы не рассматриваю

Если Вы уверены, то учет ведется корректно и регистры закрываются корректно по набору измерений, то никак. В таком случае есть только два варианта: 1. свёртка базы, следствием которой станет сокращение таблиц. 2. апгрейд железа для повышения общей производительности. Тут нужен анализ узких мест для принятия более конкретных оптимальных решений.

Железо поменяй. Диски SSD поставь, например вот такие "HP ProLiant 400GB SAS 12G MU SFF SC DS SSD (872374-B21)". У нас работают уже 4 года, ни одного сбоя и скорость хорошая.

Лог и данные разнеси по разным дискам. Базу tempdb тоже на отдельный диск.

Говорят SSD диски не долговечны?

А Отложенное проведение документов рассматриваете?

бекапирование помогает

Вот это попробую, спасибо

Там запрос кривой в УТ10/УПП

Регистры закрываются? Бардака нет в партиях?

База 870 гб, фул бекап 50 минут и бекап 90 гб по сети проблематично перекачивать

Еще можно сам файл базы данных на разные диски разнести, sql2008 вроде позволяет.

Бардак есть, но не серьезный

Недолговечны бытовые, за 3000 рублей 120 гигабайт. Ты цену этого сначала посмотри:) Говорю же, 4 года уже работают. Ни одного перемещенного сектора. Конфа на основе БП 3.0, типовые документы не используем. Размер _AccRgAT3675 = 110 млн записей, _AccRgED677 = 191 млн. Документы проводятся параллельно в фоновых процессах, никаких таймаутов не набюдаем.

Профилируй запись. Может там с индексами проблемы, может перестроить нужно.

То есть бэкапы вы совсем не делаете, я правильно понял?

Небытовые от бытовых отличаются только объемом заразервированного пространства

Косяк со списанными товарами обычно закрывают прямо в момент внедрения.

А такое время проведения просто при работе пользователей же?

А может это блокирвоки просто? Очень похоже

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

Делаем, но не перемещаем по сети

Блокировок нет

Документ проводится в текущем периоде? по какой период рассчитаны итоги в регистрах?

Регламенты SQL все настроены, обновление статистики, реорганизация и перестроение индексов? Единственно, смущает что  "1.2.14", там многое чего было переписано. Копать с данному случае нужно именно в списание партий, в УПП есть всем известное место . Если активно используются отчеты по данному регистру, то это также может вызвать замедление. Можно рассмотреть вариант вынесения аналитической базы для отчетов отдельно тем или иным способом.

В текущем, итоги рассчитаны по конец прошлого месяца

Запись в регистры через НаборЗаписей делается?

Да

Замени на МенеджерЗаписи

И что есть прирост? можно тесты увидеть?

Я думаю, ТС с нами результатами поделится. :)

Позже скрины выложу

Серийный убийца программист писал его? xD

Не. Писалось в те времена, когда и возможности движка скромнее были, и скилы по его применению даже у нуралиевских товарищей попроще были. А потом не стали оптимизировать и оставили как исторически сложилось.

раз все настолько серьезно, рассмотрите вариант 10Гб сетки между серваками.

во имя работы с такими объемами обычно ставят зеркало силами SQL на еще один сервер. тогда каждая записьотменазаписи кроме своей базы улетает в актуальное зеркало. время восстановления работы от падения главного сервера до входа юзеров равно времени необходимому админу для переключения 1сины с одного скуля на другой (переписать пути) и в скуле отменить регистрацию из ведущей базы.

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

с чего бы упасть второму серверу? для надежности и исключения влияния причин падения первого на второго можно вынести его в соседнюю сервернуюцодконтинентпланету.

ну как же Первый на первой виртуалкеВторой на второй виртуалкеИ тут омон железный сервак забрал

если они закупались одновременно, то шанс, что одновременно упадет дисковая подсистема есть. Зеркалирование хорошо именно для скорости восстановления. Но вцелом дорогое оно. По сути, держать еще один такой же сервер, который будет использоваться только как зеркало, не обоснованная трата. 10Гб сетку проще сделать, тем более, что в ней будет сразу несколько серверов+хранилище, например

Если нужно существенное увеличение скорости имеет смысл отказаться от партионного учета и перейти на РАУЗ...

а он был в 1.2?

разве в относительно последних релизах не исправили? что-то мне помнится, что там в запросе надо было исправить на Склад В (&Склад) или как-то так вроде когда-то смотрел в не совсем свежей УТ 10.3 - там такого не было

Хотелось бы все таки увидеть скрины! :) :) :)

Не знаю, есть ли в УПП: не пробовали не списывать партии при проведении (оперативно), а делать это регламентным заданием?

Таки все еще хочется увидеть скрины!!!

Знакомая проблема. У меня проводилось больше минуты, правда это было в 2008 году. Анализ показал, что 99% времени пожиралось на расчет себестоимости по партиям. Пришлось отключать при обычном проведении документов расчет себестоимости, оставить только количественные остатки. Но уже ночью с помощью специального алгоритма дописывать/исправлять в данные документы движения по расчету себестоимости. Именно дописывать/исправлять, т.к. обычное перепроведение документов за расчетный период занимало больше одной ночи.

Скрины чего ты хочешь увидеть? У набор записей и у менеджера внутре одинаковая неонка (по заявлениям 1с)

Монитора производительности. :)