Срез последних в 1с ут клиент-серверной версии на PostgreSQL
Добрый день! УТ 10.3 клиент-серверный вариант на платформе windows server 2012. База данных на PostgreSQL. Версия Postgre 9.1.2 скачанная с сайта 1с. Опыт работы полгода - 20 пользователей. Про сервер не говорю - в данной теме это значение не имеет.
Столкнулся со следующей проблемой - стандартные запросы (например, прайс-лист) выполняются очень долго в серверной версии (15 минут), хотя если запускать в файловой (запущенной на том же железе), то выполняются очень быстро (20 сек.). Стал разбираться почему это происходит и на диске ИТС нашел рекомендации: Оптимизация использования виртуальной таблицы СрезПоследних при работе с PostgreSQL от 15.12.2010 г. Оказывается если в запросе есть виртуальная таблица СрезПоследних, то оптимизатор PostgreSQL не правильно работает и отчет формируется долго.
Вопрос: данная проблема судя по дате уже давно возникла. Может быть она решена в новой версии PostgreSQL 9.4, которую можно скачать с сайта 1с? Просто переписывать все запросы в которых встречаются виртуальные таблицы очень сложно. Может есть другое решение проблемы?
Столкнулся со следующей проблемой - стандартные запросы (например, прайс-лист) выполняются очень долго в серверной версии (15 минут), хотя если запускать в файловой (запущенной на том же железе), то выполняются очень быстро (20 сек.). Стал разбираться почему это происходит и на диске ИТС нашел рекомендации: Оптимизация использования виртуальной таблицы СрезПоследних при работе с PostgreSQL от 15.12.2010 г. Оказывается если в запросе есть виртуальная таблица СрезПоследних, то оптимизатор PostgreSQL не правильно работает и отчет формируется долго.
Вопрос: данная проблема судя по дате уже давно возникла. Может быть она решена в новой версии PostgreSQL 9.4, которую можно скачать с сайта 1с? Просто переписывать все запросы в которых встречаются виртуальные таблицы очень сложно. Может есть другое решение проблемы?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(3) tarassov, про это тоже читал, кое-какие параметры изменил, но пока особого прироста по скорости обработки данного отчета (Прайс-лист) не получил. Железо вроде неплохое: Двухпроцессорный - CPU:2* Intel 6C Xeon E5-2620 2.0GHz, ОЗУ - 16Гб PC10600, HDD - 4*300GB SAS 6G 15000rpm 16MB, настроен raid 10.
На сервере установлена операционка, сервер 1с, база данных постггрее, терминальный сервер для доступа пользователей. Может подскажите свои настройки postgresql.conf?
На сервере установлена операционка, сервер 1с, база данных постггрее, терминальный сервер для доступа пользователей. Может подскажите свои настройки postgresql.conf?
(5) serpolit,
зачем стоит shared_buffers = 1536MB ?
Это по-моему запредельно много. Значение shared_buffers указывается ДЛЯ ОДНОГО СЕАНСА
10 сеансов по 1536MB могут съесть всю оперативку и загнать систему в своп
Я у себя ставил shared_buffers = 409600kB , что эквивалентно 400 мб на сеанс
зачем стоит shared_buffers = 1536MB ?
Это по-моему запредельно много. Значение shared_buffers указывается ДЛЯ ОДНОГО СЕАНСА
10 сеансов по 1536MB могут съесть всю оперативку и загнать систему в своп
Я у себя ставил shared_buffers = 409600kB , что эквивалентно 400 мб на сеанс
(6) tarassov, Просто в этой статье есть следующая информация:
"...Далее я приведу ориентировочные значения, с которых можно начинать настройку. После первоначальной настройки рекомендуется погонять сервер в рабочих режимах и следить за потреблением памяти. В зависимости от полученных результатов может потребоваться подкорректировать значения параметров.
При настройке сервера для тестирования я полагался на следующие расчеты:
Всего 4Гб ОЗУ. Потребители - ОС Windows, сервер 1С, PostgreSQL и дисковый кэш системы. Я исходил из того что для СУБД можно выделить до 2.5Гб ОЗУ
Значения могут указываться с суффиксами kB, MB, GB (значения в килобайта, мегабайтах или гигабайтах). После изменения значений требуется перезапустить службу PostgreSQL.
shared_buffers - Общий буфер сервера
Размер кэша чтения и записи PostgreSQL, общего для всех подключений. Если данные отсутствуют в кэше, производится чтение с диска (возможно, будут кэшированы ОС)
Если объём буфера недостаточен для хранения часто используемых рабочих данных, то они будут постоянно писаться и читаться из кэша ОС или с диска, что крайне отрицательно скажется на производительности.
Но это не вся память, требуемая для работы, не следует указывать слишком большое значение, иначе не останется памяти как для собственно выполнения запросов клиентов (а чем их больше тем выше потребление памяти), так и для ОС и прочих приложений, например, процесса сервера 1С. Так же сервер полагается и на кэш ОС и старается не держать в своём буфере то что скорее всего закэшировано системой.
Начальные рекомендации:
Средний объем данных, доступно 256-512Мб - значения 16-32Мб
Большой объем данных, доступно 1-4Гб - значения 64-256Мб или выше.
В тесте использовалось
shared_buffers = 512MB"
Я так понял что данная память не для каждого сеанса,а общая ("...Размер кэша чтения и записи PostgreSQL, общего для всех подключений"). У автора всего ОЗУ 4гб,а shared_buffers = 512MB. У меня же я взял 12гб (4 оставил про запас) - вот я и умножил на 3 и получил 1536мб. Вроде правильно сделал?
А вот work_mem выделяется под каждый запрос ее я сделал 512мб
"...Далее я приведу ориентировочные значения, с которых можно начинать настройку. После первоначальной настройки рекомендуется погонять сервер в рабочих режимах и следить за потреблением памяти. В зависимости от полученных результатов может потребоваться подкорректировать значения параметров.
При настройке сервера для тестирования я полагался на следующие расчеты:
Всего 4Гб ОЗУ. Потребители - ОС Windows, сервер 1С, PostgreSQL и дисковый кэш системы. Я исходил из того что для СУБД можно выделить до 2.5Гб ОЗУ
Значения могут указываться с суффиксами kB, MB, GB (значения в килобайта, мегабайтах или гигабайтах). После изменения значений требуется перезапустить службу PostgreSQL.
shared_buffers - Общий буфер сервера
Размер кэша чтения и записи PostgreSQL, общего для всех подключений. Если данные отсутствуют в кэше, производится чтение с диска (возможно, будут кэшированы ОС)
Если объём буфера недостаточен для хранения часто используемых рабочих данных, то они будут постоянно писаться и читаться из кэша ОС или с диска, что крайне отрицательно скажется на производительности.
Но это не вся память, требуемая для работы, не следует указывать слишком большое значение, иначе не останется памяти как для собственно выполнения запросов клиентов (а чем их больше тем выше потребление памяти), так и для ОС и прочих приложений, например, процесса сервера 1С. Так же сервер полагается и на кэш ОС и старается не держать в своём буфере то что скорее всего закэшировано системой.
Начальные рекомендации:
Средний объем данных, доступно 256-512Мб - значения 16-32Мб
Большой объем данных, доступно 1-4Гб - значения 64-256Мб или выше.
В тесте использовалось
shared_buffers = 512MB"
Я так понял что данная память не для каждого сеанса,а общая ("...Размер кэша чтения и записи PostgreSQL, общего для всех подключений"). У автора всего ОЗУ 4гб,а shared_buffers = 512MB. У меня же я взял 12гб (4 оставил про запас) - вот я и умножил на 3 и получил 1536мб. Вроде правильно сделал?
А вот work_mem выделяется под каждый запрос ее я сделал 512мб
проверяйте запросы. Соединение физической таблицы (например справочника) с виртуальной (регистр накопления.остатки) на всех СУБД работает очень плохо.
Но MS SQL такую связку перерабатывает значительно лучше остальных. PostGRE может вообще "умереть" на таком запросе.
Переработайте такие запросы, сделав предварительную выборку по виртуальной таблице, выгрузив эти данные во временную таблицу, ну а далее связывайте с физической таблицей.
Либо переходите на MS SQL. Но, повторюсь, и там такие запросы будут работать очень-очень медленно.
Но MS SQL такую связку перерабатывает значительно лучше остальных. PostGRE может вообще "умереть" на таком запросе.
Переработайте такие запросы, сделав предварительную выборку по виртуальной таблице, выгрузив эти данные во временную таблицу, ну а далее связывайте с физической таблицей.
Либо переходите на MS SQL. Но, повторюсь, и там такие запросы будут работать очень-очень медленно.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот