Никогда не используйте VACUUM FULL
Юзер экспириенс postgres иногда может быть самую малость удивительным. Хотя VACUUM FULL звучит как то, что вы бы хотели сделать, чтобы вычистить “пыль” вашей базы данных, более подходящей командой была бы:
Если вы используете PostgreSQL уже какое-то время, скорее всего, вы видели такие ошибки, как:
Это происходит, когда параллельные транзакции принимают одинаковые блокировки в другом порядке. Например, одна транзакция выполняет следующие команды.
Одновременно другая транзакция может выдавать те же команды, но в другом порядке.
Мы надеемся, что вы нашли эти рекомендации полезными. Если у вас есть другие советы, не стесняйтесь писать в Твиттере @citusdata или в нашем активном сообществе пользователей Citus в Slack.
Напоминаем о том, что уже через несколько часов состоится день открытых дверей на котором мы подробно расскажем о программе предстоящего курса.
Микрофинансирование → Микрокредиты → Специальные предложения → Скачать файлы → Обзор Быстроденег → Предмет договора → Ответственность сторон → Отличные наличные→ Экспресс займы
Пример решения проблемы блокировок
Как еще можно избавиться от излишних ожиданий?
Допустим, у вас есть торговые представители, которые после окончания рабочего дня (в 6 часов вечера), отправляют документы в базу. А там, как только эти документы через мобильный интернет приходят, они сразу пытаются загрузиться и провестись. В результате, если торговые представители заказали один и тот же товар с одного и того же склада, возникает ожидание, потому что они обращаются к одним и тем же данным, и поскольку там есть контроль остатков, разделитель итогов не поможет и кому-то кого-то придется ждать.
Как этого можно избежать? Можно при загрузке документы создавать, но не проводить, а потом написать механизм, который, например, реализует это дальнейшее проведение в многопоточном режиме, где каждый поток будет проводить документы по своему складу. Разнести, таким образом, эти процессы во времени: первый поток проводит документы по одному складу, второй поток – по второму складу и т.д. Тогда проблема будет решена.
Причины и способы решения проблемы
Большое количество выполняемых операций
Первым делом при поиске причин следует уточнить, сколько же одновременно работающих пользователей находится в той информационной базе, в которой выдается подобная ошибка. Как мы знаем, максимальное их количество может быть довольно большим. Это и тысяча, и пять тысяч.
Механизм блокировок и транзакций описан в руководстве разработчика. Их используют при обращении нескольких сеансов к одним и тем же данным одновременно. Логично, что одни и те же данные не могут изменяться разными пользователями в один и тот же момент.
Так же следует проверить, не запущено ли у кого-то из пользователей обработки по массовому изменению данных. Это может быть как групповое проведение документов, закрытие месяца и тому подобное. В таком случае после окончания работы обработки ошибка пропадет сама по себе.
Регламентные задания
Не редки случаи, когда причина ошибки кроется в регламентном задании, которое обрабатывает большое количеств данных. Рекомендуется подобные вещи делать ночью. Задайте расписание выполнение таких регламентных заданий во внерабочее время.
Таким образом, и пользователи будут работать в стабильной системе, и сами регламентные задания будут завершаться успешно, так как снизится вероятность возникновения конфликтов с пользовательскими сеансами.
«Зависшие сеансы»
Проблема «зависших сеансов» пользователей знакома практически каждому, кто сталкивался с обслуживанием 1С. Пользователь мог уже давно выйти из программы, или закрыть какой-либо документ, но его сеанс по-прежнему остается в системе. Проблема чаще всего единичная и достаточно завершить подобный сеанс через консоль администратора. Такие же проблемы могут возникнуть и с фоновыми заданиями.
По многочисленным комментариям на просторах интернета подобные ситуации чаще встречаются при использовании сетевых ключей защиты. Если ситуация с «зависающими сеансами» повторяется систематически, это причина произвести тщательную проверку и обслуживание системы и серверов (если база клиент-серверная).
Ошибки при написании конфигурации
Все типовые конфигурации разработаны квалифицированными специалистами и экспертами. Каждая система тщательно тестируется и оптимизируется для более быстрой и корректной работы в ней.
В связи с этим причина ошибки может крыться в неоптимальном коде, написанном сторонним разработчиком. Это может быть «тяжелый» запрос, который будет блокировать данные на длительный промежуток времени. Так же нередки случаи построения алгоритмов с низкой производительностью и нарушением логики.
Большая вероятность, что конфликт блокировки возник именно из-за ошибок разработчика, если он возник после обновления программы. Для проверки можно просто «откатить» доработки, либо произвести рефакторинг кода.
Копирование числовых ячеек из 1С в Excel Промо
Решение проблемы, когда значения скопированных ячеек из табличных документов 1С в Excel воспринимаются последним как текст, т.е. без дополнительного форматирования значений невозможно применить арифметические операции. Поводом для публикации послужило понимание того, что целое предприятие с более сотней активных пользователей уже на протяжении года мучилось с такой, казалось бы на первый взгляд, тривиальной проблемой. Варианты решения, предложенные специалистами helpdesk, обслуживающими данное предприятие, а так же многочисленные обсуждения на форумах, только подтвердили убеждение в необходимости описания способа, который позволил мне качественно и быстро справиться с ситуацией.
Инструмент для анализа блокировок
И в заключение я хочу показать инструмент, с помощью которого вы в реальном времени можете посмотреть, какие данные сейчас в системе заблокированы.
Это обработка «Текущие блокировки MS SQL Server и 1С» – она показывает вам, кто заблокировал, что заблокировал, какие конкретно данные именно в терминах 1С. Я эту обработку недавно выложил на Инфостарт – можете ее скачать, посмотреть.
Здесь – открываете, заполняете настройки.
Если хотите увидеть блокировки 1С, включаете флаг «Отображать блокировки 1С» – у вас в течение одной минуты должен включиться технологический журнал. И после этого, когда минута прошла – вы сможете увидеть, какие именно блокировки у вас наложены в базе данных на текущий момент(например, в момент, когда вы встанете на точке останова после строки Движения.Записать() и пытаетесь провести два документа, которые пересекаются по данным – и в первом и во втором документе используется один и тот же товар).
Итак, мы ставим точку останова и теперь по очереди проводим первый документ, а потом в другом пользовательском сеансе проводим второй документ – он, естественно, встает в очередь. Получается ожидание.
Как эту ситуацию отображает обработка? Она показывает, что пользователь Петров заблокирован пользователем Администратор. И при этом вы можете увидеть, что именно заблокировал Администратор и что именно заблокировал Петров.
Нежирным шрифтом показаны блокировки СУБД – можно увидеть, в какой таблице, в каком индексе, какой состав индекса, какой статус блокировки («установлена» или «ожидание»).
Сделав двойной клик, вы можете увидеть, какие именно записи были заблокированы. Причем, по сравнению с ЦУП или с сервисами Гилева, которые показывают информацию уже тогда, когда ожидание завершилось, эта обработка показывает состояние именно на текущий момент времени. Все ссылки рабочие.
Жирным шрифтом отображаются блокировки 1С – также можно поглядеть, что именно было заблокировано.
Проблема с блокировками очень обширна, и можно еще много чего рассказать о том, как узнать, сколько времени у вас система проводит на ожиданиях и как конкретно можно оптимизировать производительность ее работы.
***************
Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER. Больше статей можно прочитать здесь.
В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.
Выбрать мероприятие.
Практическая проверка материала
Как и раньше, приведу пример для практической проверки материала. Создадим базу данных, в которой установим режим управления блокировкой «Управляемый», основной режим запуска «Обычное приложение», режим использования модальных окон в «Использовать». Добавим в базу регистр сведений «АнализУправляемыхБлокировок» (непериодический, независимый). В регистре добавим измерения: «Измерение1» (тип Число), «Измерение2» (тип Число). Не забудьте настроить технологический журнал как указано в начале статьи. Теперь откройте обработку из вложения к данной статье в двух сеансах, выполните нижеприведенные кейсы и проанализируйте технологический журнал.
Таймаут (TTIMEOUT)
Для создания таймаута необходимо в первом сеансе нажать кнопку «Таймаут 1», во-втором — «Таймаут 2». Дождаться сообщения о таймауте во втором сеансе.
Длительное ожидание на блокировке
Так же как и для таймаута, в первом сеансе нажать «Таймаут 1», во-втором — «Таймаут 2». И не дожидаясь сообщения о таймауте, в первом сеансе нажать кнопку «ОК» модального окна.
Взаимоблокировка вида «захват ресурсов в разном порядке»
В первом сеансе нажать «Взаимоблокировка 1», во-втором «Взаимоблокировка 2», после чего сразу же нажать «ОК» модального окна в первом сеансе, а затем во-втором.
Конфликт блокировок при выполнении транзакции в 1С 8.3 и 8.2
Не редко при работе в 1С возникает ошибка «Конфликт блокировок при выполнении транзакций: Превышено максимальное время ожидания предоставления блокировки». Суть ее кроется в том, что несколько сеансов пытаются одновременно выполнить похожие действия, затрагивая один и тот же ресурс. Сегодня мы разберемся как исправить данную ошибку
Большое количество выполняемых операций
Первым делом при поиске причин следует уточнить, сколько же одновременно работающих пользователей находится в той информационной базе, в которой выдается подобная ошибка. Как мы знаем, максимальное их количество может быть довольно большим. Это и тысяча, и пять тысяч.
Механизм блокировок и транзакций описан в руководстве разработчика. Их используют при обращении нескольких сеансов к одним и тем же данным одновременно. Логично, что одни и те же данные не могут изменяться разными пользователями в один и тот же момент.
Так же следует проверить, не запущено ли у кого-то из пользователей обработки по массовому изменению данных. Это может быть как групповое проведение документов, закрытие месяца и тому подобное. В таком случае после окончания работы обработки ошибка пропадет сама по себе.
Регламентные задания
Не редки случаи, когда причина ошибки кроется в регламентном задании, которое обрабатывает большое количеств данных. Рекомендуется подобные вещи делать ночью. Задайте расписание выполнение таких регламентных заданий во внерабочее время.
Таким образом, и пользователи будут работать в стабильной системе, и сами регламентные задания будут завершаться успешно, так как снизится вероятность возникновения конфликтов с пользовательскими сеансами.
«Зависшие сеансы»
Проблема «зависших сеансов» пользователей знакома практически каждому, кто сталкивался с обслуживанием 1С. Пользователь мог уже давно выйти из программы, или закрыть какой-либо документ, но его сеанс по-прежнему остается в системе. Проблема чаще всего единичная и достаточно завершить подобный сеанс через консоль администратора. Такие же проблемы могут возникнуть и с фоновыми заданиями.
По многочисленным комментариям на просторах интернета подобные ситуации чаще встречаются при использовании сетевых ключей защиты. Если ситуация с «зависающими сеансами» повторяется систематически, это причина произвести тщательную проверку и обслуживание системы и серверов (если база клиент-серверная).
Ошибки при написании конфигурации
Все типовые конфигурации разработаны квалифицированными специалистами и экспертами. Каждая система тщательно тестируется и оптимизируется для более быстрой и корректной работы в ней.
В связи с этим причина ошибки может крыться в неоптимальном коде, написанном сторонним разработчиком. Это может быть «тяжелый» запрос, который будет блокировать данные на длительный промежуток времени. Так же нередки случаи построения алгоритмов с низкой производительностью и нарушением логики.
Большая вероятность, что конфликт блокировки возник именно из-за ошибок разработчика, если он возник после обновления программы. Для проверки можно просто «откатить» доработки, либо произвести рефакторинг кода.
Если Ваша программа 1С:Підприємство со временем работает заметно хуже
- медленно проводятся документы 1С:Підприємство
- 1С:Підприємство медленно работает и долго думает
- 1С:Підприємство регулярно висит и постоянно подвисает
- медленно формируются отчеты 1С:Підприємство
- большой размер базы 1С:Підприємство
- постоянное и непонятное увеличение размера базы 1С:Підприємство
- регулярные сообщение об ошибке:«Конфликт блокировок при выполнении транзакции: Microsoft OLE DB Provider for SQL Server: Lock request time out period exceeded. HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=34, Severity=10, native=1222, line=1»
Пора оптимизировать 1С:Підприємство
Почему надо бить тревогу
Для начала, давайте разберемся, что же такое представляет собой ошибка «В данной транзакции уже происходили ошибки». Это, на самом деле, предельно простая штука: вы пытаетесь работать с базой данных внутри уже откаченной (отмененной) транзакции. Например, где-то был вызван метод ОтменитьТранзакцию, а вы пытаетесь ее зафиксировать.
Почему это плохо? Потому что данная ошибка ничего не говорит вам о том, где на самом деле случилась проблема. Когда в саппорт от пользователя приходит скриншот с таким текстом, а в особенности для серверного кода, с которым интерактивно не работает человек — это… Хотел написать «критичная ошибка», но подумал, что это buzzword, на который уже никто не обращает внимания…. Это задница. Это ошибка программирования. Это не случайный сбой. Это косяк, который надо немедленно переделывать. Потому что, когда у вас фоновые процессы сервера встанут ночью и компания начнет стремительно терять деньги, то «В данной транзакции уже происходили ошибки» это последнее, что вы захотите увидеть в диагностических логах.
Есть, конечно, вероятность, что технологический журнал сервера (он ведь у вас включен в продакшене, да?) как-то поможет диагностировать проблему, но я сейчас навскидку не могу придумать вариант — как именно в нем найти реальную причину указанной ошибки. А реальная причина одна — программист Вася получил исключение внутри транзакции и решил, что один раз — не карабас «подумаешь, ошибка, пойдем дальше».
Причины и способы решения проблемы
Большое количество выполняемых операций
Первым делом при поиске причин следует уточнить, сколько же одновременно работающих пользователей находится в той информационной базе, в которой выдается подобная ошибка. Как мы знаем, максимальное их количество может быть довольно большим. Это и тысяча, и пять тысяч.
Механизм блокировок и транзакций описан в руководстве разработчика. Их используют при обращении нескольких сеансов к одним и тем же данным одновременно. Логично, что одни и те же данные не могут изменяться разными пользователями в один и тот же момент.
Так же следует проверить, не запущено ли у кого-то из пользователей обработки по массовому изменению данных. Это может быть как групповое проведение документов, закрытие месяца и тому подобное. В таком случае после окончания работы обработки ошибка пропадет сама по себе.
Регламентные задания
Не редки случаи, когда причина ошибки кроется в регламентном задании, которое обрабатывает большое количеств данных. Рекомендуется подобные вещи делать ночью. Задайте расписание выполнение таких регламентных заданий во внерабочее время.
Таким образом, и пользователи будут работать в стабильной системе, и сами регламентные задания будут завершаться успешно, так как снизится вероятность возникновения конфликтов с пользовательскими сеансами.
«Зависшие сеансы»
Проблема «зависших сеансов» пользователей знакома практически каждому, кто сталкивался с обслуживанием 1С. Пользователь мог уже давно выйти из программы, или закрыть какой-либо документ, но его сеанс по-прежнему остается в системе. Проблема чаще всего единичная и достаточно завершить подобный сеанс через консоль администратора. Такие же проблемы могут возникнуть и с фоновыми заданиями.
По многочисленным комментариям на просторах интернета подобные ситуации чаще встречаются при использовании сетевых ключей защиты. Если ситуация с «зависающими сеансами» повторяется систематически, это причина произвести тщательную проверку и обслуживание системы и серверов (если база клиент-серверная).
Ошибки при написании конфигурации
Все типовые конфигурации разработаны квалифицированными специалистами и экспертами. Каждая система тщательно тестируется и оптимизируется для более быстрой и корректной работы в ней.
В связи с этим причина ошибки может крыться в неоптимальном коде, написанном сторонним разработчиком. Это может быть «тяжелый» запрос, который будет блокировать данные на длительный промежуток времени. Так же нередки случаи построения алгоритмов с низкой производительностью и нарушением логики.
Большая вероятность, что конфликт блокировки возник именно из-за ошибок разработчика, если он возник после обновления программы. Для проверки можно просто «откатить» доработки, либо произвести рефакторинг кода.
Знакомимся с текстами ошибок.
При работе формы произошла системная ошибка (нарушена синхронизация состояния формы на клиенте и на сервере). «Данные формы не могут быть локально зафиксированы»
При работе формы произошла системная ошибка (нарушена синхронизация состояния формы на клиенте и на сервере). «Различаются значения счётчиков для данных форм»
Расследование:
Для того, чтобы понять, что происходит:
Включаем технологический журнал на всех серверах 1С:Предприятия кластера, в котором находится интересующая нас информационная база. Используем наиболее полный файл настроек технологического журнала 1С(пример файла можно посмотреть в Настройка и сбор логов для анализа проблем производительности систем 1С на Linux);
Просим пользователя воспроизвести ошибку;
Забираем записи технологического журнала со всех серверов кластера к себе на компьютер;
Приступаем к анализу логов тж с помощью утилиты git bash.
Общие сведения
Одной из часто встречающихся причин неоптимальной работы системы является неправильное или несвоевременное выполнение регламентных операций на уровне СУБД
Особенно важно выполнять эти регламентные процедуры в крупных информационных системах, которые работают под значительной нагрузкой и обслуживают одновременно большое количество пользователей. Специфика таких систем в том, что обычных действий, выполняемых СУБД автоматически (на основании настроек) оказывает недостаточно для эффективной работы
Если в работающей системе наблюдаются какие-либо симптомы проблем с производительностью, следует проверить, что в системе правильно настроены и регулярно выполняются все рекомендуемые регламентные операции на уровне СУБД.
Выполнение регламентных процедур должно быть автоматизировано. Для автоматизации этих операций рекомендуется использовать встроенное средства MS SQL Server: Maintenance Plan. Существуют так же другие способы автоматизации выполнения этих процедур. В настоящей статье для каждой регламентной процедуры дан пример ее настройки при помощи Maintenance Plan для MS SQL Server 2005.
Для MS SQL Server рекомендуется выполнять следующие регламентные операции:
- Обновление статистик
- Очистка процедурного КЭШа
- Дефрагментация индексов
- Реиндексация таблиц базы данных
Рекомендуется регулярно контролировать своевременность и правильность выполнения данных регламентных процедур.
Мониторинг производительности системы
Если производительность системы признана неудовлетворительной или недостаточной, то этот шаг можно пропустить. Переходите непосредственно к оптимизации системы.
Мониторинг производительности системы рекомендуется использовать в том случае, если текущая производительность признается удовлетворительной.
Мониторинг позволит решить следующие задачи:
- Собирать и накапливать объективную информацию о производительности системы.
- Оперативно диагностировать проблемы производительности.
- Выявлять скрытые проблемы производительности. При определенных условиях (например, в начале работы системы, когда информационная база содержит незначительное количество данных) система может работать неоптимально, но пользователи системы не будут этого замечать. Впоследствии эти скрытые проблемы могут проявиться.
Для решения этой задачи рекомендуется использовать Центр управления производительностью, входящий в состав 1С:Корпоративного инструментального пакета.
Рекомендуемая последовательность действий
1. Подключитесь к исследуемой информационной базе при помощи ЦУП в режиме “Мониторинг”.
Подробные инструкции по подключению см. в книге “1С:Корпоративный инструментальный пакет 8. Редакция 1.1. Руководство по использованию”, стр. 37.
2. Включите сбор следующих показателей производительности:
- Запросы Максимальное время выполнения запроса;
- Запросы Среднее время выполнения запроса;
- Ожидания на блокировках Только блокировки СУБД Среднее время ожидания на блокировке СУБД;
- Ожидания на блокировках Только блокировки СУБД Количество таймаутов;
- Ожидания на блокировках Только блокировки 1С Среднее время ожидания на блокировке 1С;
- Взаимоблокировки Количество взаимоблокировок.
Подробные инструкции см. там же, на стр. 41.
3. Включите запись всех показателей производительности (см. там же, на стр. 45).
4. Рекомендуется осуществлять постоянный мониторинг и вести запись показателей в течение всего “срока жизни” системы.
Парсим технологический журнал 1С по пользователю, у которого возникла ошибка, в временном интервале ее возникновения.
1 | grep-P’^01:.+Лапина|^02:.+Иванов’—color/D/logs1с/rphost_*/21042611.log |
При разборе обнаруживаем таймаут, согласно которому пользователь Иванов ожидает освобождения ресурсов
1 | 0218.818000-,TTIMEOUT,5,process=rphost,pprocessName=base,OSThread=31645,tclientID=235804,tapplicationName=WebServerExtension,tcomputerName=1s-on-web,tconnectID=787239,SessionID=55681,Usr=Иванов,AppID=1CV8C,DBMS=DBPOSTGRS,DataBase=1s-on-1c\base,WaitConnections=739428,Context=’Форма.ВызовОбщаяФорма.ГруппыИПолномочия.Модуль.СохранитьНастройкиНаСервере |
В тексте данного сообщения технологического журнала — находим номер соединения, которое блокирует ресурсы.
В нашем случае — это соединение 739428.
Архив
АрхивВыберите месяц Декабрь 2021 (1) Февраль 2018 (1) Октябрь 2017 (1) Июль 2017 (1) Июнь 2017 (2) Май 2017 (1) Март 2017 (3) Февраль 2017 (1) Октябрь 2016 (9) Сентябрь 2016 (3) Август 2016 (2) Июнь 2016 (3) Май 2016 (1) Апрель 2016 (1) Февраль 2016 (3) Январь 2016 (1) Октябрь 2015 (3) Июль 2015 (2) Июнь 2015 (3) Май 2015 (2) Апрель 2015 (8) Март 2015 (1) Февраль 2015 (11) Январь 2015 (6) Декабрь 2014 (2) Ноябрь 2014 (1) Сентябрь 2014 (1) Август 2014 (1) Июнь 2014 (1) Март 2014 (7) Февраль 2014 (2) Январь 2014 (2) Декабрь 2013 (4) Октябрь 2013 (3) Сентябрь 2013 (2) Август 2013 (2) Июль 2013 (2) Апрель 2013 (4) Март 2013 (14) Февраль 2013 (54) Январь 2013 (51) Декабрь 2012 (7) Октябрь 2012 (3) Сентябрь 2012 (2) Август 2012 (4) Июль 2012 (7) Июнь 2012 (3) Май 2012 (7) Апрель 2012 (6) Март 2012 (3) Февраль 2012 (7) Июнь 2011 (1) Май 2011 (1) Апрель 2011 (5) Март 2011 (18) Февраль 2011 (14) Январь 2011 (9) Декабрь 2010 (13)