Вход | Регистрация


1С:Предприятие :: 1С:Предприятие 8 общая

Производительность сервера 1С (postgre)

Производительность сервера 1С (postgre)
Я
   live in sky dreams
 
01.10.17 - 17:11
Не могу взять в толк в чем причина просадки производительности.

Работал себе сервер, работал.
Обслуживал 4 базы.
1) УТ 10.3 слегка допиленная
2) БП 3.0 без допилок
3) УТ 10.3 - для разработки
4) БП 3.0 - тренировачная для бухгалтеров без допилок

В один момент сервер 1С стал тупить.
Конкретно при работе в УТ.

Запуск сессии.
проведение первого документа в свежей сессии - 25 секунд!!!!
повторное проведение его же - около 0,8 сек

Проведение другого документа - около 3,1 секунд. Повторное проведение его же 0,4 - 0,8 сек.

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

Модуль проведения (записи в регистры) не модифицирован.
ПередЗаписью есть некоторые доработки, но по замерам производительности, они не всаживают.
А всаживает типовой код.
Как пример: http://prntscr.com/grwsy4

Реиндексация, пересчет итогов и прочее проводится по расписанию.
ТиИ делал.

Что еще можно посмотреть, что может влиять на скорость?
 
 
   live in sky dreams
 
1 - 01.10.17 - 17:12
up:

Пересадил базу временно на другой серв, в роли сервера БД MS SQL - ситуация аналогичная.

Делаю вывод, что проблема в самой БД.
Попробую выгрузить в файловую и прогнать Chdbfl
   live in sky dreams
 
2 - 01.10.17 - 17:20
Пока делается проверка:
Размер базы в dt до 400 Mb
Провожу тесты сейчас (кроме меня грузит сервер 1 бух, больше никого)

Загрузка сервера БД (+1С сервер): http://prntscr.com/grwy5e
   rphosts
 
3 - 01.10.17 - 17:26
виртуальный сервер БД под например дебианом?

>Реиндексация, пересчет итогов и прочее проводится по расписанию.
ТиИ делал.

ты не на форуме телепатов, поэтому уж разъясни в "и прочее" входит vacuum analize?

и да, что там с дисками и ты уверен, что твой postgre.conf анстроен адекватно?
   live in sky dreams
 
4 - 01.10.17 - 17:44
(3)
>виртуальный сервер БД под например дебианом?
нет, реальный серв под дебианом

> входит vacuum analize?
конечно входит

> и да, что там с дисками
массив зеркало под систему, софтовый
ssd под бд

> postgre.conf анстроен адекватно?
вроде как...
   live in sky dreams
 
5 - 01.10.17 - 17:47
chdbfl ничего не обнаружил
   rphosts
 
6 - 01.10.17 - 18:00
>> и да, что там с дисками 
массив зеркало под систему, софтовый 
ssd под бд 

длина очереди какова?
   rphosts
 
7 - 01.10.17 - 18:13
если выгрузить - загрузить скорость выполнения нормализуется?
   rphosts
 
8 - 01.10.17 - 18:13
в смысле через dt
   rphosts
 
9 - 01.10.17 - 18:14
только бэкап не забудь сделать
   live in sky dreams
 
10 - 01.10.17 - 18:16
(6) под это мониторинга с логированием пока не настроил.. Статистика не собрана :(
В момент проведения документа картина такая: http://prntscr.com/grxj9x

(7) неа, ситуация не меняется.
Пробовал и перезагружать конфу и в новую БД засовывать выгрузку, все без толку

В развернутом виде (CD) база под 4 гига... Фигасе из 400 Мб разархивировалось
 
 Рекламное место пустует
   rphosts
 
11 - 01.10.17 - 18:23
ну тогда собирать инфу логами ТЖ и через замер производительности.

>ПередЗаписью есть некоторые доработки, 

а там никаких подписок не навешано? они ведь в замер не попадут!
   live in sky dreams
 
12 - 01.10.17 - 21:27
(11) эээ.. навешано..
То, что подписки не попадают в замер для меня новость..
   Ranger_83
 
13 - 01.10.17 - 21:30
(0) дефрагментацию дисков смотрел?
   Злопчинский
 
14 - 01.10.17 - 22:00
(10) это норм, сжатая база не более 10 процентов от исходной
   ansh15
 
15 - 01.10.17 - 22:52
(10) Запусти atop и смотри утилизацию дисков.
   live in sky dreams
 
16 - 01.10.17 - 23:08
(11) подписки отрабатывают за 0.2 сек, не они вешают
(13) дефрагментация? для Ext3?

(15)http://prntscr.com/gs1atu
куда тут смотреть?
   Fram
 
17 - 01.10.17 - 23:31
Судя по скрину из (0) что то не так со структурой конфы. Я так понимаю очистиь все кэши в купе с реструктуризацией пробовал ?
   ansh15
 
18 - 01.10.17 - 23:42
(16) В первой колонке DSK, в третьей - busy в процентах.
>>Проведение другого документа - около 3,1 секунд. Повторное проведение его же 0,4 - 0,8 сек.
Это сильно критично? Если бы оно по полторы минуты занимало...
   live in sky dreams
 
19 - 02.10.17 - 07:24
(17) Кеш чистил, базу в dt вгружал и на другой вообще сервак загружал. Положительного эффекта не дало.
Реструктуризацию не пробовал. Сейчас попробую изменить что-нибудь в конфе и пересохранить. Пока в базе никого..

(18) По работе пользователей не особо. По тому, что "с базой что-то не так" мне лично критично как минимум разобраться что происходит.
Хотя... при перепроведении доков пользователи жалуются на "тупняки адинэс"
   Dotoshin
 
20 - 02.10.17 - 08:32
(19) Тупняк во всех базах или в какой-то конкретной?
   live in sky dreams
 
21 - 02.10.17 - 08:33
(20) только в УТ

сделал реструктуризацию... субъективно вроде бы как быстрее стала немного работать.

Жду пользователей протестить под полной нагрузкой и собрать "мнения"
   Fram
 
22 - 02.10.17 - 08:38
(21) у тебя конкретные симптомы описаны в (0). не можешь, что ли, еще раз с секундомером "провести первого документа в свежей сессии" ?
   live in sky dreams
 
23 - 02.10.17 - 08:45
(22) могу. Просто сейчас свертка базы идет и выгрузка 2 баз в dt

Боюсь результаты под такого рода нагрузкой могут смазаться..
   Dotoshin
 
24 - 02.10.17 - 08:50
(23) Ну может у тебя и тупняки были на фоне какой-нить нагрузки?
   Fram
 
25 - 02.10.17 - 09:02
(23) ясно.. ну, подождем )
   тарам пам пам
 
26 - 02.10.17 - 09:11
Отладка случаем на сервере не включена? Тупняки при первом обращении к метаданным могут быть из-за отладки, т. к. при этом режиме кэш метаданных не загружается автоматически при старте службы.
   live in sky dreams
 
27 - 02.10.17 - 09:16
(24) неа, специально проверял досконально все активные сеансы.

(26) включена.....
   тарам пам пам
 
28 - 02.10.17 - 09:27
(27) Тогда пробуй отключать. Если поможет - надо делать две службы сервера 1с - одну рабочую, вторую - для разработки/отладки.
   live in sky dreams
 
29 - 02.10.17 - 10:36
(24)(25)
Ну.. проведение документа при активной нагрузке на сервере в 12 сеансов - чуть более секунды. Уже приемлемо.

Уже поздняк, все работают, как выйдут - отключу дебагинг, рестартну сервер и проверю результат
   maks-petrov-62
 
30 - 02.10.17 - 10:46
(0) План электропитания какой?
   live in sky dreams
 
31 - 02.10.17 - 10:54
(30) не настраивал, по дефолту "из коробки"
   maks-petrov-62
 
32 - 02.10.17 - 11:00
(31) По дефолту там вроде оптимизированный, нужно поставить "Высокая производительность", в биосе и в винде.
   live in sky dreams
 
33 - 02.10.17 - 11:01
(32) в роли серверной ОС - Debian :)
 
 
   maks-petrov-62
 
34 - 02.10.17 - 11:01
(33) Ты же говоришь что на MS SQL то же самое.
   live in sky dreams
 
35 - 02.10.17 - 11:04
(34) конкретно с этой базой да, остальные хорошо работают
План там - конечно максимальная производительность
   maks-petrov-62
 
36 - 02.10.17 - 11:08
(35) Так хорошо работают или "Пересадил базу временно на другой серв, в роли сервера БД MS SQL - ситуация аналогичная. "?
   live in sky dreams
 
37 - 02.10.17 - 11:38
(36) Все базы кроме проблемной на том сервере хорошо работают

Ситуация аналогичная была только с проблемной базой
   Dmitrii
 
38 - 02.10.17 - 11:56
А не создал ли кто-нибудь случайно документик какой-нибудь далёкой-предалёкой будущей датой - например 3017 или 2071 годом?
   live in sky dreams
 
39 - 02.10.17 - 16:44
(38) неа
   PRO100 NigGaZ
 
40 - 02.10.17 - 18:01
(0) Такая же фигня при программном проведении документа. При создании реализации на основании заказа клиента документ создается 25-100 сек в зависимости от количества строк в будущей реализации
В ТЖ творится ад, выполняется 20 тыс запросов вида (по регистру заказы клиентов)
UPDATE AccumRgT16283 SET Fld16279 = Fld16279 + -1, Fld16280 = Fld16280 + -1, Fld16281 = Fld16281 + -11374.35 WHERE Period = DATETIME(2017,8,1) AND и тд по измерениям условия
где DATETIME(хххх,х,1) меняется от (1,1,1) и до текущей
пока не разобрался в чем дело
   Fram
 
41 - 02.10.17 - 18:47
Так проблема ушла или нет после ресруктуризации?


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует