Долгая реструктуризация, замеры времени и очистка Ветис. Розница 2.3

16.04.24

База данных - HighLoad оптимизация

При подготовке к обновлению возникли проблемы на стадии тестирования и исправления базы данных, также при создании файлов РИБ для магазинов.

1С:Предприятие 8.3 (8.3.21.1895)

Розница, редакция 2.3 (2.3.9.42)

Режим: Серверный (сжатие: усиленное)

РИБ 6 магазинов

MS SQL 2019

 

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

История как в сказке про репку. Появилась проблема, которая потянула за собой решение обновиться. Обновили центральную базу до последнего релиза, поставили делать первый РИБ, с 12 ночи до 9 утра не сдвинулось с 0% (железо не топ, но I7, 64гб оперативы, ssd самсунг 970), около 6кк объектов к выгрузке. Пришлось откатываться назад и разбираться. База велась с 2016, соответственно накопилось всякого. 

Далее сделал копию базы и проводил все манипуляции с ней, после в основной базе.

1. Выпилил неудачный опыт интеграции Ветис Меркурий в 1С. За несколько месяцев работы (пока не перестал этим пользоваться) в базу залетело более 5гигов файлов по ВСД(!) и несколько сотен тысяч записей по разным регистрам.

Файлы увидел через Администрирование-Обслуживание-отчеты администратора-объем ненужных. Выгрузил их в папку на диск (администрирование-работа с файлами) и снес. Регистры вычищал обработкой СДР: Редактор объекта ИБ (1.1.0.71 от 07.05.2023). Далее шлифанул тестированием и исправлением без реструктуризации.

2. Сделал свертку базы на 1 год, поудалял все помеченное, сделал ТиИ с реструктуризацией, которое неожиданно заняло 1.5 дня

3. Сделал свертку еще на 2 года, реструктуризация быстрее не стала. Проблема была на моменте реструктуризации РегистрНакопления. ТоварыНаСкладах. Таблица регистрации изменений (около 35кк записей). 99.9% времени занимала обработка этого регистра.

Обработкой СДР: Консоль запросов (1.1.0.45 от 07.02.2020) выяснил, что... одно из подключаемых оборудований, а именно весы с печатью этикетов Штрих-М, воспринималось системой как узел обмена (открыть "регистрация изменений для обмена данными") и на них все это время пытался выгружаться регистр накопления - товары на складах!!! При этом было 29 узлов обмена этих весов (не смогу складно объяснить, но этих весов в подключаемом оборудовании висело несколько неиспользуемых, плюс узлы обмена по всем этим настройкам каким-то образом были продублированы пятикратно) и почти на каждом висело по 1.6кк регистраций к выгрузке. Собственно эти абсолютно ненужные записи комп сутки и переваривал на реструктуризации. Сняв регистрацию объектов с них и удалив лишние узлы обмена, все тестирование и исправление базы заняло меньше часа. Задача весов получать PLU и цены. Зачем так сделано, для меня загадка. 

4. Ну и когда процесс ТиИ пошел быстро, не смог не обратить внимание на притормаживание на регистре Замеры времени. Тоже подлянка оказалась, но простая. Материал по ней здесь же и читал. Если коротко, то в центре мониторинга запрещаем отправку сообщений и в оценке производительности отключаем ее ведение. Чем раньше это сделаете, тем больше времени себе сэкономите в будущем, вычищая миллионы бесполезных записей о том, за сколько миллисекунд делался чек в 2017 году. Регистров по замерам несколько. В регламентных заданиях есть очистка только одного, нужно только время изменить, у меня стоял час с 4 до 5 утра)) Остальное обработкой удалял. 

5. Итого: ТиИ с полутора суток сократилось до часа. Создание файла риба с 6кк объектами (неопределенного конечного времени создания) сократилось до 2кк за 2часа с минутами. 

Если вдруг кто-то, разбирающийся в теме, прочитает и не сильно будет хейтить за эту историю (я понимаю, что на взгляд профи простые пользователи как дауны выглядят, когда рот открывают), то просьба ответить, почему, удалив столько мусора, база в sql как была 68гб, так и осталась?

реструктуризация риб замеры времени

См. также

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024    5331    ivanov660    12    

56

Администрирование СУБД Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

При хранении файлов в томах на диске они иногда исчезают. Разбираемся, почему.

23.05.2024    10204    human_new    18    

56

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024    12622    251    ZAOSTG    83    

115

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    14644    doom2good    49    

71

HighLoad оптимизация Системный администратор Программист Бесплатно (free)

При переводе типовой конфигурации 1C ERP/УТ/КА на PostgreSQL придется вложить ресурсы в доработку и оптимизацию запросов. Расскажем, на что обратить внимание при потерях производительности и какие инструменты/подходы помогут расследовать проблемы после перехода.

20.11.2023    13796    ivanov660    7    

83

HighLoad оптимизация Бесплатно (free)

Казалось бы, КОРП-системы должны быть устойчивы, быстры и надёжны. Но, работая в рамках РКЛ, мы видим немного другую картину. Об основных болевых точках КОРП-систем и подходах к их решению пойдет речь в статье.

15.11.2023    7286    a.doroshkevich    22    

75

Администрирование СУБД Системный администратор Бесплатно (free)

Переход с MS SQL на PostgreSQL сопряжен с рисками для бизнеса и неизбежно вызывает множество вопросов. Статья посвящена тому, как заранее подготовиться к предстоящей миграции, провести нагрузочное тестирование, выявить возможные проблемы перехода и провести необходимую оптимизацию.

13.11.2023    18191    ivanov660    32    

77
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. SerVer1C 816 16.04.24 16:58 Сейчас в теме
база в sql как была 68гб, так и осталась?

Сделайте шринк базы
3. xKaskadx 2 17.04.24 02:14 Сейчас в теме
(1) Спасибо, попробую на досуге. Просто, сколько читал материалов на форумах, чаще не помогает этот способ. Но надо пробовать)
2. TMV 14 16.04.24 19:36 Сейчас в теме
Я обычный пользователь
и
Выпилил неудачный опыт интеграции Ветис Меркурий в 1С
...
Сделал свертку базы на 1 год, поудалял все помеченное, сделал ТиИ с реструктуризацией

Как будто не совсем обычный
4. xKaskadx 2 17.04.24 02:35 Сейчас в теме
(2) Разумеется, в каких-то моментах обращаешься за консультацией, когда не можешь разобраться самостоятельно. Как минимум - спросить о правильности понимания проблемы, вариантах её решения и последствиях планируемых действий.
Оставьте свое сообщение