Обслуживание баз данных. Не так просто, как кажется

Публикация № 1134515

Администрирование - Производительность и оптимизация (HighLoad)

База данных обслуживание статистика оптимизации производительность

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

История начинается

Вы обслуживаете базу данных среднего или большого размера? Имею ввиду размер от 100 ГБ и больше. Если да, то, возможно, с проблемами обслуживания индексов и статистик Вы уже сталкивались, а описание кейса в статье будет Вам знакомо. Если же Вы счастливчик и имеете дело со скромными по размеру системами, то информация ниже может пригодиться Вам в будущем.

В любом случае, добро пожаловать! Рассказанный случай может быть полезен для всех.

Подопытная база

Главным героем сегодня будет "Бухгалтерия предприятия 3". Точный релиз не важен, т.к. структура регистра бухгалтерии редко меняется. Да и любая конфигурация, имеющая в своем составе этот тип регистра, потенциально могла бы быть сегодня в центре внимания.

Интересуемые для нас характеристики подопытного:

  • Размер базы 3 ТБ.
  • Работа с регистром бухгалтерии ведется очень интенсивная. В сутки на основной таблице регистра выполняется порядка 800 тысяч операций записи (вставка и обновление данных), а также 12 млн. операций чтения.
  • Регистр большого размера. Взгляните на состав его таблиц и их размеры (данные получены с помощью этого отчета).
 
 Информация о таблицах регистра бухгалтерии

Ранее мы уже рассматривали общую информацию о структуре регистра бухгалтерии. Сегодня эти знания нам пригодятся.

Плюс ко всему, в базе настроено обслуживание индексов и статистики вне рабочего времени, ночью.

 
 Скрипты обслуживания индексов и статистик

Оба скрипта имеют настройки ограничения выполнения по времени, чтобы работа по обслуживанию не перешла на рабочие часы.

 
 Обслуживание индексов
 
 Обслуживание статистики

Обратите внимание на ту часть скрипта, где информация об обслуженных индексах и объектах статистики может быть записана в служебную базу данных, в том числе и с дополнительной информацией о времени обслуживания каждого объекта. Это может быть очень полезно при расследовании что и как обслуживалось, сколько времени на это было затрачено и так далее.

В основном все работает хорошо и на производительность жалоб не поступает. APDEX в зеленой зоне (ох уж этот APDEX). Но иногда возникают странные проблемы с подвисанием и блокировками во время проведения / отмены проведения документов.

Двойная жизнь

Как это часто бывает, информационная система живет сложной жизнью. Днем она записывает / сохраняет документы при работе пользователей, а также формирует множество вариантов отчетов. Ночью же на сцену выходят "монстры", называемые как "регламентные задания" с массовым изменением данных. Думаю, это обычная ситуация для многих.

В периоды отчетности и закрытия ситуация может меняться,  но незначительно. Без каких-либо предпосылок и предупреждений, в любой день, с самого раннего утра начинают поступать жалобы, что документы проводятся очень медленно, а иногда и вовсе появляется ошибка таймаута на ожидании блокировки на уровне СУБД (в заявках, конечно, пользователи не так пишут, обычно просто "Не работает!"). Чем больше активных пользователей в системе, тем больше жалоб и критичность проблемы.

Сначала обычно начинают разбираться так:

  • Есть ли зависшие сеансы 1С или сессии на SQL-сервер. Если есть, то "убивают" их, предварительно сохранив всю доступную информацию о сеансе или сессии.
  • Зависает конкретное действие в базе или нет. Если конкретное, то уже проще - можно попытаться решить, оптимизировать или, как минимум, собрать информацию.
  • Проверяем отработало ли обслуживание индексов и статистик ночью. Возможно, произошла ошибка при работе job'а и теперь придется разбирать последствия весь оставшийся день, возможно даже обслуживать часть таблиц "на горячую" (обожаю так делать!).
  • Проверяем загрузку оборудования с помощью мониторинга (он же у вас есть, не так ли?).  Если проблема там, то решаем вопрос с администраторами что и как делать. Тут может оказаться что был выпущен новый функционал и 1Сники решили "отопить" всю серверную за счет увеличения нагрузки на железо. Можете уточнить у своих коллег делают ли они так :)
  • В отчаянии перезагружаем сервер.

Но в нашем случае ничего из вышеперечисленного не помогло! Жалобы продолжают поступать. Конечно, есть и другие способы диагностики, но не будем удлинять список, пойдем дальше.

Опять эти блокировки!

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

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

UPDATE T2 SET

    -- Итог по ресурсу "Сумма"
    _Fld9622 = T2._Fld9622 + T9._Fld9622,

    -- Итог по ресурсу "ВалютнаяСуммаДт"
    _Fld9623Dt = T2._Fld9623Dt + T9._Fld9623Dt, _Fld9623Ct = T2._Fld9623Ct 
        + T9._Fld9623Ct, _Fld9624Dt = T2._Fld9624Dt + T9._Fld9624Dt, 

    -- Итог по ресурсу "ВалютнаяСуммаКт"
    _Fld9624Ct = T2._Fld9624Ct + T9._Fld9624Ct, _Fld9625Dt = T2._Fld9625Dt 
        + T9._Fld9625Dt, _Fld9625Ct = T2._Fld9625Ct + T9._Fld9625Ct, 

    -- Итог по ресурсу "СуммаПРДт"
    _Fld9626Dt = T2._Fld9626Dt + T9._Fld9626Dt, _Fld9626Ct = T2._Fld9626Ct 
        + T9._Fld9626Ct, _Fld9627Dt = T2._Fld9627Dt + T9._Fld9627Dt, 

    -- Итог по ресурсу "СуммаВРКт"
    _Fld9627Ct = T2._Fld9627Ct + T9._Fld9627Ct

FROM #tt24 T9 WITH(NOLOCK) -- Таблица с заранее подготовленными данными
    -- Таблица "ИтогиМеждуСчетами", именно в ней обновляются итоги данным запросом
    INNER JOIN dbo._AccRgCT1188 T2
    -- Соединения по:
    -- Периоду
    ON T9._Period = T2._Period 
        -- СчетДТ
        AND T9._AccountDtRRef = T2._AccountDtRRef
        -- Счет КТ
        AND T9._AccountCtRRef = T2._AccountCtRRef AND T9._Fld9679RRef = T2._Fld9679RRef 
        -- Валюта ДТ
        AND ((T9._Fld9620DtRRef = T2._Fld9620DtRRef OR T9._Fld9620DtRRef IS NULL AND T2._Fld9620DtRRef IS NULL))
        -- Валюта КТ
        AND ((T9._Fld9620CtRRef = T2._Fld9620CtRRef OR T9._Fld9620CtRRef IS NULL AND T2._Fld9620CtRRef IS NULL)) 
        -- Подразделение ДТ
        AND ((T9._Fld9629DtRRef = T2._Fld9629DtRRef OR T9._Fld9629DtRRef IS NULL AND T2._Fld9629DtRRef IS NULL)) 
        -- Подразделение КТ
        AND ((T9._Fld9629CtRRef = T2._Fld9629CtRRef OR T9._Fld9629CtRRef IS NULL AND T2._Fld9629CtRRef IS NULL)) 
        -- Служебный разделитель
        AND T2._Splitter = @P9

-- Фильтр по разделителю данных
WHERE (T2._Fld9659 = @P2)

При формировании записей движений платформа 1C выполняет множество запросов, ведь регистр бухгалтерии имеет сложную структуру и логику работы. В будущем мы продолжим серию статей об этом регистре и рассмотрим их, но сегодня остановимся только на этом запросе. 

В этом случае выполняется обновление информации в таблице итогов оборотов между счетами. Во временной таблице есть подготовленная информация для расчета новых значений итогов (это те данные, которые сохраняются при записи движений и на которые нужно откорректировать итоги) и платформа соединяет ее с данными непосредственно таблицы итогов.

Вроде все хорошо, что же может пойти не так? Но если мы соберем дополнительную статистику, то увидим, что этот запрос выполняется порядка 30-60 секунд. То есть соединение данных двух таблиц выполняется очень долго, а в плане запроса обычно появляется операция "Table scan". О ужас!

Поскольку для базы используется RCSI, то сканирование таблицы для обновления не блокирует всю таблицу. Лишь те записи, которые подходят под указанную аналитику (счет ДТ и КТ, подразделение ДТ и КТ, валюта ДТ и КТ и период (месяц)). Но так как сканирование выполняется до 60 секунд (а иногда и более), то при интенсивной работе есть вероятность появления таймаутов на таких блокировках, особенно если эта аналитика часто используется. Вот если бы RCSI не был бы включен, то блокировок было бы еще больше!

Но почему, почему запрос получился именно такой? Почему появились операции сканирования таблиц, ведь подходящие индексы для таблицы итогов есть? Вчера же все работало! Ох уж эта платформа 1С, она точно во всем виновата!

Почему так

Но почему? Почему так? Первое, что приходит в голову, так это проверить фрагментацию индексов у таблицы итогов регистра, вдруг обслуживание почему-то не отработало и поэтому SQL Server не использует индексы? СУБД считает их использование нецелесообразным, т.к. фрагментация слишком высокая. А если высокая, то затраты ресурсов при их использовании могут быть выше, чем старое доброе сканирование таблицы? Смотрим.

 
 Что там с индексами?

Что ж, проблем с индексами нет. Давайте тогда посмотрим на состояние статистики.

 
 Статистика актуальная?

Бинго! Статистика стала неактуальной и SQL Server перестал использовать индексы в запросе. В начале статьи Вы могли видеть, что всего в таблице итогов между счетами примерно 415 тысяч записей. То есть, в таблице было потенциально изменено больше 30% всех данных, а статистика до сих пор не обновилась, что и не позволило СУБД использовать индексы должным образом. 

Но почему? Скрипт ведь обслуживания есть, он отработал.

Да, обслуживание прошло ночью без ошибок, но до таблицы итогов между счетами оно просто не добралось! Сравните сами количество записей в других таблицах регистра и этой: 415 тыс. в таблице итогов и 103 млн. записей в основной таблице регистра.  Разница существенная! Ночью были обслужены статистики больших таблиц, в которых изменения происходят чаще всего, а до мелких очередь просто не дошла. А ведь в базе есть не только регистр бухгалтерии, но и другие таблицы и пообъемнее!

В примере выше скрипт обслуживания статистик в первую очередь брал к обслуживанию те объекты, по которым больше всего изменилось записей. Даже если бы приоритет обслуживания определялся не по количеству изменений, а по % измененных строк от общего количества в таблице, то не факт, что очередь бы до нужного нам объекта дошла. По крайней мере на моей практике подход с определением приоритета обслуживания по % измененных записей часто давал сбой и делал не то, что следовало.

Может возникнуть вопрос: "Почему же проблема "плавает" и не возникает каждый день?". Вопрос справедливый и ответ простой: массовые изменения в бухгалтерском регистре происходят не каждый день и зависят от каких-то неизвестных обстоятельств.  Например:

  • Внезапно понадобилось пересчитать итоги.
  • Загрузить очень много документов.
  • Перепровести регламентные операции закрытия.
  • Да что угодно!

Плюс, в некоторых случаях обслуживание все же делает обновление статистики для этой таблицы, если в очереди нет других более тяжелых объектов к обслуживанию.

Как же быть в таких ситуациях?

Как быть

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

 
 Обновляем статистику"на горячую"

Окей, мы стабилизировали ситуацию! Блокировок больше нет, а система летает (и не падает)! Если бы таблица была очень большой, то потребовалось бы больше времени на обновление статистики, во время которого наблюдалось бы снижение производительности. Принимайте взвешенное решение, прежде чем запускать скрипт на продакшене.

Но как предотвратить подобную аварию в будущем?

Работая над обслуживанием базы некоторое время начинаешь собирать информацию об особенностях ее работы. К таким особенностям относится и наш случай. Мы можем создать отдельный план обслуживания для индексов и статистик, актуальное состояние которых критично для функционирования всей системы. Так и поступим в нашем случае: добавим план обслуживания нашей "особенной" таблицы и ее статистик, который будет работать параллельно основному плану обслуживания. Расписание также можно выбрать на свое усмотрение. Конкретно в этом случае был настроен запуск каждые 4 часа, так как таблица небольшая, а изменений по ней много. Основной работе обслуживание никак не мешало и занимало обычно от 5 до 15 секунд на рабочем сервере.

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

Теперь одной проблемой обслуживания базы данных меньше!

Нет базы - нет проблем

Все, что описано выше, необязательно должно случиться с Вами! Это лишь одна из возможных проблем, которая может поджидать при увеличении размера базы данных и ее чувствительности к качественному обслуживанию индексов и статистики.

Всю статью можно пересказать простыми словами: "Правильно обслуживайте индексы и статистику, тогда и проблем не будет". Вот только не всегда однозначно можно сказать, как это сделать, а очевидные ответы бывают ошибочны. Те скрипты, что можно найти на просторах интернета или стандартные компоненты планов обслуживания SQL Server не являются полностью универсальными, как Вы могли убедиться из примера выше.

Следите за своими базами, держите обслуживание эффективным!

Есть свои истории на этот счет? Добро пожаловать в комментарии!

Другие ссылки

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. Region102 14.10.19 12:17 Сейчас в теме
Отличная статья!
dabu-dabu; RickyTickyTok; Summer_13; taiwanchik; geron4; YPermitin; +6 Ответить
2. YPermitin 8572 14.10.19 12:22 Сейчас в теме
(1) спасибо за хороший отзыв! :)
3. geron4 154 14.10.19 15:28 Сейчас в теме
Как-то был у меня на практике случай, 1С ЗУП + MSSQL (версия Standart 2014) перестал использовать индекс, сбор/пересбор статистики не помогали, пришлось новый индекс запилить, оптимизатор его сам подхватил.

Хинты к сожалению в 1С не поставишь, есть вариант перехвата запроса и добавления хинта, точно не помню, но там тоже что не пошло.
Вот в случае, когда в течении дня статистика может стать не актуальной - хинты на индексы бы нормально зашли, только платформа их конечно не поддерживает. :(
Как вариант, можно капнуть, чтобы запретить менять план запроса для некоторых запросов, но это тема для изучения.
YPermitin; acanta; +2 Ответить
4. YPermitin 8572 14.10.19 15:31 Сейчас в теме
(3) интересный случай. Вот бы воспроизвести и изучить.

P.S. Надеюсь в скором времени выпустить небольшую разработку для экспериментов с перехватом запросов от платформы с возможностью их изменения. Можно будет и с хинтами поэкспериментировать. Не для прода, конечно.
klezyk; geron4; +2 Ответить
5. geron4 154 14.10.19 15:38 Сейчас в теме
(4) На счет перехвата запросов - очень интересно, в каких-то версиях MSSQL есть штатные механизмы для отлова и подмены. Вспомнил почему не получилось штатными средствами - там привязка к точному тексту запроса, а если у тебя таблицы соединяются с временными, например #TT800 (или #TT1000), то запрос всегда разный.

На счет номеров временных таблиц это шутка из Терминатора :))), номера всегда разные.
acanta; YPermitin; +2 Ответить
6. YPermitin 8572 14.10.19 15:41 Сейчас в теме
(5) штатный перехват не совсем то, что нужно. Там можно планы запросов свои делать для запроса или триггерами переопределять действия для запроса, но вот прям текст запроса поменять нельзя. В PostgreSQL есть возможность поменять текст запроса через AST-дерево запроса, но задача тоже не тривиальная.

Вообщем, будет публикация :)

P.S. про терминатора Огонь!
7. nicxxx 238 14.10.19 16:14 Сейчас в теме
Включите уже traceflag 2371 и забудьте о ручном обновлении статистики.
Ashandy; YPermitin; +2 Ответить
8. YPermitin 8572 14.10.19 16:19 Сейчас в теме
(7) это применимо, но далеко не всегда. Расскажите свой случай, где Вам настройка помогла, если есть такая возможность.
9. nicxxx 238 14.10.19 18:52 Сейчас в теме
(8)
Расскажите свой случай, где Вам настройка помогло

БП 3.0
Размер регистра бухгалтерии точно не скажу, в сумме наверно 200 ГБ
Прирост в день минимум 1 млн проводок
11. Ashandy 21.10.19 16:27 Сейчас в теме
(7)
traceflag 2371

спасибо, не знал о таком
Кстати, там еще написано:

Примечание. Начиная с версии SQL Server 2016 (13.x) и при уровне совместимости базы данных 130 или более высоком эта реакция управляется подсистемой, и флаг трассировки 2371 не оказывает влияния.
YPermitin; +1 Ответить
12. YPermitin 8572 21.10.19 16:36 Сейчас в теме
(11) (9) все никак не успеваю ответить.

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

Тема обширная. Посмотрите в гугле.
13. nicxxx 238 22.10.19 16:33 Сейчас в теме
(11) Да, все правильно. С этой версии флаг включен по-умолчанию.
10. vihrov_av 16.10.19 08:26 Сейчас в теме
Подобные планы обслуживания нужно периодически актуализировать, так как таблицы в которых вчера статистика обновлялась за 5 секунд, сегодня может обновится целую минуту, а завтра и того больше. Поэтому данная процедура - цепь непрерывных улучшений. Которым нужно удалять время и включать в план работ.
Дмитрий74Чел; YPermitin; +2 Ответить
14. nicxxx 238 22.10.19 16:34 Сейчас в теме
(10)
таблицы в которых вчера статистика обновлялась за 5 секунд
хе-хе. 9 часов :)
YPermitin; +1 Ответить
15. nvv1970 23.10.19 18:34 Сейчас в теме
Объемные таблицы должны быть вынесены в отдельный план обслуживания. При чем при определенных условиях автоапдейт для отдельных таблиц имеет смысл выключать вообще.
YPermitin; +1 Ответить
16. YPermitin 8572 23.10.19 18:42 Сейчас в теме
(15) полностью согласен.
А иногда и не только большие.
17. letarch 29.10.19 15:50 Сейчас в теме
подобные операции по обслуживанию индексов и статистик нужно применять и для postgres баз?
YPermitin; +1 Ответить
18. YPermitin 8572 29.10.19 16:28 Сейчас в теме
(17) у PG тоже есть статистика, но работает несколько иначе.
26. Xershi 983 02.05.20 10:30 Сейчас в теме
(17) нужно, на днях была статья как это сделать.
27. letarch 03.05.20 11:24 Сейчас в теме
28. Xershi 983 03.05.20 12:30 Сейчас в теме
(27) вам повезло на днях админу скидывал, быстро нашел:
Держи данные в тепле, транзакции в холоде, а VACUUM в голоде.
Там также чутка и по мс скуль.

Кстати вопрос к автору. У клиента А есть 2012, у Б 2017 мс скуль.
У А 2 плана ежедневный и недельный. У Б ежедневный.
Каким образом проверяете время выполнения плана обслуживания?

У клиента Б мс скуль дает задать процент в частности указали 15%. И вот для таблицы заказы клиента при объеме в 400к документов нужно изменить 60к, чтобы скрипт отработал?
19. user706076_s.travin 30.12.19 17:06 Сейчас в теме
спасибо за статью! очень выручает периодически.

скрипт по обновлению статистики отрабатывает заменив "where" на "and"
AND [o].[is_ms_shipped] = 0
-- Отбор по имени таблицы итогов, у которой мы расследуем проблему
WHERE AND o.name = '_AccRgCT1188'
20. rozer 268 28.04.20 20:52 Сейчас в теме
А процедурный кеш надо же сбрасывать после обновления статистики вроде бы... а то планировщик будет из старого кеша планы брать....
21. DarkAn 938 30.04.20 11:57 Сейчас в теме
(20) вроде как, уже не актуально.
22. rozer 268 30.04.20 13:17 Сейчас в теме
(21) не актуально с какой версии sql server стало?
23. DarkAn 938 30.04.20 13:22 Сейчас в теме
(22) Точно не отвечу. Андрей Бурмисров в курсе по оптимизации об этом говорил.
Одна из проблема с сбросом процедурного кэша в том, что он сбрасывается для ВСЕХ БД, а не отдельно взятой.
24. rozer 268 30.04.20 14:53 Сейчас в теме
странно во всех мануалах нужно процедурный кеш скидывать после статистики и иначе планировщик, который берет инфу из кеша используя старую статистику вместо например index seek фигачит менее оптимальные способы поиска и соединений в данных .... Ну Бурмистров не Гилев конеч но Бурмистрову виднее ))
25. YPermitin 8572 30.04.20 15:51 Сейчас в теме
(24) с 2014 редакции SQL Server помечает планы после обновления статистики как устаревшие. Это если ооооочень кратко.
Очищать кэш каждый раз не лучшая идея. Видел ужас - днем обновляется статистика и тут же сбрасывается процедурный кэш. Все вроде хорошо, но на самом деле нет :) График компиляции планов запросов зашкаливает некоторое время, даже в замера 1С видны замедления операций.

Отсюда вывод: самый главный мануал - это документация к ПО и .... эксперименты.
Оставьте свое сообщение

См. также

Регламентные операции с индексами в MS SQL Server (Скрипты для SQL-Server - Часть 2) Промо

Производительность и оптимизация (HighLoad) Абонемент ($m)

В данном вебинаре я расскажу о том, что такое индексы, зачем они нужны, какие регламентные операции необходимо выполнять с индексами, а также будут приведены соответствующие скрипты (для MS SQL-Server) для обслуживания индексов баз данных.

1 стартмани

22.03.2018    26738    26    Tavalik    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

В статье обсудим пример практической настройки конфигурации «Мониторинг производительности» для автоматической классификации ошибок по группам/кластерам на данных текстов описания ошибок. Используем механизм векторной модели текстов и косинусное сходство между ними.

25.06.2020    1863    0    ivanov660    12    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

Обычно предметом оптимизации являются заранее определенные ключевые операции, т.е. действия, время выполнения которых значимо для пользователей. Причиной недостаточно быстрого выполнения ключевых операций может быть неоптимальный код, неоптимальные запросы либо же проблемы параллельности. Если выясняется, что основная доля времени выполнения ключевой операции приходится на запросы, то осуществляется оптимизация этих запросов. При высоких нагрузках на сервер СУБД в оптимизации нуждаются и те запросы, которые потребляют наибольшие ресурсы. Такие запросы не обязательно связаны с ключевыми операциями и заранее неизвестны. Но их также легко выявить и определить контекст их выполнения, чтобы оптимизировать стандартными методами.

24.05.2020    6007    0    DataReducer    22    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

18.05.2020    1651    0    Aleksey.Bochkov    3    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    28819    0    MrWonder    42    

Настоящий краудфандинг. Даешь сравнение двух СУБД!

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

Первый вариант сравнения двух СУБД. Каждый может внести правку и получить SM. Приветствуются конструктивные комментарии, начинающиеся словами "Автор ничего не понимает".

11.05.2020    2242    0    Mari_Kuznetzova    25    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    10089    0    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

Производительность и оптимизация (HighLoad) Практика программирования v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    3267    0    feva    14    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    40085    0    Gilev.Vyacheslav    1    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    11177    0    informa1555    21    

Многострочный контекст событий

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

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    2781    0    vasilev2015    9    

Анализ взаимоблокировок

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

Скрипт Bash, который выводит полную информацию взаимоблокировок по технологическому журналу. Не имеет аналогов в отечественных публикациях.

20.03.2020    4081    0    vasilev2015    21    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    66494    0    yuraos    112    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    6138    0    kaliuzhnyi    43    

1С + Apache + SSL: Перевод опубликованной базы на защищенное соединение https с сертификатом от Let's encrypt windows

Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Есть куча инструкции про связку с ISS, решил добавить свои 5 копеек, как я это настраивал на Apache на Windows.

02.03.2020    2923    0    rst_filippov    5    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    53282    0    Антон Ширяев    116    

Ошибка при обновлении: Записи регистра сведений стали неуникальными: Двоичные данные файлов

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

Способ обойти ошибку обновления Записи регистра сведений стали неуникальными: ДвоичныеДанныеФайлов.

26.02.2020    3898    0    dubovenko_m    11    

Контроль места на дисках

Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Один из последних случаев на работе. Диск, на котором хранились файлы базы, "развалился", база потеряна. Начали искать копию базы. Копии базы делались на другой диск, но оказалось, что на том диске нет места и копии не делались несколько дней. Так было потеряно несколько дней работы фирмы, кому-то выговор, кого-то уволили((.

20.02.2020    3044    0    wowik    20    

Нюансы лицензирования 1С

Администрирование СУБД v8 1cv8.cf Россия Бесплатно (free)

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

19.02.2020    8231    0    fixin    112    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    53909    0    Gilev.Vyacheslav    46    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    8108    0    Evil Beaver    13    

Как мы научились автоматически отслеживать ошибки в 1С

Администрирование СУБД v8 1cv8.cf Россия Бесплатно (free)

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

04.02.2020    12409    0    slozhenikin_com    27    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    5885    0    darkdan77    59    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    29657    0    gallam99    19    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    7182    0    Kaval88    26    

Активный 2019 год на Инфостарт

О сообществе О жизни Бесплатно (free)

О прошедшем 2019 годе в 100 и 500 словах.

26.12.2019    5443    0    YPermitin    24    

Автономный сервер. Часть 2 - утилита управления

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

Утилита управления "Автономным сервером" может не только управлять. Какие возможности можно использовать уже сегодня? Разбираем с примерами и ищем отличия от привычных методов.

21.12.2019    8928    0    -vito-    26    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    41856    0    madmpro    32    

Автономный сервер. Часть 1 - новый вариант сервера

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

В Платформе версии 8.3.14 появился новый вариант серверной архитектуры - "Автономный сервер" (бета-версия). Выясняем, что это такое, какова сфера его применения, что он позволяет уже сейчас, чего можно ожидать.

21.12.2019    11193    0    -vito-    19    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    9982    0    ivanov660    16    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    6988    0    EugeneSemyonov    11    

Набор скриптов для знакомства с SQL Server

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

Поговорим о скриптах, которые помогут быстро ознакомиться с состоянием SQL Server, в том числе с вопросами производительности.

30.09.2019    20720    0    YPermitin    14    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    8522    0    Repich    5    

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    17519    0    Sloth    24    

Хранение файлов - как уменьшить размер базы данных

Чистка базы Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 Россия Бесплатно (free)

Хранение файлов в базе 1С можно оптимизировать для уменьшения размера хранимых данных.

09.09.2019    7983    0    2tvad    17    

Регистры бухгалтерии. Общая информация

Практика программирования Математика и алгоритмы v8 v8::БУ БУ Бесплатно (free)

Общая информация о внутреннем устройстве регистров бухгалтерии.

05.09.2019    24540    0    YPermitin    24    

Анализ производительности APDEX

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    9875    2    YPermitin    7    

Просмотр и анализ структуры базы данных (отчет на СКД)

Инструментарий разработчика v8 v8::СКД 1cv8.cf Абонемент ($m)

Отчет для просмотра и анализа структуры базы данных с поддержкой файловых баз (ограниченный режим), а также баз на SQL Server и PostgreSQL.

5 стартмани

24.07.2019    18608    157    YPermitin    27    

Неочевидные проблемы производительности: важность системного подхода при анализе

Производительность и оптимизация (HighLoad) v8 Россия Бесплатно (free)

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    8486    0    Филин    12    

Ловля блокировок на связке "Microsoft SQL server - 1С"

Производительность и оптимизация (HighLoad) v8 v8::blocking Бесплатно (free)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    9151    0    fhqhelp    0    

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным

Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка v8 Бесплатно (free)

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    10639    0    igordynets    119    

Ускорение чтения правил обмена в УПП 1.3 в 20 раз!

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    9343    0    YPermitin    16    

Хотите снизить нагрузку на процессор сервера в 2 раза?

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

В статье рассмотрено влияние частого запуска регламентных заданий на процессор сервера 1С.

27.06.2019    8975    0    Дмитрий74Чел    6    

Непридуманные истории по оптимизации. История 1

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    12112    0    Repich    117    

Оптимизация: неэффективные запросы

Производительность и оптимизация (HighLoad) Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

В большинстве случаев основной причиной медленной работы системы при многопользовательском режиме работы является блокировка данных СУБД (говорим про клиент-серверную версию). Блокировка - это не есть хорошо или плохо, это жизненно необходимая вещь при построении прикладной логики работы системы. Но блокировки таблиц, записей могут быть как вполне законными, так и далеко не всегда оправданными в каждой конкретной ситуации. Одной из самых распространенных причин неоптимальной блокировки ресурсов является некорректное написание запросов.

13.06.2019    5601    0    slayer-ekb    10    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    22897    0    dmurk    144