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

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

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

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

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

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

Вы обслуживаете базу данных среднего или большого размера? Имею ввиду размер от 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 не являются полностью универсальными, как Вы могли убедиться из примера выше.

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

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

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

122

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

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

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

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

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

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

P.S. про терминатора Огонь!
7. nicxxx 236 14.10.19 16:14 Сейчас в теме
Включите уже traceflag 2371 и забудьте о ручном обновлении статистики.
Ashandy; YPermitin; +2 Ответить
8. YPermitin 5706 14.10.19 16:19 Сейчас в теме
(7) это применимо, но далеко не всегда. Расскажите свой случай, где Вам настройка помогла, если есть такая возможность.
9. nicxxx 236 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 5706 21.10.19 16:36 Сейчас в теме
(11) (9) все никак не успеваю ответить.

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

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

См. также

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

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

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

22.10.2019    2010    EugeneSemyonov    10       

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

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

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

30.09.2019    10828    YPermitin    13       

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

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

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

13.09.2019    4113    Repich    4       

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

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

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

10.09.2019    7945    Sloth    11       

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

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

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

31.08.2019    3242    93    YPermitin    7       

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

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 v8::СКД 1cv8.cf Windows Абонемент ($m) Инструментарий разработчика

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

2 стартмани

24.07.2019    5961    80    YPermitin    25       

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

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

19.07.2019    4656    Филин    12       

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

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

16.07.2019    4088    fhqhelp    0       

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

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

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

02.07.2019    6503    igordynets    119       

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

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

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

27.06.2019    4965    YPermitin    16       

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

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

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

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

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

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

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

13.06.2019    7967    Repich    117       

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

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

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

13.06.2019    2948    slayer-ekb    10       

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С 91

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

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    8208    ivanov660    5       

Не думать о секундах свысока... 56

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

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    4709    vasilev2015    21       

Альтернативная стратегия управления блокировками 45

Статья Программист Архив с данными v8 v8::blocking 1cv8.cf Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

20.05.2019    4139    zhichkin    15       

Как работают управляемые блокировки 122

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

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

29.04.2019    13947    comol    198       

Странное потребление места на диске С 33

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

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    10918    kuzyara    12       

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С 51

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

С версии 1С 8.3.14 в платформе появился новый функционал «Копии базы данных». В данной публикации я хочу рассказать, как включить использование данного механизма в платформе 1с и как его использовать для получения отчетов с копии базы данных, которая может быть вынесена на внешний сервер относительно текущей базы данных, а также как использовать систему «Дата акселератор», в которой база данных целиком размещена в оперативной памяти рабочего сервера кластера серверов «1С:Предприятия».

25.04.2019    8769    Elf1k    27       

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С 202

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

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

18.04.2019    18986    ivanov660    68       

Как разбить базу на файлы и не сойти с ума 108

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

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    9338    YPermitin    29       

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз 124

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

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    10344    w.r.    23       

Простое программное решение проблем с блокировками SQL 17

Статья Системный администратор Программист Нет файла v8 v8::blocking 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    6280    dmitrydemenew    38       

Другой взгляд на APDEX и подсистему "Оценка производительности" 81

Статья Системный администратор Программист Нет файла 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

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

20.02.2019    9865    YPermitin    30       

Производительность сервера 1С и фоновые задания 63

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

В падении производительности сервера 1С зачастую виноваты не регламентные / фоновые задания, они выполняют полезную работу. Но задания нельзя оставлять «наедине» с базой.

05.02.2019    11322    user715208    38       

Новый режим реструктуризации (обновление базы данных на сервере в режиме v2) 170

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

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

31.10.2018    19361    Dach    46       

Нетривиальные подходы в решении всем известных проблем: ускорение «больших» документов в 1С и ускорение поиска по подстроке. Как добиться эффекта в разы? 62

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

Часто у пользователей 1С поиск информации по большим спискам данных по подстроке занимает продолжительное время. Павел Баркетов рассматривает причины торможения запросов с поиском по подстроке и описывает возможности и подходы к их оптимизации и ускорению. Также в статье разобраны причины длительного проведения «больших» документов (более 10 000 строк) и даны рекомендации по ускорению этих операций.

30.08.2018    11386    gallam99    31       

Кейс: как мы разрабатывали систему автоматизации анализа ошибок, связанных со скоростью работы 1С 43

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

Бурмистров Андрей рассказывает о создании инструмента по автоматизации анализа неоптимальных запросов в коде 1С. Он поднимает вопрос о предпосылках создания этого инструмента, рассказывает о возникших форс-мажорных ситуациях, с которыми столкнулась команда в процессе разработки, и о том, как они с ними справлялись.

27.08.2018    7739    Andreynikus    20       

3000 пользователей на трехъядерном Athlon – сверхтонкий веб-клиент для 1С 97

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

Юрий Лазаренко поделится опытом ускорения 1С нестандартными методами, в том числе с помощью http-сервисов. Он расскажет, как с помощью сверхтонкого клиента для 1С и интеграции с сайтом удалось добиться ускорения 1С на порядок. Также в статье приведена статистика по отчету о нагрузочном тестировании сверхтонкого клиента для 1С:ITIL.

16.08.2018    11709    TitanLuchs    28       

Когда условие в срезе последних даже вредит 20

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

Спойлер: оптимизатор MSSQL видит внешние, по отношению к срезу, условия, и строит план с их учетом.

05.08.2018    8052    nicxxx    105       

Оптимизация без оптимизации: как мы ускорили 1С в 10 раз без трудоемкой оптимизации запросов и алгоритмов. Практический опыт 81

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

Можно ли ускорить 1С, не оптимизируя запросы, не разбивая транзакции и не наращивая оборудование? В статье Аверьянова Алексея рассмотрены три практических кейса повышения производительности системы без трудоемкой оптимизации: отложенное резервирование «в один поток», отложенное создание и проведение реализаций.

26.07.2018    13544    avryanovalexey    100       

Альтернативные технологии нагрузочного тестирования серверной части кода прикладных решений на платформе 1С 56

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

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

12.07.2018    8593    jf2000    10       

Архитектура ИТ-системы на базе 1С в крупной организации. Часть 2. Чудес не бывает 81

Статья Системный администратор Нет файла v8 УТ11 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Развернуто отвечаю, как мы боремся с зависаниями системы и вообще решаем проблемы. С примерами, но без слайдов.

04.07.2018    12555    Repich    74       

Архитектура ИТ-системы на базе 1С в крупной организации 101

Статья Системный администратор Нет файла v8 УТ11 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В данной статье я хотел бы очень крупными мазками обрисовать архитектуру ИТ системы на базе 1С в крупных (более 1 тысячи пользователей) организациях. Она не несет какой либо образовательной цели, это просто попытка показать – «а как у нас».

02.07.2018    15149    Repich    112       

Взгляд на ошибки и платформу через призму HI-Load 53

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

Поговорим об ошибках в целом и их влиянии на Hi-Load системы в частности. Может ли тут помочь платформа 1С? (да и должна ли в принципе?) Немного про сам Hi-Load на примере крупной БД. PS Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY.

18.06.2018    10343    Sergey.Noskov    27       

Простые регулярные выражения 59

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

Шпаргалка к экзамену "Эксперт по технологическим вопросам".

30.04.2018    12111    3    vasilev2015    30       

Неоптимальная работа запроса 130

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

Шпаргалка к экзамену "Эксперт по технологическим вопросам".

27.04.2018    17368    vasilev2015    32       

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

Инструменты и обработки Системный администратор Программист Архив с данными Абонемент ($m) Производительность и оптимизация (HighLoad)

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

1 стартмани

22.03.2018    20985    26    Tavalik    7       

Неоптимальности вида «план исполнения запроса "испортился"» - поиск и исправление 69

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

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

05.02.2018    14063    fhqhelp    20       

Пример поиска неоптимальности при загрузке SQL-сервера по CPU на 100% 83

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

Вечер пятницы, ничто не предвещало.. Звонок из техподдержки: "центральная база розничной сети лежит". Далее расследование причин.

23.12.2017    15719    fhqhelp    32