Есть 1С УПП 1.3.
В последнее время стала подтормаживать на формировании отчетов. Также если большая нагрузка на сервере, то оборотно-сальдовые ведомости начинают выдавать кривые данные. Можно несколько раз сформировать отчет и получим разные цифры.
Объем базы около 1 Тб. Серверы довольно быстрые. Описание в приложенных файлах.
Регламентное обслуживание БД производится регулярно. Обновление статистики, переиндексации и т.п.
Такое ощущение, что 1С просто не дожидается получения всех данных и выдает то, что получилось.
Подскажите, что можно посмотреть.
В последнее время стала подтормаживать на формировании отчетов. Также если большая нагрузка на сервере, то оборотно-сальдовые ведомости начинают выдавать кривые данные. Можно несколько раз сформировать отчет и получим разные цифры.
Объем базы около 1 Тб. Серверы довольно быстрые. Описание в приложенных файлах.
Регламентное обслуживание БД производится регулярно. Обновление статистики, переиндексации и т.п.
Такое ощущение, что 1С просто не дожидается получения всех данных и выдает то, что получилось.
Подскажите, что можно посмотреть.
Прикрепленные файлы:
Сервер 1С.txt
Сервер SQL.txt
По теме из базы знаний
Найденные решения
(29) Ну да... Это первое что нужно было сделать...
Только отмечу, что если у вас в базе закралась ошибка в различии данных и итогов в старых периодах, и это влияет на результаты запросов, то это значит, что запросы выполняются нестабильно и расчет ведется то по таблице остатков, то по таблице движений (с каким-то совершенно диким сканированием). Это очень странно. Платформа не 8.1 часом?
Еще опишу для потомков похожую ситуацию, чтобы голову не ломали...
Ситуация: итоги хозрасчетного не были рассчитаны с 2016 года... Соответственно все остатки после последних рассчитанных итогов получались по "всем" движениям в readuncommited от даты остатков и до текущих (3999).Т.е. остаки на 01.01.2017 скачут в момент активной работы с 2018 годом, т.е. с нерассчитанным периодом.
Варианты решений:
- рассчитать остатки за закрытый период, если в нем получаете остатки.
- отключить текущие итоги (расчет будет производиться от последнего сохраненного остатка). В неоперативном учете они как правило не нужны и только вредят (нужно оценировать производительность каждого случая)
- минимизирует "скачки" проведение документов без предварительной очистки движений и записи пустых наборов.
ну и наконец.... тадам...
- получение данных без грязного чтения... Само собой речь о RCSI...
ПС: чего зацепился на ваш пост... Уж больно похожая ситуация была совсем недавно в Минске... И 1 Тб, и база УПП1.3... и именно ОСВ чудила... Это были не вы? ))))))))))
Только отмечу, что если у вас в базе закралась ошибка в различии данных и итогов в старых периодах, и это влияет на результаты запросов, то это значит, что запросы выполняются нестабильно и расчет ведется то по таблице остатков, то по таблице движений (с каким-то совершенно диким сканированием). Это очень странно. Платформа не 8.1 часом?
Еще опишу для потомков похожую ситуацию, чтобы голову не ломали...
Ситуация: итоги хозрасчетного не были рассчитаны с 2016 года... Соответственно все остатки после последних рассчитанных итогов получались по "всем" движениям в readuncommited от даты остатков и до текущих (3999).Т.е. остаки на 01.01.2017 скачут в момент активной работы с 2018 годом, т.е. с нерассчитанным периодом.
Варианты решений:
- рассчитать остатки за закрытый период, если в нем получаете остатки.
- отключить текущие итоги (расчет будет производиться от последнего сохраненного остатка). В неоперативном учете они как правило не нужны и только вредят (нужно оценировать производительность каждого случая)
- минимизирует "скачки" проведение документов без предварительной очистки движений и записи пустых наборов.
ну и наконец.... тадам...
- получение данных без грязного чтения... Само собой речь о RCSI...
ПС: чего зацепился на ваш пост... Уж больно похожая ситуация была совсем недавно в Минске... И 1 Тб, и база УПП1.3... и именно ОСВ чудила... Это были не вы? ))))))))))
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(7) Если в ОСВ данные меняются на начало периода, тогда точно как у нас, у нас где то записывались данные на ПустуюДату - 01010001 и уходили меняя остатки, мы так и не нашли где он так проводит. Какое то движение сажается сначала на пустую дату, а затем сажается правильно и двигаются остатки
(1)
Учитывая подтормаживание и большую нагрузку на сервере(кстати, каком?) помимо (19) можно еще посмотреть цены на новый сервер, более современный и многоядерный чем ваши(особенно для сервера приложений)
Подскажите, что можно посмотреть.
Учитывая подтормаживание и большую нагрузку на сервере(кстати, каком?) помимо (19) можно еще посмотреть цены на новый сервер, более современный и многоядерный чем ваши(особенно для сервера приложений)
(21) Не думаю что сильно улучшит ситуацию более быстрый сервер. Тем более под нужный 1с и так выделены новые серверы с довольно высокой производительностью.
Нагрузки на сервер практически нет. Пробовали ставить более производительный сервер, результат никак уже не меняется.
Вот и хотел поинтересоваться, как люди живут с 1С больших объемов. В день у нас создается порядка 3-4 тысяч документов. Обрезку базы не предлагать, т.к. это результат дас, но очень временный.
По самому вопросу проблему решил. Оказалось что слетели итоги регистров 2015-2016 годов. А из никто давно уже не пересчитывал. Для ускорения просто пересчитывали последние 6 месяцев.
SQL поже малость пооптимизировал. На хабре нашел довольно неплохие примеры "осторожного" обновления статистики и дефрагментации индексов без серьезной нагрузки на сервер. Типовые варианты из планов обслуживания не подходят, т.к. серьезно снижают скорость работы сервера в момент самого обслуживания, что нам просто нельзя делать.
Нагрузки на сервер практически нет. Пробовали ставить более производительный сервер, результат никак уже не меняется.
Вот и хотел поинтересоваться, как люди живут с 1С больших объемов. В день у нас создается порядка 3-4 тысяч документов. Обрезку базы не предлагать, т.к. это результат дас, но очень временный.
По самому вопросу проблему решил. Оказалось что слетели итоги регистров 2015-2016 годов. А из никто давно уже не пересчитывал. Для ускорения просто пересчитывали последние 6 месяцев.
SQL поже малость пооптимизировал. На хабре нашел довольно неплохие примеры "осторожного" обновления статистики и дефрагментации индексов без серьезной нагрузки на сервер. Типовые варианты из планов обслуживания не подходят, т.к. серьезно снижают скорость работы сервера в момент самого обслуживания, что нам просто нельзя делать.
1. В качестве СУБД что используется?
2. Дисковая система сервера под СУБД (процессор(а) не единственный показатель скорости работы).
Это для начала.
2. Дисковая система сервера под СУБД (процессор(а) не единственный показатель скорости работы).
Это для начала.
Базу саму проверяли ? (DBCC CHECKDB ("Имя базы"). Далее саму статистику индексов смотрели? Лог сжимали?
(6)
Может попробовать статистику каждые три часа собирать? Не полную, конечно, выборочно. Скриптов на эту тему тут полно пробегало.
Статистику индексов тоже не смотрел, но периодически их обновляю
"периодически" - это как? "периодически" оно у всех по-разному. У кого-то - это раз в сутки, у кого-то каждый час.
Может попробовать статистику каждые три часа собирать? Не полную, конечно, выборочно. Скриптов на эту тему тут полно пробегало.
Не думаю что в этом дело. Проверяли даже так. На 2 ПК смотрим отчет. У меня отчет корректный. У ГБ остатки скачут.
Можно как вариант посмотреть в сторону ограничений данных на уровне записей RLS, если под полными правами работает ощутимо быстрее чем не под полными, в этом причина высокой нагрузки на сервер.
Была аналогичная ситуация правда база была не 1 Тб а 120 гигов, но отчет по партиям тоже всегда выдавал разный. Проявлялось это когда формируешь отчет (на скд) с вертикальными группировками по периоду (в колонках). Методом проб и ошибок установили что это компоновщик сервера 1С так сходит с ума. Решилась проблема с установкой 8.3.11, а до этого что только не перепробовали и версии с тем что записи в регистре скачут проверяли и базы тестировали и исправляли.
Проверьте ваш отчет в котором цифры пляшут, попробуйте в него добавить в группировку документ движения и скорей всего у вас данные скакать перестанут. Если поможет то это именно тот случай когда компоновщик начинает дурить (по не понятным причинам) - переставляйте платформу.
Проверьте ваш отчет в котором цифры пляшут, попробуйте в него добавить в группировку документ движения и скорей всего у вас данные скакать перестанут. Если поможет то это именно тот случай когда компоновщик начинает дурить (по не понятным причинам) - переставляйте платформу.
(27) Это связано с методикой расчета остатка от "текущих остатков" в не расчитанном периоде или используемом периоде + грязное чтение (nolock) в отчетах... "Скачут" незакомитченные данные - скачут цифры в отчетах. Что тут непонятного...
(29) Ну да... Это первое что нужно было сделать...
Только отмечу, что если у вас в базе закралась ошибка в различии данных и итогов в старых периодах, и это влияет на результаты запросов, то это значит, что запросы выполняются нестабильно и расчет ведется то по таблице остатков, то по таблице движений (с каким-то совершенно диким сканированием). Это очень странно. Платформа не 8.1 часом?
Еще опишу для потомков похожую ситуацию, чтобы голову не ломали...
Ситуация: итоги хозрасчетного не были рассчитаны с 2016 года... Соответственно все остатки после последних рассчитанных итогов получались по "всем" движениям в readuncommited от даты остатков и до текущих (3999).Т.е. остаки на 01.01.2017 скачут в момент активной работы с 2018 годом, т.е. с нерассчитанным периодом.
Варианты решений:
- рассчитать остатки за закрытый период, если в нем получаете остатки.
- отключить текущие итоги (расчет будет производиться от последнего сохраненного остатка). В неоперативном учете они как правило не нужны и только вредят (нужно оценировать производительность каждого случая)
- минимизирует "скачки" проведение документов без предварительной очистки движений и записи пустых наборов.
ну и наконец.... тадам...
- получение данных без грязного чтения... Само собой речь о RCSI...
ПС: чего зацепился на ваш пост... Уж больно похожая ситуация была совсем недавно в Минске... И 1 Тб, и база УПП1.3... и именно ОСВ чудила... Это были не вы? ))))))))))
Только отмечу, что если у вас в базе закралась ошибка в различии данных и итогов в старых периодах, и это влияет на результаты запросов, то это значит, что запросы выполняются нестабильно и расчет ведется то по таблице остатков, то по таблице движений (с каким-то совершенно диким сканированием). Это очень странно. Платформа не 8.1 часом?
Еще опишу для потомков похожую ситуацию, чтобы голову не ломали...
Ситуация: итоги хозрасчетного не были рассчитаны с 2016 года... Соответственно все остатки после последних рассчитанных итогов получались по "всем" движениям в readuncommited от даты остатков и до текущих (3999).Т.е. остаки на 01.01.2017 скачут в момент активной работы с 2018 годом, т.е. с нерассчитанным периодом.
Варианты решений:
- рассчитать остатки за закрытый период, если в нем получаете остатки.
- отключить текущие итоги (расчет будет производиться от последнего сохраненного остатка). В неоперативном учете они как правило не нужны и только вредят (нужно оценировать производительность каждого случая)
- минимизирует "скачки" проведение документов без предварительной очистки движений и записи пустых наборов.
ну и наконец.... тадам...
- получение данных без грязного чтения... Само собой речь о RCSI...
ПС: чего зацепился на ваш пост... Уж больно похожая ситуация была совсем недавно в Минске... И 1 Тб, и база УПП1.3... и именно ОСВ чудила... Это были не вы? ))))))))))
(30) Нет, это были не мы :)
Отключение текущих итогов сильно снизит скорость работы?
В нашем случае произошел похоже какой-то сбой в базе и слетели все итоги регистров бухгалтерии. Пересчитали все итоги, хоть и непросто это было )) Но пользователи пережили. В текущем же режиме пересчитываем раз в неделю только последние 3 месяца. Я просто не ожидал что итоги могут упасть с 2012 года. Думал проблемы на стороне sql.
Сейчас годовая ОСВ формируется за несколько секунд и без глюков.
Отключение текущих итогов сильно снизит скорость работы?
В нашем случае произошел похоже какой-то сбой в базе и слетели все итоги регистров бухгалтерии. Пересчитали все итоги, хоть и непросто это было )) Но пользователи пережили. В текущем же режиме пересчитываем раз в неделю только последние 3 месяца. Я просто не ожидал что итоги могут упасть с 2012 года. Думал проблемы на стороне sql.
Сейчас годовая ОСВ формируется за несколько секунд и без глюков.
(31)
Однозначного ответа нет.
Совершенно точно, что это лишняя нагрузка на СУБД и потенциальные конфликты блокировок на текущих итогах ПРИ ЗАПИСИ.
А вот ПРИ ЧТЕНИИ текущие итоги могут как помогать, так и вредить. Все зависит от даты рассчитанных итогов и "периода остатков". Как правило польза есть (в подавляющем количестве случаев, для этого и придумали текущие итоги), если дата остатков не задана (идеально) или близко к последним записям в регистре. Но бывает, что их использование избыточно и отключение оправдано.
Общее состояние (запись + чтение) может оценить только глубокий анализ и тестирование.
Отключение текущих итогов сильно снизит скорость работы?
Однозначного ответа нет.
Совершенно точно, что это лишняя нагрузка на СУБД и потенциальные конфликты блокировок на текущих итогах ПРИ ЗАПИСИ.
А вот ПРИ ЧТЕНИИ текущие итоги могут как помогать, так и вредить. Все зависит от даты рассчитанных итогов и "периода остатков". Как правило польза есть (в подавляющем количестве случаев, для этого и придумали текущие итоги), если дата остатков не задана (идеально) или близко к последним записям в регистре. Но бывает, что их использование избыточно и отключение оправдано.
Общее состояние (запись + чтение) может оценить только глубокий анализ и тестирование.
(29)
Я же у Вас спрашивал и отчет был что итоги пересчитаны. При пересчёте в конфигураторе (не путать с расчётом в пользовательском интерфейсе за период) итоги считаются полностью, поэтому и спросил именно про пересчёт)))
Ну решилось и отлично!
Пропали тормоза
Я же у Вас спрашивал и отчет был что итоги пересчитаны. При пересчёте в конфигураторе (не путать с расчётом в пользовательском интерфейсе за период) итоги считаются полностью, поэтому и спросил именно про пересчёт)))
Ну решилось и отлично!
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот