Добрый день, вчера начались дикие тормоза при формировании любого отчет на SQL версии 1С, при этом на самом сервере ресурсов много не съедается, но при запуске монитора ресурсов, иногда вылетает с ошибкой. Сервер перезагружал, проблема не исчезла.
На сервере стоит SQL 2008 R2 Standard, конфигурация: Xeon 5649 2.53Ghz, 16Gb, программа УПП 1.3.63.4
В каком направлении искать, с чего начать поиски проблемы?

1. настроить регламенты SQL
2. 16Gb - это мало, увеличить как минимум в 2 а лучше в 4 раза

с поиска.

регламенты SQL делаются?

хотя бы это Бешеные тормоза после переноса на MS SQL

(0) >>вчера начались дикие тормоза при формировании любого отчет ...
А до вчера все хорошо работало?

(0) клиент тонкий?
Локально, в терминале работаете или remoteApp?
HDD какой? какая очередь на диск средняя?
Размер базы какой?
Вы не предоставили и половины информации и хотите чтобы вам помогли

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

Обновите статистику SQL

значит нужно узнать, кто чего делал с серверами/программами вчера/сегодня

может злой админ вас за ночью на виртуалку перенес :)

(3) Кроме бэкапов больше ничего не делается. Просто как-то резко стало.
(6) Клиент толстый, стандратная УПП же, работа по обычной сети, не терминал и remoteApp, HDD посмотрю какой, размер базы 24 гига
Какая инфа еще нужна спрашивайте

(10) очередь на диск есть?

http://yandex.ru/search/?lr=213&text=настройка%20регламентов%20SQL%20для%201с

(10) Обновления какие-нибудь ставили (драйвера, платформа и т.д.)? Вообще на сервер что-нибудь устанавливали?

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

(8) статистику обновлю, вечером, когда работать не будут
по идее никто ничего не мог сделать, может железо глючит
Сейчас, кстати лучше ситуация стала, поставил обновляться винду
(11) при включении показателя средняя длина очереди он скаканул до 100, сейчас пики до 40-60 показывает временами

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

Пригласить специалистов еще не предлагали?

(15) 40-60? Очередь? о_0
ничего не перепутали?

хм странно, может с базой что стало, сделал оборотку 20 счета за март, выполнилась за 2,7 сек. Запустил за апрель после 3 минут формирования вырубил программу не дождался.
(18) сбоку на графике разметка по 10 до 100 я по ней сказал, так максимум показывает 5,556 на данный момент.

может диск в рэйде полетел?

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

(19) значит 4-6 у вас очередь. это многовато

попробуй итоги перечситать

(19) в файловой копии такой проблемы нет?

(19) вобщем оперативки 16 а база 24. имхо проблемы отсуда растут. увеличивайте оперативку, как вам сказали еще в (1)

(25) Это еще ни о чем не говорит. Как живут люди у которых базы по 500Гиг. Им и памяти нужно по 500Гиг ставить?

может итоги не пересчитаны?
Или умер один из винтов raid массива

Посмотрите, кто из пользаков грузит сервак - в консоле кластеров параметр "захвачено СУБД". После чего убейте его

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

(26) нет. просто не забываем, что оперативка на серваке нужна не только базе

запустил checkDB, посмотрим будут ли ошибки

(27) Зачем ты повторяешь за мной )))

(30) Статистику, значит, - вечером, а более тяжелый checkDB - сейчас?
Если очередь к дискам - копать туда. Может батарейка на рейде загнулась или обучается.

(32) да я не очень в этом, если статистика не будет сильнее напрягать, сделаю сейчас. Просто checkDB уже пару раз пользовался когда-то, не умирали вроде)

CHECKDB обнаружил 0 ошибок размещения и 0 ошибок согласованности в базе данных

при его выполнении очередь диска почти все время на 100 была

(10) "размер базы 24 гига " -log файл SQL какого размера?

(36) сейчас 500 метров, во время обновлений растет бывает до 3 гиг, я его потом очищаю, после бэкапов.

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

Голосую за мертвый диск в рейде.

(38) Хм. Если на одном месяце, то подозрение на другое падает.

(40) да вот и не пойму, проверил февраль, март, май все за несколько сек выполняется. Тот же отчет за апрель и висит минут 5, а то и больше.

(39) мертвый диск было бы полно дисковых ошибок в событиях (37) http://www.gilev.ru/sqlsize/
попробуй обекапить базу загрузить в пустую SQL и подключить как копию в кластере

(41) Косяк где-то в таблицах. Стоит попытаться перезаписать все движения за апрель по бухрегистру.

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

(42) и на копии запустить ТИИ

сделал обновление индексов с помощью sp_updatestats, не знаю в этом дело или нет, но сейчас апрель нормально сформировался. Потестирую еще, в копии пока перепроводятся доки за апрель, потом тестирование и исправление ошибок там запущу посмотрю, что напишет. Если в копии это не поможет, там сделаю обновление индексов, чтобы уже точно понять в этом дело или нет. Может просто сейчас совпало так.

(0) Я правильно понимаю, "дикие тормоза при формировании любого отчета" на самом деле означает "дикие тормоза при формировании ОСВ", другие отчеты не тормозят?

(47) ну проверял на ОСВ, каюсь))

(48) В стандартной ОСВ в УПП есть проблема, использование "счет в иерархии". При таких конструкциях sql может выбирать неправильный план запроса, и вдруг начинает отчет висеть. После пересчета статистики, индексов проблема может быть снята, но при больших объемах и интенсивном вводе данных большой риск повторного возникновения.
Для локализации, можно проверить, если зависла ОСВ по 20, попробовать ОСВ 20.01.1. Если она не зависнет, то виноват именно "счет в иерархии".

(49) В ERP 2.0, в БП 3.0 уже сначала получают список счетов по иерархии, а в запросе используют Счет В (&Счет).
Так что переходите на новую версию, а не используйте старую рухлядь, для кого вообще 1С старается..

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