|
Второй и последующие разы проводит быстрее. | ☑ | ||
---|---|---|---|---|
0
prad2002
16.07.15
✎
10:52
|
Доброго всем времени суток!
Ситуация следующая: имеется 1С8.2 УТ 10.3, крутится на SQL, база 20 гиг. При первом проведении документа (т.е. документы уже есть в базе, просто перепровожу) время проведения рандомно колеблется от 10 до 90 секунд, выявить закономерность не удалось, тут скорей всего каким-то образом влияют фазы луны и взаимное расположение планет. При повторном перепроведении этого же документа время проведения редко бывает выше 1 сек. В базе пользователей нет, ковыряю один. По 1с-ному замеру производительности затуп всегда на строке записи по регистрам Движения.Записать(). Если зайти в другой док. поступления и перепровести его - та же картина. в первый раз проводится крайне долго, во второй и последующие на порядок быстрее. Подскажите в какую сторону копать? |
|||
1
Галахад
гуру
16.07.15
✎
10:53
|
В кэше пусто, а потом густо.
|
|||
2
Strogg
16.07.15
✎
10:55
|
(1) ++.
|
|||
3
prad2002
16.07.15
✎
10:57
|
(1) Научиться с этим жить или можно как-то побороть?
|
|||
4
Маратыч
16.07.15
✎
10:58
|
(3) Для начала посмотри в сторону производительности скуля.
|
|||
5
patria0muerte
16.07.15
✎
10:59
|
К слову, в конфигурациях типа УТ 11 - такая штука еще может быть не только из за кэша, т.к. там, в некоторых доках, контрольные проверки (типа остатков и прочее) выполняются только если были изменения в движениях. Соответственно первый раз пройдут все контроли, при провторном проведении - их не будет..
|
|||
6
CHerypga
16.07.15
✎
11:00
|
(0) вполне возможно что скулю не хватает выделенной оперативы, или же вполне возможно что настроен еженочный перезапуск службы скуля и на момент первого проведения в оперативу он еще ничего не подкачал
|
|||
7
Маратыч
16.07.15
✎
11:01
|
(6) Кстати, да, ежедневные ребуты сервера БД - зло.
|
|||
8
prad2002
16.07.15
✎
11:03
|
(6) тоже есть такая мысля...
на весь скуль выделено 9гиг, при этом на нем крутиться несколько продакшн баз (одна основная на 20г и несколько по 1,5 гигов) и несколько тестовых копий базы на 20г. |
|||
9
prad2002
16.07.15
✎
11:04
|
но тогда закономерный вопрос: как в таком случае у людей работают базы на 200-500 гиг?
|
|||
10
Маратыч
16.07.15
✎
11:05
|
(9) У базы на 200-500 Гб за десяток лет активно задействуемых таблиц - процентов десять, остальное архивные данные, к которым обращение раз в пятилетку происходит.
|
|||
11
SeraFim
16.07.15
✎
11:08
|
>> При повторном перепроведении
это еще раз нажать кнопочку "Провести"? Или все же Отменить проведение и снова провести? |
|||
12
prad2002
16.07.15
✎
11:10
|
Тогда вопрос:
если запилить мелкую копию продакшн, в которой будет 10 документов из рабочей и будет она весить метров 200, выделить под неё отдельный инстанс SQL так, чтобы она полностью легла в оперативу, по логике тогда док. при любом проведении должен проводиться за примерно одинаковое время. Или я не прав? |
|||
13
prad2002
16.07.15
✎
11:11
|
(11)
просто повторно тисну кнопку "Провести" |
|||
14
Гёдза
16.07.15
✎
11:11
|
повторная запись неизмененного набора ничего не делает
|
|||
15
Гёдза
16.07.15
✎
11:12
|
(7) а сервера 1С - добро
|
|||
16
prad2002
16.07.15
✎
11:13
|
(14)
что физически происходит на субд при первом и втором нажатии "провести"? |
|||
17
SeraFim
16.07.15
✎
11:20
|
Тут еще и настройки влияют. В частности, что именно написано в свойствах конкретного документа:
УдалениеДвижений: "Удалять автоматически при отмене проведения", "Удалять автоматически" или "Не удалять автоматически" ЗаписьДвиженийПриПроведении: "Записывать модифицированные" или "Записывать выбранные" Ну и вообще, в коде может быть все что угодно прописано) |
|||
18
Маратыч
16.07.15
✎
11:21
|
(12) Не совсем, все-таки кэш тоже участвует. Но по времени уже сравнимо будет.
|
|||
19
BuHu
16.07.15
✎
11:28
|
(16) при первом - добавление записей в таблицы , во втором - апдейт этих записей .
|
|||
20
prad2002
16.07.15
✎
11:37
|
(19) имел ввиду при перепроведении. Когда открываешь проведенный документ, в первый раз тиснешь "Провести" - можно сходить покурить или на обед, второй раз тот же документ - меньше секунды. Открываешь другой проведенный документ - та же картина.
(17)тестил на разных доках и с разными настройками свойств дока. Например, в доке реализации дольше всего идет очистка движений, причем опять же только в при первом перепроведении, свойства в нем типовые. В доке поступления немного перепилено проведение, проводит он все движения скопом строкой Движения.Записать(), свойство дока при этом http://prntscr.com/7tau8n. И в том и в том случае затупы именно на строках записи-удаления движений. Причем затупы только при первом нажатии "Провести" уже проведенного документа. |
|||
21
H A D G E H O G s
16.07.15
✎
11:50
|
(20) Регламенты на sql ?
|
|||
22
Гёдза
16.07.15
✎
11:51
|
(19) нет никакого апдейта записей регистров
|
|||
23
Маратыч
16.07.15
✎
11:52
|
(22) Удаляет и снова пишет же, да?
|
|||
24
Гёдза
16.07.15
✎
11:54
|
(23) да, но 1с говорит, что тот же самый набор 2 раз не пишется
|
|||
25
prad2002
16.07.15
✎
12:00
|
(21)каждую ночь обновляется статистика, дефрагментация индексов.
итоги в 1с актуальные |
|||
26
prad2002
16.07.15
✎
12:08
|
У админов имеются еще файлики мониторинга загрузки памяти, дисков, проца на серверах. Поковыряю ка я их :)
|
|||
27
prad2002
16.07.15
✎
12:40
|
(1) (21)
Еще одно подозрение - сначала пусто потом густо в кэше плана запроса. Если админы неправильно настроили регламенты на сиквеле, то тогда те доки, которые сегодня со второго раза проводятся быстро, завтра опять в первый раз будут проводиться медленно. Это смогу проверить только завтра |
|||
28
hhhh
16.07.15
✎
13:37
|
(27) с самим запросом разберитесь. Почему работает медленно.
|
|||
29
ssh-2013
16.07.15
✎
15:58
|
(25) Частое обновление всей статистики порой вредит. Заново запросы компилируется в кэш потом. Можно настроить выборочные обновление
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |