Лагает интерфейс 1С на серверной базе PostgreSQL под Windows10
Доброго времени суток!
Лагает может быть громко сказано, подлагивает, подтармаживает, подмерзает. Немного, но не приятно. Пользователь нервничает...
Как выражается:
В форме списка документов чуть-чуть задумывается при переходе в конец или начало списка
При закрытии окна формы несколько мгновений ничего не происходит, а потом форма закрывается (курсора ожидания нет)
ну и т.д.
При этом документы проводятся, тьфу-тьфу, нормально.
клиент 1С х32 8.3.10.2375
сервер 1С х64 8.3.10.2375
pgSQL 9.6.3 от Postgres Pro (настройки conf по рекомендациям мануалов pdSQL, ИТС, Инфостарт и т.д. )
Win 10x64
i5-6500, 32 GB, fake RAID1, система на SSD, базы и логи pgSQL на RAID1
ИБ типовые БП 2.0, 3.0
размеры ИБ не большие, если верить pg_database_size: 3,3GB, 3,1GB
по монитору ресурсов все нормально, на первый взгляд:
доступной памяти > 15Gb
длина очереди дисков <1
правда ЦП всегда в районе 90, и пользуют его два rphost и postgres в основном
может чего-то подкрутить в конфе Possgre?
в сервере 1С ничего не настраивал, все по умолчанию. Может там какие галки поставить? (вроде в последних уже и не надо особо)
Спасибо!
Лагает может быть громко сказано, подлагивает, подтармаживает, подмерзает. Немного, но не приятно. Пользователь нервничает...
Как выражается:
В форме списка документов чуть-чуть задумывается при переходе в конец или начало списка
При закрытии окна формы несколько мгновений ничего не происходит, а потом форма закрывается (курсора ожидания нет)
ну и т.д.
При этом документы проводятся, тьфу-тьфу, нормально.
клиент 1С х32 8.3.10.2375
сервер 1С х64 8.3.10.2375
pgSQL 9.6.3 от Postgres Pro (настройки conf по рекомендациям мануалов pdSQL, ИТС, Инфостарт и т.д. )
Win 10x64
i5-6500, 32 GB, fake RAID1, система на SSD, базы и логи pgSQL на RAID1
ИБ типовые БП 2.0, 3.0
размеры ИБ не большие, если верить pg_database_size: 3,3GB, 3,1GB
по монитору ресурсов все нормально, на первый взгляд:
доступной памяти > 15Gb
длина очереди дисков <1
правда ЦП всегда в районе 90, и пользуют его два rphost и postgres в основном
может чего-то подкрутить в конфе Possgre?
в сервере 1С ничего не настраивал, все по умолчанию. Может там какие галки поставить? (вроде в последних уже и не надо особо)
Спасибо!
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) Я такой скрипт выполняю
SET PGPASSWORD=123456
"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\psql.exe" --dbname BaseName --host 127.0.0.1 --port 5432 --username postgres --command "reindex DATABASE BaseName;"
"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\psql.exe" --dbname BaseName --host 127.0.0.1 --port 5432 --username postgres --command "vacuum full analyze;"
Ну а почитать, гугл/инфостарт, все ищется)
SET PGPASSWORD=123456
"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\psql.exe" --dbname BaseName --host 127.0.0.1 --port 5432 --username postgres --command "reindex DATABASE BaseName;"
"C:\Program Files\PostgreSQL\9.4.2-1.1C\bin\psql.exe" --dbname BaseName --host 127.0.0.1 --port 5432 --username postgres --command "vacuum full analyze;"
Ну а почитать, гугл/инфостарт, все ищется)
(7) максимальная производительность включена, если мы об этом
а расклад вот такой
смущает, что много процессов postgres.exe в состоянии прерван, пока не понимаю... направьте, если есть соображения )
регламентные, конечно есть, но не так, чтобы критично: в кластере видно пару фоновых заданий.
отключу для чистоты эксперимента
надо ли после загрузки из dt выполнять какие-то дополнительные операции на pgSQL?
а расклад вот такой
смущает, что много процессов postgres.exe в состоянии прерван, пока не понимаю... направьте, если есть соображения )
регламентные, конечно есть, но не так, чтобы критично: в кластере видно пару фоновых заданий.
отключу для чистоты эксперимента
надо ли после загрузки из dt выполнять какие-то дополнительные операции на pgSQL?
(9)
Последняя запись.
Можно попробовать обновиться до 2446, посмотреть на ней.
Может какие-то фоновые задания прервались, их сеансы с postgresql не завершились и
процессы остались в состоянии "idle in transaction"
На версии платформы 8.2+PostgreSQL такое когда-то возникало
Последняя запись.
Можно попробовать обновиться до 2446, посмотреть на ней.
Может какие-то фоновые задания прервались, их сеансы с postgresql не завершились и
процессы остались в состоянии "idle in transaction"
На версии платформы 8.2+PostgreSQL такое когда-то возникало
(11) последнюю запись багрепорта я видел, но вроде как не ожидалось "массового запуска и прерывания работы фоновых заданий", может не верно интерпретировал тему, но...
поднял ВМ в том же составе, только postgresql.conf по умолчанию, развернул Бухгалтерию 3.0 (демо) запускаю 1С, диспетчер, монитор ресурсов, ProcessExplore и чего-то я не понимаю...
"прерванные" процессы отображает только Монитор ресурсов, ни Диспетчер задач, ни ProcessExplore их не показывают, кроме того прерванные процессы возникают даже когда сервер 1С не запущен:
только у меня такая картинка? или это нормальное поведение?
поднял ВМ в том же составе, только postgresql.conf по умолчанию, развернул Бухгалтерию 3.0 (демо) запускаю 1С, диспетчер, монитор ресурсов, ProcessExplore и чего-то я не понимаю...
"прерванные" процессы отображает только Монитор ресурсов, ни Диспетчер задач, ни ProcessExplore их не показывают, кроме того прерванные процессы возникают даже когда сервер 1С не запущен:
только у меня такая картинка? или это нормальное поведение?
(12)
Это коварная ошибка, под которую попадает и поиск в динамических списках. При наборе первой же буквы в поле поиска запускается фоновый поиск и если набрать следующую букву до того как появится результат, то предыдущее фоновое задание поиска прерывается и запускается новое. И так на каждую новую букву в этом поле.
но вроде как не ожидалось "массового запуска и прерывания работы фоновых заданий"
Это коварная ошибка, под которую попадает и поиск в динамических списках. При наборе первой же буквы в поле поиска запускается фоновый поиск и если набрать следующую букву до того как появится результат, то предыдущее фоновое задание поиска прерывается и запускается новое. И так на каждую новую букву в этом поле.
(20)
кстати, про default_statistics_target
pgtune рекомендует default_statistics_target = 100
в других источниках видел 400, на ИТС - 4000,
поверил pgtune, сейчас стоит 100, попробую 5000 )
по памяти мы про effective_cache_size говорим? так и есть, прописал 1/3 от RAM
стесняюсь спросить что скрывается за аббревиатурой DWH?
default_statistics_target
кстати, про default_statistics_target
pgtune рекомендует default_statistics_target = 100
в других источниках видел 400, на ИТС - 4000,
поверил pgtune, сейчас стоит 100, попробую 5000 )
по памяти мы про effective_cache_size говорим? так и есть, прописал 1/3 от RAM
стесняюсь спросить что скрывается за аббревиатурой DWH?
(21)
что
Просто все настройки, как на сайте выставьте (кроме стата) и пробуйте. Не забудьте рестарт сервера сделать (или подгрузить настройки). Также нужно иметь ввиду, что на 32-битном сервере память не будет выделена по указанным значениям - нужно использовать 64-битную версию.
(14)
По моим наблюдениям пользователи довольны скоростью работы при индексе, по тесту Вячеслава, выше 35. Причём, если вдруг происходит замена сервера с индексом 60, на сервер с индексом 38-40 - то рядовые пользователи даже разницы не замечают.
получилось прогнать тест. результат 20.58
По моим наблюдениям пользователи довольны скоростью работы при индексе, по тесту Вячеслава, выше 35. Причём, если вдруг происходит замена сервера с индексом 60, на сервер с индексом 38-40 - то рядовые пользователи даже разницы не замечают.
(14) по тесту надо начать с диагностики БИОСа
выключить там C-States, C1E
включить турбобуст
включить в биосе максимальную производительность в электропитании, управление электропитанием отдать БИОСу
затем снова сделайте тест
если результаты не подымутся, напишите модель вашего процессора
выключить там C-States, C1E
включить турбобуст
включить в биосе максимальную производительность в электропитании, управление электропитанием отдать БИОСу
затем снова сделайте тест
если результаты не подымутся, напишите модель вашего процессора
(28) до BIOSa пока не доберусь (
а конфигурация вот такая:
клиент 1С х32 8.3.10.2375
сервер 1С х64 8.3.10.2375
pgSQL x64 9.6.3 от Postgres Pro (настройки conf по рекомендациям мануалов pgSQL, ИТС, Инфостарт и т.д. )
Win 10x64
i5-6500, 32 GB, fake RAID1, система на SSD, базы и логи pgSQL на RAID1
а конфигурация вот такая:
клиент 1С х32 8.3.10.2375
сервер 1С х64 8.3.10.2375
pgSQL x64 9.6.3 от Postgres Pro (настройки conf по рекомендациям мануалов pgSQL, ИТС, Инфостарт и т.д. )
Win 10x64
i5-6500, 32 GB, fake RAID1, система на SSD, базы и логи pgSQL на RAID1
(31)
Т.к. проц Ваш работает на частоте 3200 (в бусте 3600), то уровень производительности должен быть где-то в районе 40-ка попугаев по данному тесту. Вы правда включили схему питания "Высокая производительность"? А то на моем AMD Ryzen 5 1600 (3200 МГц) производительность в районе 38 (Linux Ubuntu 17.04, постгрес 9.6).
По поводу С-State, то это такая интересная штука, которая в последнее время владельцам AMD Ryzen стала знакома как мать родная ))) Суть в том, что процессор управляется BIOS или OS, при этом в соответствии со схемой производительности ему дается несколько вариантов вольтажа, частоты и прочих характеристик. В интеловских процах частоты, обычно, в лесенке С-State задаются от 800МГц до частоты с бустом, но при этом бустится только одно ядро (хотя с точки зрения диагностических утилит это не так), остальные не превышают максимальной частоты процессора без буста (в Вашем случае - 3200). При загрузке одного из ядер происходит повышение его частоты (не сразу, а шагами). В итоге, если схема производительности стоит обычная (сбалансированная), то львиную долю времени ядра работают на частоте 800МГц, а в моменты их загрузки частота ядер повышается системой до 3600 (в Вашем случае, если в БИОС включен турбобуст). Но т.к. ядру нужно время, чтобы повысить частоту до максимума, то, в среднем, частота у него находится в процессе прохождения теста где-то на середине. Почему? Потому, что 1С - это клиент-серверное приложение. Сначала сервер интерпретирует язык 1С, формирует запросы к SQL-серверу, передает их туда, а потом отдыхает, а в работу включается SQL, который получает данные и возвращает их 1С. Т.е. они постоянно занимаются этаким пинг-понгом. В итоге половину времени простаивает 1С, вторую половину времени простаивает SQL. Поэтому частота ядер, на которых работает 1С и SQL постоянно то повышается, то снижается. Чтобы этого не происходило, достаточно включить эту самую схему питания "Высокая производительность".
в мониторе ресурсов процессор > 100%
Это говорит о том, что турбобуст включен. Но на картинке из (9) 102% - это не особо буст. У меня на I7 (рабочем ноуте, 2400/3000) больше 120% показывает. При этом тест Гилева тоже 20 показывает, но 1С и постгрес находятся на виртуалке (VirtualBOX) с Убунту сервер (16.04). На домашнем ноуте (i7/2400-3000) на хосте убунту десктоп 17.04, тест показывает 26-27 (это со схемой питания performance, без нее - 14-16).
Т.к. проц Ваш работает на частоте 3200 (в бусте 3600), то уровень производительности должен быть где-то в районе 40-ка попугаев по данному тесту. Вы правда включили схему питания "Высокая производительность"? А то на моем AMD Ryzen 5 1600 (3200 МГц) производительность в районе 38 (Linux Ubuntu 17.04, постгрес 9.6).
По поводу С-State, то это такая интересная штука, которая в последнее время владельцам AMD Ryzen стала знакома как мать родная ))) Суть в том, что процессор управляется BIOS или OS, при этом в соответствии со схемой производительности ему дается несколько вариантов вольтажа, частоты и прочих характеристик. В интеловских процах частоты, обычно, в лесенке С-State задаются от 800МГц до частоты с бустом, но при этом бустится только одно ядро (хотя с точки зрения диагностических утилит это не так), остальные не превышают максимальной частоты процессора без буста (в Вашем случае - 3200). При загрузке одного из ядер происходит повышение его частоты (не сразу, а шагами). В итоге, если схема производительности стоит обычная (сбалансированная), то львиную долю времени ядра работают на частоте 800МГц, а в моменты их загрузки частота ядер повышается системой до 3600 (в Вашем случае, если в БИОС включен турбобуст). Но т.к. ядру нужно время, чтобы повысить частоту до максимума, то, в среднем, частота у него находится в процессе прохождения теста где-то на середине. Почему? Потому, что 1С - это клиент-серверное приложение. Сначала сервер интерпретирует язык 1С, формирует запросы к SQL-серверу, передает их туда, а потом отдыхает, а в работу включается SQL, который получает данные и возвращает их 1С. Т.е. они постоянно занимаются этаким пинг-понгом. В итоге половину времени простаивает 1С, вторую половину времени простаивает SQL. Поэтому частота ядер, на которых работает 1С и SQL постоянно то повышается, то снижается. Чтобы этого не происходило, достаточно включить эту самую схему питания "Высокая производительность".
(36) это последняя мулька Windows 10 версии 1703
Второе изменение в настройках схемы электропитания связано со скоростью работы процессора. Теперь, развернув раздел «Управление питанием процессора», вы можете указать максимальную частоту процессора.
Значение устанавливается в мегагерцах. К примеру, если вы укажите 1500 МГц, тактовая частота процессора всегда будет поддерживаться ниже 1.5 ГГц, даже если выполняемым задачам требуется больше мощности. Убедиться в корректности работы ограничителя скорости процессора можно в диспетчере задач на вкладке «Производительность».
подробнее
ИМХО, если 0, то не ограничивать
Второе изменение в настройках схемы электропитания связано со скоростью работы процессора. Теперь, развернув раздел «Управление питанием процессора», вы можете указать максимальную частоту процессора.
Значение устанавливается в мегагерцах. К примеру, если вы укажите 1500 МГц, тактовая частота процессора всегда будет поддерживаться ниже 1.5 ГГц, даже если выполняемым задачам требуется больше мощности. Убедиться в корректности работы ограничителя скорости процессора можно в диспетчере задач на вкладке «Производительность».
ИМХО, если 0, то не ограничивать
вроде бы разобрался с "прерванными" процессами, это не "idle in transaction", это дочерние процессы которые инициируют plantuner, online_analyze и им подобные, а pg форкает потомка при каждом коннекте, они быстренько отрабатывают и закрываются, а монитор windows отображает по другому
на скриншоте два "прерванных" процесса в разное время
а процессор по прежнему под 100%
мог я его так загнать неправильным postgresql.conf?
на скриншоте два "прерванных" процесса в разное время
а процессор по прежнему под 100%
мог я его так загнать неправильным postgresql.conf?
настройки сейчас как на картинке
память Total RAM указал 24GB из тех соображений, что всего 32, минус треть на Window + 1C, остальные 24 - доступны pg
плюс рекомендации с других источников
fsync on
synchronous_commit off
autovacuum on
autovacuum_max_workers 4
autovacuum_naptime 60s
bgwriter_delay 20ms
bgwriter_lru_multiplier 4
bgwriter_lru_maxpages 400
effective_io_concurrency 2
random_page_cost 2
row_security off
standard_conforming_strings off
escape_string_warning off
max_locks_per_transaction 256
max_connections 100
online_analyze.enaible on
все х64 - Win, 1C, pgSQL
попробую увеличить параметр как рекомендуете, только в не рабочее время, понаблюдаю )
память Total RAM указал 24GB из тех соображений, что всего 32, минус треть на Window + 1C, остальные 24 - доступны pg
плюс рекомендации с других источников
fsync on
synchronous_commit off
autovacuum on
autovacuum_max_workers 4
autovacuum_naptime 60s
bgwriter_delay 20ms
bgwriter_lru_multiplier 4
bgwriter_lru_maxpages 400
effective_io_concurrency 2
random_page_cost 2
row_security off
standard_conforming_strings off
escape_string_warning off
max_locks_per_transaction 256
max_connections 100
online_analyze.enaible on
все х64 - Win, 1C, pgSQL
попробую увеличить параметр как рекомендуете, только в не рабочее время, понаблюдаю )
(25) Попробуйте для теста
fsync = off, full_page_writes = off и online_analyze.enable=off
Отсюда
Включенный online_analyze уменьшает результат теста процентов на 20.
fsync = off, full_page_writes = off и online_analyze.enable=off
PostgreSQL после каждого завершения пишущей транзакции сбрасывает данные из файлового кэша ОС на диск. С одной стороны, это гарантирует что данные на диске всегда в актуальном состоянии, с другой при большом количестве транзакций падает производительность. Полностью отключить fsync можно, указав
fsync = off
full_page_writes = off
Делать это можно только в случае если вы на 100% доверяете оборудованию и ИБП (источнику бесперебойного питания). Иначе в случае аварийного завершения системы есть риск получить разрушенную БД. И в любом варианте не помешает так же RAID-контроллер с батарейкой для питания памяти недозаписанных данных.
fsync = off
full_page_writes = off
Делать это можно только в случае если вы на 100% доверяете оборудованию и ИБП (источнику бесперебойного питания). Иначе в случае аварийного завершения системы есть риск получить разрушенную БД. И в любом варианте не помешает так же RAID-контроллер с батарейкой для питания памяти недозаписанных данных.
Отсюда
Включенный online_analyze уменьшает результат теста процентов на 20.
Кстати, еще раз прочитал название темы. Так вот, лаги интерфейса (управляемого) - это на столько обычно, что никто уже особого внимания не обращает. Такое поведение характерно и для MS SQL, и для PgSQL, и даже для файловой (не говоря уже об оракле и IBM DB2). Тут проблема не в СУБД, а в сети, клиентских машинах, положении звезд, ... Вот на практике видел решение (допил бухни 3.0), в котором обычная (абсолютно стандартная) ОСВ формируется хрен знает сколько времени, хотя там MS SQL, специальное решение от какой-то всем известной конторы, которая запиливает прослойку между 1С и SQL с чуть ли не ручной оптимизацией запросов суперэкспертами по SQL (не говоря уже об экспертах по тех.вопросам 1C). Да, интерфейс первые минут пять вообще живенький (но и железо там ОГОГО!!!), но это только первые пять минут - потом периодически фризы.
(33)
раньше как-то не замечал или внимания не обращал )
в пользовательский интерфейс особо то не смотрю. понажимаю кнопочки, понаблюдаю, как время будет.
остальные базы файловые или MS SQL и, насколько помню, пользователь обычно ждет, пока 1с данные покажет и смотрит на курсорчик выполнения, и не нервничает, и не жамкает бестолково по тем же кнопочкам ))))
а тут новые практики - PostgesSQL, посмотрел более пристально - родилась тема на форуме )
лаги интерфейса (управляемого) - это на столько обычно, что никто уже особого внимания не обращает
раньше как-то не замечал или внимания не обращал )
в пользовательский интерфейс особо то не смотрю. понажимаю кнопочки, понаблюдаю, как время будет.
остальные базы файловые или MS SQL и, насколько помню, пользователь обычно ждет, пока 1с данные покажет и смотрит на курсорчик выполнения, и не нервничает, и не жамкает бестолково по тем же кнопочкам ))))
а тут новые практики - PostgesSQL, посмотрел более пристально - родилась тема на форуме )
Внимание! Тема сдана в архив
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот