Ускорение 1С 7.7 в 10 раз и более(на SQL) - Созданием Нестандартных ИНДЕКСОВ +Кэш SQL
База данных - HighLoad оптимизация
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Мной были расмотрены варианты следуюшие варианты решение проблемы Индексов:
1) Перехват и парсилка От 1С до ODBC - драйвера - тормозно и сложно "-"
2)Изменение хранимых процедур - уже получше но сложно "-"
3) и Наконец - СОЗДАНИЕ НЕСТАНДАРТНЫХ ИНДЕКСОВ - результат приятно удивил 
Сразу уточняю размер БД взятой для теста 1С - на SQL около 25 ГБ, конфигурация Комплексная (дописанная до Производства), таблицы с Десятками милионов записей не редкость)), MS SQL 2008, ОЗУ сервера =40 ГБ.
Все документы проводились ЗАДНИМ ЧИСЛОМ ( т.е. не на ТА):
3.1)SQL БД- стандартная
а)(БЕЗ КЭШИРОВАНИЯ) Среднее время проведения 1 документа(19 строк) 30 сек
3.2)DBF БД- стандартная
Среднее время проведения 1 документа(19 строк) 15 сек - приведено просто до кучи))) DBF без СУБД прошу не обсуждать в КОММЕНТАРИЯХ СТАТЬИ, буду игнорировать!
3.3)SQL БД + добавление простых Индексов по КАЖДОМУ полю (таблицы три- четыре менял: Журнал доков, Регистр ОстаткиТМЦ...)
Вступайте в нашу телеграмм-группу Инфостарт
См. также
HighLoad оптимизация Системный администратор 1С:Предприятие 7.7 1C77 Бесплатно (free)
Вариант для SQL 77
18.10.2022 5119 Dionisiy 7
HighLoad оптимизация Разработчик 1С:Предприятие 7.7 1C77 Абонемент ($m)
Конфигурация на 1С 7.7, показывающая блокировки на MS SQL сервере и доменных пользователей по SPID. Используется 1С++ и классы.
1 стартмани
09.11.2021 6815 10 ShoDm 17
HighLoad оптимизация Инструменты администратора БД Системный администратор Разработчик 1С:Предприятие 7.7 1С:Предприятие 8 1C:Бухгалтерия 1C77 Бесплатно (free)
Еще один подход к увеличению производительности 1C+SQL = использование RAM-дисков
16.02.2015 48412 kos 36
HighLoad оптимизация Системный администратор 1С:Предприятие 7.7 Оперативный учет 7.7 Бухгалтерский учет 7.7 Расчет 7.7 1C77 Абонемент ($m)
1С сама проверит своё железо и скажет, чего ей не хватает!
1 стартмани
12.01.2014 25067 80 by_1Cnik 7
HighLoad оптимизация Системный администратор Разработчик 1С:Предприятие 7.7 1C77 Бесплатно (free)
Недорогое повышение скорости работы 1С
31.05.2013 15209 ins-post 22
Чистка данных HighLoad оптимизация Системный администратор Разработчик 1С:Предприятие 7.7 1C77 Абонемент ($m)
По статье "Зачем в 1С нужно периодически пересчитывать итоги по регистрам?" http://infostart.ru/public/177171/ Обработка для 7.7, чтобы посмотреть что же творится в БД для SQL
1 стартмани
13.03.2013 25437 54 maxpiter 15
Инструменты администратора БД HighLoad оптимизация Системный администратор Разработчик 1С:Предприятие 7.7 1C77 Бесплатно (free)
Автоматическая переиндексация базы
11.09.2012 19613 Gazulo 3
HighLoad оптимизация Системный администратор Разработчик Оперативный учет 7.7 Бухгалтерский учет 7.7 Расчет 7.7 1C77 Россия Бесплатно (free)
Обратились ко мне с вопросом по теме форума: http://forum.mista.ru/topic.php?id=558772 Автор темы: "DennizzM". Название: "v7: 1c v7.7 ошибки транзакции - как отловить виновника?" Текст с сокращениями: "Вопрос наверняка не новый... Итак - есть база 1c v7.7 (самописная конфа). Периодически у пользователей возникает ошибка при проведении транзакции. База работает под терминалом. Нагрузка на дисковую подсистему небольшая, CPU на нуле, RAM до черта свободного. Вопрос вот в чем - как отловить инициатора первой транзакции которая всех держит? Итак - как мне выкрутиться? ;) ...я не имею права и не могу лезть внутрь конфы и модифицировать ее.".
13.07.2011 28874 hogik 16
Доп.Индексы - да ускоряют получение данных,
но эффект явно виден при закэшированной(в ОЗУ SQL-сервера) базе данных!
******************************************************
******* Принудительное КЭШИРОВАНИЕ на SQL СЕРВЕРЕ******
(эффективно если на SQL сервере ОЗУ больше чем размер Базы)
методики см. в описании ниже по тексту))
Идея взята путем переработки информации из следующих источников:
*********************
Автор плагина для обмана 1с 7.7 насчет доп.Индексов
***********************
Запрос №1 (что то похожее порой шлет сама 1С)
Select top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, ROW_ID
Время выполнения: 10203 мс
-----------------------------------------------------------------------------
Запрос №2 - видоизмененный запрос 1 без указания индекса
Select top 50 * from SC46 order by SP4135, ROW_ID
Время выполнения: 4105 мс
-------------------------------------------------------------------------------------
Запрос №3 - Добавим Все Поля входящие в Индекс
Select top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, Descr, ROW_ID
Время выполнения:156 мс
********************
А чтобы ОдынЦэ не убивало ЛЕВЫЕ)) индексы берем разработку -скрипт-плагин для OpenConf -файл приложен + Обработка загрузки БД в память SQL))
.....BIN\config\scripts\ExtDD.vbs
и
....Каталог_Инф_Базы\1cv7.ddx (Эти индексы в БД SQL создаст Конфигуратор при РЕСТРУКТОРИЗАЦИИ БД)
пример куска содержания моего DDX
X=RA405 %#Доп. индекс Регистр (Дв.) ОстаткиТМЦ
X=RA405 %I=MY_IDDOC | |0 |IDDOC |0
Но вся проблема в том что НАПРИМЕР "расчет итогов регистров" при проведении не на ТА занимает от 60 до 85 % времени проведения.
3.1)SQL БД- стандартная Среднее время проведения 1 документа(19 строк) 30 сек
3.2)DBF БД- стандартная Среднее время проведения 1 документа(19 строк) 15 сек
3.3)SQL БД + добавление простых Индексов по КАЖДОМУ полю (таблицы три- четыре менял: Журнал доков, Регистр ОстаткиТМЦ...) - Среднее время проведения 1 документа(19 строк) 3 сек
С учетом (6) правильно ли я понял, что у вас в дбф расчет занимает 14,5 сек и сама запись 0,5 сек?
Правильно ли я понимаю что в SQL у вас расчет занимал 29 сек, а запись 1 сек
Т.е. у вас скуль получал итоги в 2 раза медленее чем дбф??? Простите вы скуль на первом пне с 64 метрами поставили?
Ведь как вы сказали добавления индексов не ускоряет запись (что логично), т.е. в можно предположить, что в п. 3.3 в 3 сек грубо говоря расчет - 2 сек + 1 сек запись
Я пока что всё верно рассуждаю?
Т.е. у вас скуль получал итоги в 2 раза медленее чем дбф??? Простите вы скуль на первом пне с 64 метрами поставили?
1) SQL стоит на серверной платформе 4-ех ядерный Проц., RAID 10, 40 Гб ОЗУ.
2) Оболочки 1с 7.7 запускаем тоже на серверной платформе на Терминальном сервере 4-ех ядерный проц, RAID 10, 10 ГБ ОЗУ.
С учетом (6) правильно ли я понял, что у вас в дбф расчет занимает 14,5 сек и сама запись 0,5 сек?
не совсем верно, Расчет регистров занимает от 60-85%, но есть же еще партионные алгоритмы и т.д.
А насчет использования DBF без СУБД хочу закончить наш спор, моему подразделению(Производство -одно из ...в крупной торговой фирме)) ) не подойдет:
1)Объемы БД не те (SQL бд уже 25 ГБ) (притом восстановление последовательности доков в отдельной БД - потом Синхронизируем УРБД)
2)Объемы документооборота все время растут
3)работа в программе КРУГЛОСУТОЧНАЯ - следовательно никакие многочасовые ПЕРЕ-ИНДЕКСАЦИИ неприемлемы.
4)Урезки/Порезки тоже не пойдут.. отчетность будет проблемна... налоговая... собственник фирмы и т.д.
Не хочу никого обидеть, но 1c 7.7 +DBF без СУБД -- ИМХО для "ларьков"! ))
было 30 сек * 85% = 25 сек расчет регистров
Значит на оставшиеся проверки и записи остается 5 сек
Индексы не дадут ускорения оставшейся части (проверки и записи). Значит после "правильных" индексов время проведения должно быть
новое время расчета + более 5 сек = время как минимум больше 5 сек. А по вашим расходам - 3 сек. Я вот понять не могу где и у кого ошибки расчета?
P.S. На разных база что ли тестировали, или откуда данные про проведения в дбф, если у вас база большая?
Индексы не дадут ускорения оставшейся части (проверки
утверждение НЕВЕРНО! Ускорение доступа по таблицам SQL для 1с: Регистров, Документов и справочников -- также ускорит работу(поиск и получение данных) с ОБЪЕКТАМИ 1С в самих программных модулях языка 1С.
P.S. На разных база что ли тестировали, или откуда данные про проведения в дбф, если у вас база большая?
Да есть другая БД DBF, база отличается от SQL, но только объемом данных - а не Конфигурацией.
т.е. в DBF даже меньше данных значительно!
Проведение документа вряд ли сильно ускорит. Например, регистр остатков в ТиС. Измерения Фирма/Склад/Номенклатура. По ним троим есть комплексный индекс. Все трое известны при проведении документа. Индекс достаточно оптимален. Вот для отчетов добавление своих индексов может кардинально ускорить быстродействие.
а Связь Регистра с Таблицей ЖурналаДокументов и Справочников - вы уверены что все индексы будут использоваться ОПТИМАЛЬНО? ))
Тесты более подробные - наверное закину после выходных, как буду на работе.
Я не вижу связи между Вашей публикацией и моими разработками.
А посмотреть результаты (замеры) тестов будет интересно.
Думаю, имеет смысл их обнародовать в "моих" темах форума.
Но, только с учетом моего замечания из #2 сообщения данной темы.
А разве простые индексы по одному полю не добавляются установкой галочек "Отбор движений" и "Отбор итогов" ?
моя статья приводит только пример - Тест Технологии)), я согласен что простые индексы - не всегда оптимальны. Просто тестировал данную технологию.
А вот как раз по примеру из начала статьи.
Запрос №1
Select top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, ROW_ID
Можно для Этого случая составить Индекс из Двух полей SP4135, ROW_ID пусть Будет "SP4135_ROW_ID" , ТОГДА SQL при составлении плана запроса
сделает примерно так Select top 50 * from SC46(NOLOCK INDEX=SP4135_ROW_ID) order by SP4135, ROW_ID,
тогда выйдем примерно на те же "Время выполнения:156 мс " и возможно даже быстрей ибо всего Два поля в индексе а не три)) размер то меньше однако!
Народ прошу помощи как АВТОМАТИЗИРОВАТЬ создание Оптимальных Индексов, догадываюсь что сбором ТРАСС в SQL Server Profiler и потом прогонять в Database Engine Tuning Advisor, т.е. на выходе получить готовый скрипт с созданием индексов!
MS SQL 2008
я кажется понял почему помогло даже тупое) добавление Простых Индексов по каждому полю больших таблиц!!
Среднее время проведения 1 документа(19 строк) 15 сек - приведено просто до кучи))) DBF без СУБД прошу не обсуждать в КОММЕНТАРИЯХ СТАТЬИ, буду игнорировать!
Это полный ПЭ..
Что такое ДБФ без СУЮД ? Это как ?
Если что, база 18 гигов в ДБФ, среднее время проведения 1 документа <1 секунда на ТА и чуть больше в заднем числе.
Попробуй "обгони" на скуле..
:)
Комплексная, 2 плана счетов, добавлены ресурсы для упр учета во все регистры.
База крутится 24 часа в сутки, рег. работы в воскресенье.
Перепровод - сутки - 1 год.
Что я делаю не так ?
ЗагрузитьВнешнююКомпоненту("rainbow.dll");
КонецПроцедуры
Процедура Сформировать()
ЗапросРадуги=СоздатьОбъект("ODBCQuery");
СЗ=СоздатьОбъект("СписокЗначений");
ТекстЗапроса="Select RTRIM(CONVERT(char(30),TABLE_NAME)) from INFORMATION_SCHEMA.TABLES
|WHERE TABLE_TYPE='BASE TABLE' AND TABLE_NAME<>'dtproperties'";
Если ЗапросРадуги.Prepare(ТекстЗапроса,0,0)=1 Тогда
Если ЗапросРадуги.Open()=1 Тогда
ЗапросРадуги.GotoNext();
Пока ЗапросРадуги.IsOK()=1 Цикл
СЗ.ДобавитьЗначение(ЗапросРадуги.GetString(0));
ЗапросРадуги.GotoNext();
КонецЦикла;
ЗапросРадуги.Close();
Иначе
Предупреждение("Ошибка открытия запроса!",10);
Возврат;
КонецЕсли;
ЗапросРадуги.Reset();
Иначе
Предупреждение("Ошибка выполнения запроса!",10);
Возврат;
КонецЕсли;
Для к=1 по СЗ.РазмерСписка() Цикл
Если ЗапросРадуги.Prepare("SELECT COUNT(*) FROM "+СЗ.ПолучитьЗначение(к),0,0)=1 Тогда
Если ЗапросРадуги.Open()=1 Тогда
ЗапросРадуги.Close();
КонецЕсли;
ЗапросРадуги.Reset();
КонецЕсли;
КонецЦикла;
ЗапросРадуги="";
Предупреждение("Память для базы данных выделена!",10);
Сообщить("Память для базы данных выделена!");
КонецПроцедуры
//________________________________________________________
Да. Есть такой способ.
Это работает во всех задачах ввода/вывода.
Сделайте, пару раз, копию файла на локальном диске.
Копирование второй раз будет в 10 раз быстрее... ;-)
Вроде, я об этом и написал в сообщениях #2 и #42 данной темы.
И ЧТО мы обсуждаем? :-( :-( :-( ...
- до Документ.ЗаказНаряд.Модуль Документа 1456 ПроведениеПоРегистрам(); 77 705.314887 99.02
- после Документ.ЗаказНаряд.Модуль Документа 1456 ПроведениеПоРегистрам(); 77 725.706179 99.15.
Т.е. ускорения не произошло. Объем базы 10,6Гб, ОЗУ 16Гб, MS Sql Server 2000 SP4, Windows Server 2003.
Мне не понятно, процедура "Сформировать()" должна запускаться каждым пользователем или достаточно чтобы только первым? Может я что-то не правильно делаю?
не получите от этого никакого выигрыша.минимум не станет хуже.
sql сервер гораздо лучше знает
что ему надо а что не надо кешировать.
простой пример предположим у Вас есть очень большой документ Счет ( по размеру sql таблицы)
и Вам надо провести 10 000 расходных накладных. Загнав все счета в кеш Вы съедите
у sql сервера память(буферную) ( со временем конечно все сбалансируется но на время балансировки
памяти будет меньше у sql сервера да и на то чтобы снова все сбалансировать (выпихивать счета)
тоже понадобиться ресурсы sql)
у тебя есть SQL сервак?
загони туда свою базу.... желательно очень большого объема.
а на самых больших табличках навешай индексов по каждому полю, а еще на _1SJOURN - это в обяз))
****************************************************
например моя Тестовая SQL БД(рабочая еще больше)
ТАБЛИЦА /Колич записей.
_1SACCSEL /29 792 921 -Отбор Счетов
..........
.......
_1SSBSEL /10 332 026
_1SENTRY /8 812 137
RA328 /5 623 467 - регистр
RA4674 /5 563 064 - регистр
RA405 /5 506 885 - регистр
....................
...................
PS: т.е. в таблицах МИЛЛИОНЫ и ДЕСЯТКИ миллионов записей!
Я просто хочу понять, как у тебя без прямой записи в скуль время проведения в 5 раз меньше, чем в дбф
... ... (sanfoto)
При создании индекса просматриваются все записи таблицы.
И "умные" СУБД оставляют данные в оперативной памяти.
А "глупые" СУБД - не оставляют, но это за них делает операционная система.
После этого система по чтению работает быстрее, чем до создания индекса.
Но после перезагрузки сервера (железа) скорость чтения возвращается к первоначальному состоянию. А запись начинает работать, естественно, медленнее из-за лишних индексов.
Присоединяюсь к сообщению #41:
"Ждем нормальное тестирование на сопоставимых данных"(с)
первоначальный замер проводился после Группового проведения документов...нужно было для сбора трасс в ПРОФАЙЛЕРЕ
сегодня перезагружали сервера
сделал новый замер время проведения в SQL БД(тестовой) 27 секунд..
скорей всего тему закрою((
hogik,
Alav,
Ёпрст,
vcv,
спасибо за участие в обсуждении... ибо в споре рождается истина))
Я не призываю использовать альтернативные "движки" в части повышения скорости.
Думаю, прежде всего надо пересматривать концепцию самой 1С.
Т.к., по моему опыту, без такого пересмотра - смена "движка" не очень помогает.
Признаюсь, я уже "не понимаю" таких слов как: "без установки ТА/с установкой ТА".
У нас нет никаких ТА уже больше десяти лет... ;-)
И ЧТО мы обсуждаем? :-( :-( :-( ...
да уже наверное нечего обсуждать)) тема была создана для выяснения так сказать ИСТИНЫ))
а еще думаю кому то поможет.
- абсурдные выводы;
выводы ... хм, по 1с 7.7 +SQL
1)правильные доп.индексы - да ускоряют получение данных.
+
2)принудительное Кэширование данных в SQL - да ускоряет(завтра буду автоматизировать сей процесс :D ).
*********** работает есно эффективно если у SQL сервера МНОГО оперативной памяти.... больше БАЗЫ ДАННЫХ хотябы на 2 ГБ.
---сделав пункты 1) и 2) я опять вышел на те же 3 сек. проведения дока(19 строк) )))
---если исключить пункт 1) и выполнить только п. 2), то
а) до кэширования -проведение 30 сек.
б) после кэширования около 9 сек.
строки из dds
#Доп. индекс Регистр (Дв.) ОстаткиТМЦ
I=FASTACT | |0 |DATE_TIME_IDDOC,SP4062,SP408,SP418 |0
вот на вторую строку ругается :( Что не так? Подскажите!
Оказалось, что ошибка возникает, если доп. индекс расположен в файле DDS до основных индексов и, соответственно, создается до того, как создан основной индекс. Если расположить в файле DDS доп. индексы после основных, то все работает.
Поэтому пришлось немного переделать скрипт, чтобы строки с доп. индексами добавлялись после основных, если они есть.
Похоже, нашёл вариант решения - в скрипте ExtDD.vbs заменил "F" на "I" (i) в Sub ProcessDD() - второй Do ... While цикл.
Было:
...
Case "F="
Mode = "F"
Case Else
If Mode = "F" Then
...
Стало:
...
Case "I="
Mode = "I"
Case Else
If Mode = "I" Then
...
Таким образом индексы добавляются к таблице не после описания полей, а после описания её индексов.
Единственное - если, вдруг, будет таблица без родных индексов - то и дополнительные теперь не добавятся, как я понимаю...
P.S.
Да - ExtDD.vbs работает и с 1cpp. Т.е. rainbow.dll не понадобилась.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 84501
Создание 22.04.11 18:11
Обновление 27.04.11 13:48
Просмотры 40191
Загрузки 147
Рейтинг
26
Комментарии 67
Код открыт Не указано
Рубрики HighLoad оптимизация
Кому
Системный администратор
,
Разработчик
Тип файла Архив с данными
Платформа 1С:Предприятие 7.7
Конфигурация 1C77
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
