Доброго, попытаюсь сформулировать вопрос
клиент 1С х32 8.3.10.2639
сервер 1С х64 8.3.10.2639
pgSQL 9.6.3 х64 от Postgres Pro (настройки conf по рекомендациям мануалов pgSQL, ИТС, Инфостарт и т.д. )
Win 10x64
i5-6500, 32 GB, fake RAID1, система на SSD, базы и логи pgSQL на RAID1
типовая, практически пустая база 1С:Бухгалтерия 3.0.55.16
заметил, что rphost ощутимо грузит процессор при выполнении регламентного задания в базе данных на pgSQL. К примеру, можно наблюдать рост до 15-30% по счетчику загруженности процессора.
причем большой разницы при разных заданиях нет, что при обновлении новостей, что при обновлении индекса ПДД.
при тех же условиях, но на MS SQL такого напряга процессора нет.
это нормальное поведение или что-то можно подкрутить в postgresql.conf?
спасибо!
клиент 1С х32 8.3.10.2639
сервер 1С х64 8.3.10.2639
pgSQL 9.6.3 х64 от Postgres Pro (настройки conf по рекомендациям мануалов pgSQL, ИТС, Инфостарт и т.д. )
Win 10x64
i5-6500, 32 GB, fake RAID1, система на SSD, базы и логи pgSQL на RAID1
типовая, практически пустая база 1С:Бухгалтерия 3.0.55.16
заметил, что rphost ощутимо грузит процессор при выполнении регламентного задания в базе данных на pgSQL. К примеру, можно наблюдать рост до 15-30% по счетчику загруженности процессора.
причем большой разницы при разных заданиях нет, что при обновлении новостей, что при обновлении индекса ПДД.
при тех же условиях, но на MS SQL такого напряга процессора нет.
это нормальное поведение или что-то можно подкрутить в postgresql.conf?
спасибо!
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(5) я понимаю, что 1С, а не "слоник" )
и не говорю, что загрузка процессора это плохо, но в данном случае процессора откровенно мало )
развернул по просьбе пользователей 10 новых баз типовой бухгалтерии 3.0, базы практически пустые, только заполняются и готовятся к учету с нового года.
регламентные задания остались включенными с настройками по умолчанию, а там обновление индекса ППД каждые 60 сек.
обратил внимание на напряг процессора в не рабочее время. пригляделся - rphost рулит регзаданиями, и так старается, что в частенько отъедает все 100% процессора )))
а в рабочее время, естественно, пользователя забижает (
у меня только один сервер со "слоником", и совсем недавно. пока ничего плохого сказать не могу (тьфу, тьфу, тьфу), но опыта маловато, терзают смутные сомнения, а сомнения - вопросы ;)
справедливости ради надо сказать, что регламентное задание в базе под MS SQL тоже грузит процессор, поменьше правда, но тут i7-7600. Не справедливо сравнивать.
надо будет сделать две одинаковых виртуалки и посмотреть пристальней ;)
просто из научного интереса.
теоретически СУБД тут ни при чем.
и не говорю, что загрузка процессора это плохо, но в данном случае процессора откровенно мало )
развернул по просьбе пользователей 10 новых баз типовой бухгалтерии 3.0, базы практически пустые, только заполняются и готовятся к учету с нового года.
регламентные задания остались включенными с настройками по умолчанию, а там обновление индекса ППД каждые 60 сек.
обратил внимание на напряг процессора в не рабочее время. пригляделся - rphost рулит регзаданиями, и так старается, что в частенько отъедает все 100% процессора )))
а в рабочее время, естественно, пользователя забижает (
у меня только один сервер со "слоником", и совсем недавно. пока ничего плохого сказать не могу (тьфу, тьфу, тьфу), но опыта маловато, терзают смутные сомнения, а сомнения - вопросы ;)
справедливости ради надо сказать, что регламентное задание в базе под MS SQL тоже грузит процессор, поменьше правда, но тут i7-7600. Не справедливо сравнивать.
надо будет сделать две одинаковых виртуалки и посмотреть пристальней ;)
просто из научного интереса.
теоретически СУБД тут ни при чем.
(6) Спасибо за инфу. Конечно там очень мало конкретики
Но субъективно думаю что Postgres Pro пока все еще более развивающая и постоянно оптимизируемая сборка на текущий момент времени.
При исполнении сложных запросов, в которых используются шаблоны ограничений доступа к данным
и то можно предположить что у всех кто РЛС не использует смысла ставить эту сборку нет, хотя да, сам факт что в фирме 1С залезли в сборку интересен, нов.
Но субъективно думаю что Postgres Pro пока все еще более развивающая и постоянно оптимизируемая сборка на текущий момент времени.
(8)
Появились новые патчи, в исходниках.
В БГУ ред.1.0 формирование некоторых отчетов стало заметно быстрее.
Плюс со стороны платформы также есть улучшения.
Как-то тестировал 8.3.11, прирост неплохой(в сравнении с 8.3.10)
Интересовали результаты именно одного потока.
Ваш тест тоже дал ощутимый прирост, с 50 до 60(на том же сервере, что и в тесте по ссылкам).
сам факт что в фирме 1С залезли в сборку интересен
Появились новые патчи, в исходниках.
В БГУ ред.1.0 формирование некоторых отчетов стало заметно быстрее.
Плюс со стороны платформы также есть улучшения.
Как-то тестировал 8.3.11, прирост неплохой(в сравнении с 8.3.10)
Интересовали результаты именно одного потока.
Ваш тест тоже дал ощутимый прирост, с 50 до 60(на том же сервере, что и в тесте по ссылкам).
(6)
1с не разрабатывает СУБД. Доработка, выпуск сборок, а так же поддержка версии для 1с выполняется командой пг.про.
1с осуществляет первую линию поддержки ентерпрайз версии. Вторая - пг.про.
Версии на сайте 1с и на сайте пг.про - это одни и те же версии.
Про какой свой путь вы говорите?
1с не разрабатывает СУБД. Доработка, выпуск сборок, а так же поддержка версии для 1с выполняется командой пг.про.
1с осуществляет первую линию поддержки ентерпрайз версии. Вторая - пг.про.
Версии на сайте 1с и на сайте пг.про - это одни и те же версии.
Про какой свой путь вы говорите?
(14) Если сравнить патчи в исходных текстах сборок PostgreSQL 9.6.6 от 1С и Постгрес Про, то можно увидеть некоторые различия. Интересующиеся могут легко это сделать.Почему эти различия есть, я не знаю, доступа к сотрудникам 1С и "партнеркам" у меня нет. Исходными текстами интересуюсь потому, что есть привычка самому собирать PostgreSQL из исходников, а не пользоваться готовыми(и тем более, для Windows).
А про "свой путь" - это так, фигура речи, образное выражение..
А про "свой путь" - это так, фигура речи, образное выражение..
Проц нагружается не из за выполнения регламентного задания, а из за загрузки базы в оперативу rphosta для выполнения этого самого регламентного задания. А мс скуль держит все в оперативке. Ну такая же история и с апачем и iis, только из апача все выйдут - процесс сворачивается, первый старт будет долгий пока в опертиву все незакинет, а iis все держит в опертивке пока сам процесс не будет завершен или перезапущен (кстати по умолчаню iis через некоторое время простоя сворачивается, а также через определенные промежутки времени перезапускается - это надо настраивать). Правда я апач все же как то настраивал чтобы он не выгружал все из оперативки... Как вариант держать открытыми все базы на сервере, тогда и заход в них будет быстрый и нагрузка на проц минимальна. Наверно это все таки камень в огород 1с, так как после выхода всех пользователей rphost освобождает оперативку, явно выгружая все что связано с базой.
(18) Не поможет.
Развернул сервер MSSQL + 1с. 35 баз (буха+ЗУП).
Железка - i7-8700K, 64GB DDR4@3000, SSD EVO960.
Автозакрытие баз отключил. Загрузка проца - 100% непрерывно.
Пока не разнёс фоны по времени (1 база в минуту, повтор через час), работать юзерам было ОЧЕНЬ некомфортно. Зато после этой нехитрой операции загрузка упала до нуля. Только в начале каждой запланированной минуты вырастает до 11-15%.
Развернул сервер MSSQL + 1с. 35 баз (буха+ЗУП).
Железка - i7-8700K, 64GB DDR4@3000, SSD EVO960.
Автозакрытие баз отключил. Загрузка проца - 100% непрерывно.
Пока не разнёс фоны по времени (1 база в минуту, повтор через час), работать юзерам было ОЧЕНЬ некомфортно. Зато после этой нехитрой операции загрузка упала до нуля. Только в начале каждой запланированной минуты вырастает до 11-15%.
(18) Не поможет.
Развернул сервер MSSQL + 1с. 35 баз (буха+ЗУП).
Железка - i7-8700K, 64GB DDR4@3000, 3 x SSD EVO960.
Автозакрытие баз отключил. Загрузка проца - 100% непрерывно, нагрузка на накопители - незначительная.
Пока не разнёс фоны по времени (1 база в минуту, повтор через час), работать юзерам было ОЧЕНЬ некомфортно. Зато после этой нехитрой операции загрузка упала до нуля. Только в начале каждой запланированной минуты вырастает до 11-15%.
Развернул сервер MSSQL + 1с. 35 баз (буха+ЗУП).
Железка - i7-8700K, 64GB DDR4@3000, 3 x SSD EVO960.
Автозакрытие баз отключил. Загрузка проца - 100% непрерывно, нагрузка на накопители - незначительная.
Пока не разнёс фоны по времени (1 база в минуту, повтор через час), работать юзерам было ОЧЕНЬ некомфортно. Зато после этой нехитрой операции загрузка упала до нуля. Только в начале каждой запланированной минуты вырастает до 11-15%.
Что-то, прочитав всю эту ветку, так и не понял, есть ли что-то, что можно попробовать сделать чтобы постгрес перестал загружать процессор на сотку...
Как только запускаются фоновые задания (регламентные отключил вообще), так сразу в сотку и может держать их так по несколько минут, при этом сам алгоритм фоновых заданий достаточно прост... там нечего так напряженно рассчитывать.
Как только запускаются фоновые задания (регламентные отключил вообще), так сразу в сотку и может держать их так по несколько минут, при этом сам алгоритм фоновых заданий достаточно прост... там нечего так напряженно рассчитывать.
Прикрепленные файлы:
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот