Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Скорость проведения документов  (Прочитано 5170 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Radistka
Помогающий

ru
Offline Offline
Пол: Женский

« : 29-05-2013 02:58 » 

SQL 2008 R2
1С 8.1.15.14
Самописка - 25Гб
комплексная 130 Гб
скриншот характеристик сервера во вложении

ну медленно проводились документы, но жить можно было. при 3 активных операторах реализация в 500строк за 3,5 минуты в комплексной проводилась. мы нагоняем учёт, перепроводим документы за прошлые месяцы. и стали замечать что на перепроведение тратится всё больше времени. раньше месяц перепроводился впринципе за выходные, а тут начали март перепроводить - за ночь 2 дня всего обрабатывает. думали что объёмы увеличились, но оно как бы не настолько. на том же серваке лежит ещё одна база, самописка, таблиц - копейки. один мощный справочник(порядка миллиона элементов в иерархии). стала замечать, что при добавлении хотя бы одного условия в запрос по этому справочнику, время запроса увеличивается в десяток раз, если с консоли выборку гнать, а если тот же самый запрос написать в обработке, то выполняется он...в общем я не дождалась.

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

* Безымянный.png (12.85 Кб - загружено 111 раз.)
« Последнее редактирование: 29-05-2013 04:38 от Radistka » Записан
Dest
Опытный

ru
Offline Offline

« Ответ #1 : 29-05-2013 04:54 » 

Что касается той базы где реализация проводится. Делайте замер производительности и смотрите на чем тормозит.
А там, где мегосправочник, тоже запрос нужно смотреть. Может не оптимальный.

Обновление статистики делали?
Use NameDB
exec sys.sp_updatestats

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


Записан
Radistka
Помогающий

ru
Offline Offline
Пол: Женский

« Ответ #2 : 29-05-2013 07:54 » 

Что касается той базы где реализация проводится. Делайте замер производительности и смотрите на чем тормозит.
на всём том, что касается выборок в запросах.. т.е. я подозреваю именно то в каком состоянии база находится.. только как это состояние определить и поправить Здесь была моя ладья...

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

Код: (1C v8)
 |    ВЫБРАТЬ
|               ТрансфертТаблица.Консультант КАК Консультант
|       ИЗ
|               Документ.Трансферт.Таблица КАК ТрансфертТаблица
|       ГДЕ
|               ТрансфертТаблица.Ссылка.Дата < &Дата
|      
|       СГРУППИРОВАТЬ ПО
|               ТрансфертТаблица.Консультант

Обновление статистики делали?
Use NameDB
exec sys.sp_updatestats
можете  по этому моменту подробнее? я как бы понимаю, что это относится к скулю и может даже найду, где это юзануть, но что это за команда и что она даёт? чем поможет базе?
Записан
Radistka
Помогающий

ru
Offline Offline
Пол: Женский

« Ответ #3 : 29-05-2013 08:36 » 

мм.. нарыла в интернетах про статистику, щас пошукаю, как админ с обеда вернётся, есть ли у нас на этих базах нечто подобное.

UPD  обновление статистики делается каждую ночь. на это дело уходит 3-4 часа, так что чаще - не вариант..
« Последнее редактирование: 29-05-2013 09:47 от Radistka » Записан
Dest
Опытный

ru
Offline Offline

« Ответ #4 : 29-05-2013 22:13 » 

3-4 часа на обновление статистики Не понялНе понял??!!!!!!!!!! Не может быть...
У нас база примерно 170 Гб, мы делаем не чаще раза в неделю, процесс занимает 15-20 минут не дольше.  Меня одолевают смутные сомнения
Я читал, что слишком часто делать обновление статистики тоже не желательно. Мы каждый день не делаем.

Записан
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 30-05-2013 05:11 » 

Скорей всего здесь серверные проблемы.

Попробовать бы на другой конфигурации система/железо.

Проблемы могут возникать как на i/o - дисках, так и на наличии lock'ов таблиц

Было бы неплохо посмотреть
1. план выполнения запросов
2. Проверить время сбора статистики после перезапуска сервера
3. Проверить наличие lock
4. Проверить наличие db-link, возможно, что (это ведь самописка) идет какая-то синхронизация с внешними базами (возможно, несуществующими). Поизучать вопрос логирования slow запросов
5. Проверка железа и качества i/o - диски, сеть.
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Radistka
Помогающий

ru
Offline Offline
Пол: Женский

« Ответ #6 : 30-05-2013 09:54 » 

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

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

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

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #7 : 30-05-2013 10:05 » 

С переиндексацией понятно...

медленные запросы смотрели?
lock смотрели

подвисшие запросы? Может они накапливаются?

Я люблю рассказывать когда сделали на оракле курсор for update для сотни тысяч записей
Т.е. на тестовом сервере все "летало", а на боевом - падало в ступор

Кроме того, нужно проанализировать циклы запросов, возможно, что запросы повторяются в цикле, подумать о кешировании, возможно ли увеличить объем кеша для запросов, может постоянно своп идет?
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
Radistka
Помогающий

ru
Offline Offline
Пол: Женский

« Ответ #8 : 30-05-2013 10:21 » 

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

lock - что это? к чему относится?

"подвисшие запросы? Может они накапливаются?" - это как? в каком месте они подвисают, как это определить и изза чего это случается?

"подумать о кешировании, возможно ли увеличить объем кеша для запросов, может постоянно своп идет?"- место увеличивать нам есть куда, а вот где увеличивать и как понять что оно надо? кеш сам чистится? этот кеш относится к скулю или 1Ске?))
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines