Немного о конфигурировании PostgreSQL

29.01.15

База данных - Инструменты администратора БД

*Есть ли альтернатива MSSQL?
*PostgreSQL - тормоз или отличная СУБД?
*Как заставить работать PostgreSQL на полной скорости?

Данная статья не претендует на полноту изложения всех возможностей конфигурирования PostgreSQL, и в сравнительном тестировании я не охватываю всех режимов работы базы данных. Заинтересовавшимся советую изучить книгу по ссылке

Вступление
Тестирование
Конфигурирование
Настройка использования памяти
Настройка Autovacuum
Настройка записи данных на диск
Прочие настройки
Заключение
Полезные ссылки
История правок статьи

Вступление

Я много работал с PostgreSQL и считаю его прекрасной СУБД. У меня многогигабайтная рабочая база (не 1С) обрабатывает моментально огромные массивы данных. PostgreSQL прекрасно использует индексы, хорошо справляется с параллельной нагрузкой, функционал хранимых процедур на высоте, есть хорошие средства администрирования и повышения производительности "из коробки", а сообщество создало полезные утилиты. Но я с удивлением узнал что у многих администраторов 1С мнение о PostgreSQL не на высоте, что он тормоз и едва обгоняет файловый вариант базы, и только MSSQL может спасти положение.

Поизучав вопрос, я нашел множество статей по установке PostgreSQL по шагам для чайников, как по Linux, так и под Windows. Но подавляющее большинство статей описывают установку до "установилось - создадим базу", и совершенно не затрагивают вопрос конфигурирования. В оставшихся конфигурирование упоминается лишь на уровне "прописать такие значения", практически не объясняя зачем.

И если подход "установка в одну кнопку" применим к MSSQL и вообще многим продуктам под Windows, то к PostgreSQL он, к сожалению, не относится. Настройки по умолчанию очень сильно ограничивают его в использовании памяти, чтобы можно было его установить хоть на калькулятор и он там не мешал работе остального ПО. PostgreSQL обязательно нужно конфигурировать под конкретную систему, и только тогда он сможет показать себя на высоте. В особо тяжелых случаях можно тюнинговать настройки PostgreSQL, базы и файловой системы друг под друга, но это касается в большей степени Linux-систем, где больше возможностей по настройке всего и вся.

Следует напомнить, что для 1С не подойдет сборка PostgreSQL от разработчиков СУБД, только собранная из пропатченных 1С исходных текстов. Готовые совместимые сборки предлагает 1С (через диски ИТС и кабинет для имеющих подписку на поддержку) и EterSoft http://etersoft.ru/products/postgre

Тестирование проводилось в среде Windows, но все рекомендации по настройке не являются специфичными для платформы и применимы к любой ОС.

Тестирование и сравнение

При тестировании я не ставил задачи провести испытания во всех режимах и сценариях работы, исключительно черновая проверка успешного конфигурирования.

Для тестирования я использовал следующую конфигурацию:
Host-машина: Win7, Core i5-760 2.8MHz, 4 ядра, 12Гб ОЗУ, VMWare 10
Виртуальная: Win7 x64, 2 ядра, 4Гб ОЗУ, отдельный физический жесткий диск для размещения БД (не SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1C 8.3.5 1383

Использовалась БД, dt-выгрузка 780Мб.
После восстановления базы:
размер файла 1CD в файловом варианте - 10Гб,
размер базы PostgreSQL - 8Гб,
размер базы MSSQL - 6.7Гб.

Для теста использовал запрос на выборку договоров контрагентов (21к) с выборкой дополнительных реквизитов из различных регистров, для каждого договора фактически делалась отдельная выборка из регистров. Конфигурацию взял что была под рукой - сильно доработанная на базе Бухгалтерии 3.0.

При тестировании выполнял запрос одним и двумя клиентами по несколько раз до получения стабильных результатов. Первые прогоны игнорировал.

Тестирование одним клиентом:

Выборка на хосте из файлового варианта с размещением базы на SSD - 31с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - 46с
Выборка из MSSQL-базы - первый проход - 25с или 9с (видимо в зависимости от актуальности кэша СУБД) (потребление памяти процессом СУБД составило примерно 1.3Гб)
Выборка из PostgreSQL с настройками по умолчанию - 43с (потребление памяти не превышало 80Мб на подключение)
Выборка из оптимизированного PostgreSQL - 21с (потребление памяти составило 120Мб на подключение)

Тестирование двумя клиентами:

Выборка на хосте из файлового варианта с размещением базы на SSD - по 34с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - по 56с
Выборка из MSSQL-базы - по 50с или 20с (видимо в зависимости от актуальности кэша СУБД)
Выборка из PostgreSQL с настройками по умолчанию - по 60с
Выборка из оптимизированного PostgreSQL - по 40с

Замечания к тестированию:

После добавления третьего ядра PostgreSQL и MSSQL-варианты стали работать в тесте "два клиента" практически с производительностью теста "один клиент", т.е. удачно распараллелились. Что мешало им параллелить работу на двух ядрах для меня осталось загадкой.
MSSQL памяти захватил сразу много, PostgreSQL требовал во всех режимах существенно меньше, и сразу после завершения выполнения запроса почти всю высвобождал.
MSSQL работает единым процессом. PostgreSQL запускает по отдельному процессу на подключение+служебные процессы. Это позволяет даже 32-разрядному варианту эффективно использовать память при обработке запросов от нескольких клиентов.
Увеличение памяти для PostgreSQL в настройках свыше указанных ниже значений не привело к заметному росту производительности.
Первые тесты во всех случаях проходили дольше чем в последующих замерах, специально замеры не производил, но MSSQL субъективно стартовал быстрее.

Конфигурирование PostgreSQL

Есть прекрасная книга на русском языке о конфигурировании и оптимизировании PostgreSQL: http://postgresql.leopard.in.ua/ Каждому слоноводу имеет смысл поставить себе в закладки эту ссылку. В книге описывается множество техниг оптимизации СУБД, создание отказоустойчивых и распределенных систем. Но сейчас мы рассмотрим то что пригодится всем - конфигурирование использования памяти. PostgreSQL не будет использовать памяти больше чем разрешено настройками, а с настройками по умолчанию PostgreSQL использует минимум памяти. При этом не стоит указывать памяти больше чем доступно к использованию - система начнет использовать файл подкачки со всеми вытекающими печальными последствиями для производительности сервера. Ряд советов по настройке PostgreSQL приведены на диске ИТС.

В Windows конфигурационные файлы PostgreSQL находятся в каталоге установки в каталоге Data:

postgresql.conf - основной файл с настройками СУБД
pg_hba.conf - файл с настройками доступа для клиентов. В частности, тут можно указать каким пользователям с каких IP-адресов можно подключаться к определенным БД, и требуется ли проверять пароль пользователя, и если требуется - каким методом.
pg_ident.conf - файл с преобразованием имен пользователей из системных во внутренние (вряд ли он потребуется большинству пользователей)

Файлы текстовые, можно править блокнотом. Строки, начинающиеся с # считаются комментариями и игнорируются.

Параметры, относящиеся к объму памяти могут дополняться суффиксами kB, MB, GB - килобайты, мегабайты, гигабайты, например, 128MB. Параметры, описывающие интервалы времени, могут дополняться суффиксами ms,s,min,h,d - миллисекунды, секунды, минуты, часы, дни, например, 5min

Если вы забыли пароль к постгрессу - не беда, можно прописать в pg_hba.conf строку:

host    all             all             127.0.0.1/32            trust

И подключаться любым пользователем (например, postgres) к СУБД на локальной машине по адресу 127.0.0.1 без проверки пароля.

Оптимизация использования памяти

Настройки использования памяти располагаются в postgresql.conf

Оптимальные значения параметров зависят от объема свободной оперативной памяти, размера базы и отдельных элементов базы (таблицы и индексы), сложности запросов (в принципе, стоит полагаться что запросы будут достаточно сложными - множественные соединения в запросах это типовой сценарий) и количества одновременных активных клиентов. Кстати, PostgreSQL хранит таблицы и индексы БД в отдельных файлах (<каталог установки PG>\data\base\<идентификатор БД>\), и размеры объектов можно оценить. Так же можно используя входящую в поставку утилиту pgAdmin подключиться к базе, раскрыть "Схемы"-"public", и сформировать отчет по статистике для элемента "Таблицы".

Далее я приведу ориентировочные значения, с которых можно начинать настройку. После первоначальной настройки рекомендуется погонять сервер в рабочих режимах и следить за потреблением памяти. В зависимости от полученных результатов может потребоваться подкорректировать значения параметров.

При настройке сервера для тестирования я полагался на следующие расчеты:
Всего 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

work_mem - память для сортировки, агрегации данных и т.д.

Выделяется на каждый запрос, возможно по нескольку раз для сложных запросов. Если памяти недостаточно - PostgreSQL будет использовать временные файлы. Если значение слишком большое - может возникнуть перерасход оперативной памяти и ОС начнет использовать файл подкачки с соответствующим падением быстродействия.

Есть рекомендация при расчетах взять объем доступной памяти за вычетом shared_buffers, и поделить на количество одновременно исполняемых запросов. В случае сложных запросов делитель стоит увеличить, т.е. уменьшить результат. Для рассматриваемого случая из расчета 5 активных пользователей (2.5Гб-0.5Гб (shared_buffers))/5=400Мб. В случае если СУБД сочтет запросы достаточно сложными, или появятся дополнительные пользователи, потребуется значение уменьшить.

Для простых запросов достаточно небольших значений - до пары мегабайт, но для сложных запросов (а это типовой сценарий для 1С) потребуется больше. Рекомендация - для памяти 1-4Гб можно использовать значения 32-128Мб. В тесте использовал

work_mem = 128MB

maintenance_work_mem - память для команд сбора мусора, статистики, создания индексов.

Рекомендуется устанавливать значение 50-75% от размера самой большой таблицы или индекса, но чтобы памяти хватило для работы системы и приложений. Рекомендуется устанавливать значения больше чем work_mem. В тесте использовал
maintenance_work_mem = 192MB

temp_buffers - буфер под временные объекты, в основном для временных таблиц.

Можно установить порядка 16 МБ. В тесте использовал
temp_buffers = 32MB

effective_cache_size - примерный объем дискового кэша файловой системы.

Оптимизатор использует это значение при построении плана запроса, для оценки вероятности нахождения данных в кэше (с быстрым случайным доступом) или на медленном диске. В Windows текущий объем памяти, выделенной под кэш, можно посмотреть в диспетчере задач.

Autovacuum - "сборка мусора"

PostgreSQL как типичный представитель "версионных" СУБД (в противоположность блокирующим) самостоятельно не блокирует при изменении данных таблицы и записи от читающих транзакций (в случае 1С этим занимается сам сервер 1С). Вместо этого создаётся копия изменяемой записи, которая становится видна последующим транзакциям, действующие же продолжают видеть данные, актуальные на начало своей транзакции. Как следствие, в таблицах накапливаются устаревшие данные - предыдущие версии измененных записей. Для того чтобы СУБД могла высвободившееся место использовать, необходимо произвести "сборку мусора" - определить какие из записей больше не используются. Это можно сделать явно SQL-командой VACUUM, либо дождаться когда таблицу обработает автоматический сборщик мусора - AUTOVACUUM. Так же до определенной версии сборка мусора была связана со сбором статистики (планировщик использует данные о количестве записей в таблицах и распределении значений индексированных полей для построения оптимального плана запроса). С одной стороны, сбор мусора делать необходимо, чтобы таблицы не разрастались и эффективно использовали дисковое пространство. С другой внезапно начавшаяся уборка мусора дает дополнительную нагрузку на диск и таблицы, что приводит к увеличению времени выполнения запросов. Аналогичный эффект создает автоматический сбор статистики (явно его можно запустить командой ANALYZE или совместно со сборкой мусора VACUUM ANALYZE). И хотя от версии к версии PostgreSQL совершенствует эти механизмы, чтобы минимизировать негативное влияние на производительность (например, в ранних версиях сборка мусора полностью блокировала доступ к таблице, с версии 9.0 работа VACUUM ускорена), тут есть что настроить.

Полностью отключить autovacuum можно параметром:

autovacuum = off

Так же для работы Autovacuum требуется параметр track_counts = on, в противном случае он работать не будет.

По умолчанию оба параметра включены. На самом деле autovacuum полностью отключить нельзя - даже при autovacuum = off иногда (после большого количества транзакций) autovacuum будет запускаться.

Отключать autovacuum крайне не рекомендуется, иначе имеет смысл самостоятельно запланировать регулярное выполнение команды VACUUM ANALYZE.

Замечание: VACUUM обычно не уменьшает размер файла таблицы, только помечает свободные, доступные для повторного использования области. Если же требуется физически высвободить лишнее место и максимально уменьшить занимаемое пространство на диске, потребуется команда VACUUM FULL. Этот вариант блокирует доступ к таблице на время работы, и обычно не требуется его использовать. Подробнее об использовании команды VACUUM можно прочитать в документации (на английском).

Если Autovacuum полностью не отключать, настроить его влияние на выполнение запросов можно следующими параметрами:

autovacuum_max_workers - максимальное количество параллельно запущенных процессов уборки.

autovacuum_naptime - минимальный интервал, реже которого autovacuum не будет запускаться. По умолчанию 1 минута. Можно увеличить, тогда при частых изменениях данных анализ будет выполняться реже.

autovacuum_vacuum_threshold, autovacuum_analyze_threshold - количество измененных или удаленных записей в таблице, необходимых для запуска процесса сборки мусора VACUUM или сбора статистики ANALYZE. По умолчанию по 50.

autovacuum_vacuum_scale_factor, autovacuum_analyze_scale_factor - коэфициент от размера таблицы в записях, добавляемый к autovacuum_vacuum_threshold и autovacuum_analyze_threshold соответственно. Значения по умолчанию 0.2 (т.е. 20% от количества записей) и 0.1 (10%) соответственно.

Рассмотрим пример с таблицей на 10000 записей. Тогда при настройках по умолчанию после 50+10000*0.1=1050 измененных или удаленных записей будет запущен сбор статистики ANALYZE, а после 2050 изменений - сборка мусора VACUUM.

Если увеличить threshold и scale_factor, обслуживающие процессы будут выполняться реже, но небольшие таблицы могут существенно разрастаться. Если БД состоит преимущественно из небольших таблиц, общее увеличение занимаемого дискового пространства может быть существенным, таким образом увеличивать эти значения можно, но с умом.

Таким образом может иметь смысл увеличить интервал autovacuum_naptime, и несколько увеличить threshold и scale_factor. В нагруженных базах может быть альтернативой существенно поднять scale_factor (значение 1 позволит "разбухать" таблицам вдвое) и поставить в планировщик ежесуточное выполнение VACUUM ANALYZE в период минимальной загруженности БД.

default_statistics_target - назначает объем статистики, собираемый командой ANALYZE. Значение по умолчанию 100. Большие значения увеличивают время выполнения команды ANALYZE, но позволяют планировщику строить более эффективные планы выполнения запросов. Встречаются рекомендации по увеличению до 300.

Можно управлять производительностью AUTOVACUUM, делая его более длительным но менее нагружающим систему.

vacuum_cost_page_hit - размер "штрафа" за обработку блока, находящегося в shared_buffers. Связан с необходимостью блокировать доступ к буферу. Значение по умолчанию 1

vacuum_cost_page_miss - размер "штрафа" за обработку блока на диске. Связан с блокировкой буфера, поиском данных в буфере, чтении данных с диска. Значение по умолчанию 10

vacuum_cost_page_dirty - размер "штрафа" за модификацию блока. Связан с необходимостью сбросить модифицированные данные на диск. Значение по умолчанию 20

vacuum_cost_limit - максимальный размер "штрафов", после которых процесс сборки может быть "заморожен" на время vacuum_cost_delay. По умолчанию 200

vacuum_cost_delay - время "заморозки" процесса сборки мусора по достижению vacuum_cost_limit. Значение по умолчанию 0ms

autovacuum_vacuum_cost_delay - время "заморозки" процесса сборки мусора для autovacuum. По умолчанию 20ms. Если установить -1, будет использоваться значение vacuum_cost_delay

autovacuum_vacuum_cost_limit - максимальный размер "штрафа" для autovacuum. Значение по умолчанию -1 - используется значение vacuum_cost_limit

По сообщениям использование vacuum_cost_page_hit = 6, vacuum_cost_limit = 100, autovacuum_vacuum_cost_delay = 200ms уменьшает влияние AUTOVACUUM до 80%, но увеличивает время его выполнения втрое.

Настройка записи на диск

При завершении транзакции PostgreSQL начала пишет данные в специальный журнал транзакций WAL (Write-ahead log), а затем уже в базу после того, как данные журнала гарантированно записаны на диск. По умолчанию используется механизм fsync, когда PostgreSQL принудительно сбрасывает данные (журнала) из дискового кэша ОС на диск, и только после успешной записи (журнала) клиенту сообщается об успешном завершении транзакции. Использование журнала транзакций позволяет завершить транзакцию или восстановить базу если во время записи данных произойдет сбой.

В нагруженных системах с большими объемами записи может иметь смысл вынести журнал транзакций на отдельный физический диск (но не на другой раздел этого же диска!). Для этого нужно остановить СУБД, перенести каталог pg_xlog в другое место, а на старом месте создать символическую ссылку, например, утилитой junction. Так же ссылки умеет создавать Far Manager (Alt-F6). При этом надо убедиться что новое место имеет права доступа для пользователя, от которого запускается PostgreSQL (обычно postgres).

При большом количестве операций изменения данных может потребоваться увеличить значение checkpoint_segments, регулирующее объем данных, который может ожидать переноса из журнала в саму базу. По умолчанию используется значение 3. При этом следует учитывать что под журнал выделяется место, расчитываемое по формуле (checkpoint_segments * 2 + 1) * 16 МБ, что при значении 32 уже потребует более 1Гб места на диске.

PostgreSQL после каждого завершения пишущей транзакции сбрасывает данные из файлового кэша ОС на диск. С одной стороны, это гарантирует что данные на диске всегда в актуальном состоянии, с другой при большом количестве транзакций падает производительность. Полностью отключить fsync можно, указав

fsync = off
full_page_writes = off

Делать это можно только в случае если вы на 100% доверяете оборудованию и ИБП (источнику бесперебойного питания). Иначе в случае аварийного завершения системы есть риск получить разрушенную БД. И в любом варианте не помешает так же RAID-контроллер с батарейкой для питания памяти недозаписанных данных.

Определенной альтернативой может быть использование параметра

synchronous_commit = off

В этом случае после успешного ответа на завершение транзакции до безопасной записи на диск может пройти некоторое время. В случае внезапного отключения база не разрушится, но могут быть потеряны данные последних транзакций.

Если не отключать fsync совсем, можно указать метод синхронизации в параметре. Статья с диска ИТС ссылается на утилиту pg_test_fsync, но в моей сборке PostgreSQL её не оказалось. По утверждению 1С, в их случае в Windows оптимально себя показал метод open_datasync (судя по всему, именно этот метод и используется по умолчанию).

В случае если используется множество мелких пишущих транзакций (в случае 1С этом может быть массовое обновление справочника вне транзакции), может помочь сочетание параметров commit_delay (время задержки завершения транзакции в микросекундах, по умолчанию 0) и commit_siblings (по умолчанию 5). При включении опций завершение транзакции может быть отложено на время commit_delay, если в данный момент исполняется не менее commit_siblings транзакций. В этом случае результат всех завершившихся транзакций будет записан совместно для оптимизации записи на диск.

Прочие параметры, влияющие на производительность

wal_buffers - объем памяти в shared_buffers для ведения транзакционных логов. Рекомендация - при 1-4Гб доступной памяти использовать значения 256КБ-1МБ. Документация утверждает что использование значения "-1" автоматически подбирает значение в зависимости от значения shared_buffers.

random_page_cost - "стоимость" случайного чтения, используется при поиске данных по индексам. По умолчанию 4.0. За единицу берется время последовательного доступа к данным. Для быстрых дисковых массивов, особенно SSD, имеет смысл понижать значение, в этом случае PostgreSQL будет более активно использовать индексы.

В книге по ссылке есть некоторые другие параметры, которые можно настраивать. Так же настоятельно рекомендуется ознакомиться с документацией на PostgreSQL по назначению конкретных параметров.

Параметры из раздела QUERY TUNING, особенно касающиеся запрета планировщику использовать конкретные методы поиска, рекомендуется изменять только в том случае если есть полное понимание что делаете. Очень легко оптимизировать один вид запросов и обрушить производительность всех остальных. Эффективность изменения большинства параметров в этом разделе зависит от данных в БД, запросов к этим данным (т.е. от используемой версии 1С в т.ч.) и версии СУБД.

Заключение

PostgreSQL - мощная СУБД в умелых руках, но требующая тщательной настройки. Его вполне можно использовать совместно с 1С и получить приличное быстродействие, а бесплатность его будет очень приятным бонусом.

Критика и дополнения к этой статье приветствуются.

Полезные ссылки

http://postgresql.leopard.in.ua/ - сайт книги "Работа с PostgreSQL настройка и масштабирование", наиболее полное и понятное руководство на мой взгляд по конфигурированию и администрированию PostgreSQL

http://etersoft.ru/products/postgre - здесь можно скачать 1С-совместимую сборку PostgreSQL под Windows и различные дистрибутивы и версии Linux. Для тех у кого нет подписки на ИТС или требуется версия под версию Linux, которая не представлена на v8.1c.ru.

http://www.postgresql.org/docs/9.2/static/ - официальная документация на PostgreSQL (на английском)

Статьи с диска ИТС по настройке PostgreSQL

История правок статьи

29.01.2015 - опубликована первоначальная версия
31.01.2015 - статья дополнена разделом по AUTOVACUUM, добавлена ссылка на оригинальную документацию.

В дальнейшем я намерен провести тестирование работы СУБД в режиме добавления и изменения данные.

СУБД MSSQL PostgreSQL

+316 –1

См. также

SALE! 15%

Database Compression Tool (DCT) Универсальный инструмент сжатия, свертки и конвертации баз данных 1С

Инструментарий разработчика Чистка данных Свертка базы Инструменты администратора БД Системный администратор Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Россия Платные (руб)

Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP и т.д.). Поддерживаются управляемые и обычные формы. Может выполнять свертку сразу нескольких баз данных и выполнять их автоматически без непосредственного участия пользователя.

~~8400~~ 7140 руб.

20.08.2024 7748 55 22

Автоподбор ролей для профилей и групп доступа в любых типовых базах 1С УТ 11, КА 2, ERP2, Розница 2/3, УНФ 16/3, БП 3, ЗУП 3 и подобных (УФ, Платформа 8.3.14+)

Инструменты администратора БД Роли и права Системный администратор Программист Пользователь 8.3.14 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Документооборот 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

Роли… Вы тратите много времени и сил на подбор ролей среди около 2400 в ERP или 1500 в Рознице 2, пытаясь понять какими правами они обладают? Вы все время смотрите права в конфигураторе или отчетах чтоб создать нормальные профили доступа? Вы хотите наглядно видеть какие права дает профиль и редактировать все в простом виде? А может хотите просто указать подсистему и дать права на просмотр и добавление на объекты и не лезть в дебри прав и чтоб обработка сама подобрала нужные роли? Все это теперь стало возможно! Обновление от 18.09.2024, версия 1.2

16800 руб.

06.12.2023 8831 42 5

SALE! 15%

Infostart DataFormWizard: Управление данными и формами в 1С 8.3

Инструменты администратора БД Инструментарий разработчика Роли и права Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

Расширение позволяет без изменения кода конфигурации выполнять проверки при вводе данных, скрывать от пользователя недоступные ему данные, выполнять код в обработчиках. Не изменяет данные конфигурации, легко устанавливается практически на любую конфигурацию на управляемых формах.

~~10000~~ 8500 руб.

10.11.2023 10403 36 20

SALE! 35%

PowerTools: Инструменты администратора 1С 8.3

Инструментарий разработчика Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

Универсальный инструмент программиста для администрирования конфигураций. Сборник наиболее часто используемых обработок под единым интерфейсом.

~~4800~~ 3120 руб.

14.01.2013 187959 1138 0

912

Ускоренное проведение документов в 1С (x4), устранение ошибок 60/62 счетов и зачет авансов (Бухгалтерия 3.0)

Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтер Пользователь Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).

14400 руб.

29.04.2020 32654 106 152

Система хранения присоединенных файлов в томах на диске

Инструменты администратора БД Системный администратор Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием Платные (руб)

Конфигурация Комплексная автоматизация 1.1 (и УПП 1.3 тоже) хранит файлы и изображения в справочнике Хранилище дополнительной информации в реквизите Хранилище типа ХранилищеЗначений. Та же история с ВложениямиЭлектроннойПочты. Но при этом присоединенные файлы в Электронном документообороте хранит в томах на диске. Эта доработка позволяет использовать стандартный механизм хранения файлов, изображений и вложений электронных писем в томах на диске. При этом можно разделить тома хранения по объектам конфигурации.

4200 руб.

10.11.2015 62812 94 59

Автоматическое резервное копирование любой клиент-серверной базы 1С в формате DT с удалением сеансов, архивацией, изменением расширения (8.3.14+, расширение)

Архивирование (backup) Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Данная разработка позволит решить вопрос с резервным копированием Ваших баз в автоматическом режиме, расположенных на сервере 1С. Система умеет ставить блокировки на вход, блокировать фоновые задания, принудительно отключать сеансы пользователей. И все это система делает в автоматически при создании бэкапа (или через команду). Выгрузка происходит в родной формат 1С - .dt. Так же система умеет архивировать данные выгрузки с установкой пароля. Умеет менять расширение файла zip или dt на любое указанное вами, что позволит сохранить выгрузки от шифровальщика. Может удалять старые копии выгрузок, оставляя указанное количество резервных копий, начиная с самой поздней. Только для WINDOWS!

6000 руб.

06.11.2012 72785 625 45

Сжатие (уменьшение) картинок в базе 1С и приведение их к одинаковой ширине

Инструменты администратора БД Пользователь Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Платные (руб)

Многие сталкиваются с проблемой когда изображения, находящиеся в базе разные по объему и размерам. Менеджеры могут добавить файлы в очень высоком разрешении, объемом свыше 20 Мегабайт. База данных становится слишком большой, выгрузка на сайт идёт медленно и требуется много место на хостинге. Как сжать картинки и уменьшить размер базы 1С? Это можно сделать с помощью данной обработки. Существует возможность выбрать различные варианты для того чтобы уменьшить картинки: в разы, в процентах от первоначального объема, а также сделать картинки одинаковой ширины. В результате размер базы 1С значительно сократится (в зависимости от количества и размера картинок), а изображения станут небольшого объема, равными по ширине, почти без потери качества. Работает на управляемых формах для УТ 11, КА, ERP.

3000 руб.

21.07.2022 9831 7 4

Вознаграждение за ответ

Сумма: 2 $m

Добавили:
quick (2.00 $m)

Показать полностью

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. TODD22 19 30.01.15 06:18 Сейчас в теме

Я много работал с PostgreSQL и считаю его прекрасной СУБД. У меня многогигабайтная рабочая база (не 1С) обрабатывает моментально огромные массивы данных.

А опыт эксплуатации многогигабайтной рабочей базы 1С есть?
А то проблема может быть не в СУБД. А в работе 1С с этой самой СУБД.

2. Pasha1st 849 30.01.15 08:09 Сейчас в теме

(1) TODD22, у себя запускал относительно небольшие базы, а вот у пары знакомых 1С на PostgreSQL работает с крупными базами. Отзывы были положительные.

3. MishaHD 33 30.01.15 09:07 Сейчас в теме

Пробежался мельком по статье, полезная, спасибо! Но в тексте нет ничего про блокировки. При взаимодействии Postgre и 1С, 1с не умеет выставлять блокировки на отдельные записи таблиц базы данных в режиме автоматических блокировок (актуально например для УТ 10.3), то есть всегда блокируется таблица целиком. Страдает производительность, причем на порядки, а самое неприятное что при большом объеме данных начинается проблема с deadlock. Получается два варианта: писать управляемые блокировки и переходить на MS SQL. Если у вас большая и сильно переписанная база, то экономически не целесообразно переписывать все под управляемые блокировки, проще перейти на MS SQL.
Вообще по моему мнению сейчас Postgre можно рассматривать как альтернативу файловой только на относительно небольшой базе с небольшим количеством пользователей.

5. qwinter 683 30.01.15 11:03 Сейчас в теме

(3) MishaHD, постгря версионник, он никогда не будет выставлять блокировки. Блокировки накладывает сервер 1С. И тут мы уже возвращаемся к уже измусоленному вопросу, что 1С поддерживает все остальные базы данных кроме мс на отъебись.

4. Dmitri_1C 195 30.01.15 09:09 Сейчас в теме

По опыту работы с PostgreSQL - это очень хорошая вещь, если конечно научить её пользоваться.
Я не ставил её на Windows, но в связке с Linux, даже при стандартных настройках работает замечательно.
Мне кажется, что на PostgreSQL жалуются только те, кто не смог разобраться как её устанавливать (установка её на Linux это отдельная история), вот и придумывают всё, чтоб народ даже не смотрел в сторону PostgreSQL.

8. TODD22 19 30.01.15 13:03 Сейчас в теме

(4) Dmitri_1C,

Мне кажется, что на PostgreSQL жалуются только те, кто не смог разобраться как её устанавливать (установка её на Linux это отдельная история), вот и придумывают всё, чтоб народ даже не смотрел в сторону PostgreSQL.

Скорее люди себе проблем наживать на работе не хотят.
(2)

TODD22, у себя запускал относительно небольшие базы, а вот у пары знакомых 1С на PostgreSQL работает с крупными базами. Отзывы были положительные.

У меня знакомый эксплуатировал слона на относительно небольшой базе... всё до определённого момента было хорошо. Потом появились какие то ошибки СУБД. С которыми он героически сражался и даже отсылал базу в 1С. После этого плюнул на этот гемор и завёл всё ms sql.

63. vasyna 23.02.16 16:53 Сейчас в теме

(4) Dmitri_1C, а что там сложного? Там и без мануалов раз-два и готово. А с ними и того проще. Я ставил года 4 назад знакомым. Они с фс по сети и 5 пользователей по 2 минуты ждали открытия или проведения документа. 4 часа и я им поставил ubuntu server + PostgreSQL + 1с Сервер + webMin (там же влепил архивацию базы и на ваял скриптик который каталагизировал архивы). Ни чего сложного. Конечно работать стало быстрее и комфортнее, но потом сервер изъяли и купили такое же железо, но уже взяли лицуху на 1с и sql сервер и вот там вот действительно увидели разницу.

6. qwinter 683 30.01.15 11:17 Сейчас в теме

Статья не полная, по сути нет ничего полезного. Во первых почему не написана про параметры "Autovacuum"? Если с чего в постгре и начинать, то так именно с этого раздела. И раздел настроек "Planner Cost Constants" тоже не важен?))))

21. Pasha1st 849 30.01.15 20:41 Сейчас в теме

(6) qwinter, Дополню, напишу поподробнее про Autovacuum. Но первое, что надо делать, это именно настройка памяти - практика показывает что многие не читают даже рекомендаций 1С по настройке, не говоря уже об остальном. Planner Costs - это уже сверхтонкая настройка, результат которой зависит и от данных, и от запросов (читай - версии 1С), и от версии PostgreSQL, испортить производительность тут намного проще чем выиграть. Да и не ставил я задачи описать все возможности по настройке, заинтересовавшиеся могут сами изучить оставшиеся возможности.
(7) AllexSoft, постараюсь провести тестирование с добавлением/изменением данных, но быстро не получится, постараюсь в течении следующей недели сделать.

86. user741586 28.05.17 14:14 Сейчас в теме

(6)Павел ждем от вас дополнения к этой статье

7. AllexSoft 30.01.15 11:45 Сейчас в теме

Спасибо за статью! Хорошо написано и разжевано именно то что нужно при настройке PostgreSQL + 1С. Собственно из своего опыта: по операциям чтения от PostgreSQL добиться неплохой производительности можно довольно просто - выставив подходящие параметры буферов и использования памяти.. обычно это получается почти сразу "на глаз".. а вот с записью беда( мне например пришлось полностью отключать fsync на операциях массовой перезаписи (при закрытии месяца - восстановление последовательности, при обновлении конфигурации) - вот тут PostgreSQL показала себя не с лучшей стороны, к сожалению замеров не делал но визуально с включенным fsync операции записи шли в 2 раза дольше чем на файловой, с отключенным fsync - сравнимо с файловой..
К автору - хотелось бы увидеть более детальное рассмотрение параметров связанных с синхронизацией транзакционных логов с базой и Autovacuum + сравнение файловой, PostgreSQL и MSSQL именно на операциях записи, потому что это узкое место PostgreSQL

9. qwinter 683 30.01.15 15:24 Сейчас в теме

(7) AllexSoft, не надо забывать, что PostgreSQL использует множество мелких файлов (отсюда и растут ноги многочисленных тормозов), поэтому при развертывании на linux надо подобрать соответствующую файловую систему которая быстро работает с мелкими файлами (перейдя с самой распространенной ext4 на ext3 можно получить 20-30% прироста производительности, а есть файловые системы которые с мелкими файлами работают еще быстрее), а для windows очень желателен SSD диск.

10. TODD22 19 30.01.15 15:53 Сейчас в теме

а для windows очень желателен SSD диск.

SSD диск желателен не только для винды. После того как у меня процедура чистки базы на зеркале из 2х HDD длилась около 5 часов и та же самая операция на SSD на той же базе прошла за 40 минут я думаю пора активно переходить на SSD.

11. mms76 74 30.01.15 16:08 Сейчас в теме

(10) TODD22, Живучесть SSD пока под вопросом

12. TODD22 19 30.01.15 16:20 Сейчас в теме

(11) mms76, Да у меня и винты в серверах HP из строя выходили. Хотя нагрузки на них особой то и не было.
Вполне нормально работают SSD. За тот прирост производительности что они дают я думаю можно доплатить за резервные винты. Не так уж это и накладно.

40. AlexanderKai 16.04.15 13:45 Сейчас в теме

(11) mms76,
На хабре где-то есть тест живучести.

64. vasyna 23.02.16 17:00 Сейчас в теме

(11) mms76, Живучесть HDD так же. У меня есть Segate чего-то там Enterprise встал просто так без предупреждения через 2 недели ( Спасибо raid ) Так что ssd в зеркале очень спасают.

60. Umix 132 16.02.16 20:51 Сейчас в теме

(10) TODD22, итак простое тестирование на чтение (формирование отчета) и запись (запись+проведение) документа на разных винтах на сервере HP PL380G8 показали, что HP SAS винты на секунды, но выигрывают
а дальше судите сами винт HP порядка 40-50 тыс. руб, ssd - кажется в половину меньше...
но было пару раз когда базы на ssd просто начинали сыпаться...
во и решайте сами

13. palsergeich 30.01.15 16:29 Сейчас в теме

PostgreSQL это конечно здорово, но до первого инцендента.
У нашего партнера - средней IT компании база 1с, которую они обслуживали сами (и сервак и 1с) на PostgreSQL сдохла, они так и не смогли ее завести.
Вытаскивал по таблицам сам, потерялось 2 справочника, слава богу это Сообщения электронной почты и Вложения электронной почты, ребята сказали ну и пес с ними, а если бы навернулось бы что нибудь более ценное?
По ошибке в мануале написано следующее - сделайте ваккуум, не поможет - ой. Естесственно ваккуум не помог.
По этому постгрес это недорохо, но нафиг надо, на маленькие базы - SQL express, IBM DB2 express (так же абсолютно бесплатные, причем DB2 даже поинтереснее будет 2 ядра и 2 гига в express, в отличии от 1и1 в MSSQL). На большие - их полные версии.
И помним что PostgreSQL при работе с 1с при автоматической блокировке блокирует на уровне таблиц, как файловая база, а не на уровне записи, а переписыватьи потом обновлять базы, как уже ранее было замечено, по затратам выйдет дороже.
Кроилово ВСЕГДА ведет к попадалову.

14. qwinter 683 30.01.15 16:36 Сейчас в теме

(13) palsergeich, а резервные копии их делать не учили? Подобные высказывания у меня только смех вызывают, и очень много говорит о таких "горе" специалистах.

15. palsergeich 30.01.15 16:39 Сейчас в теме

(14) qwinter, бекап есть ночной, база слетела вечером, дневные документы они не хотели терять. Им и нам было проще наш партнерский долг списать, тем более они никак не могли долго определиться, сколько же мы им должны.

16. AllexSoft 30.01.15 16:40 Сейчас в теме

(13) palsergeich,

И помним что PostgreSQL при работе с 1с при автоматической блокировке блокирует на уровне таблиц, как файловая база, а не на уровне записи.

ошибаетесь.. для управляемых блокировок на 8.3 с поддержкой версионников все ок, как и говорили выше. Новые конфиги все по умолчанию с управляемыми блокировками...

17. palsergeich 30.01.15 16:48 Сейчас в теме

(16) AllexSoft, тут неделю назад у одного моего заказчика, франч, который работает параллельно, обновил сервер до 8.3(я ХЗ что они сделали, но все ключи оказались запороты, и чистил все, помогла только полная перестановка сервера и повтороное лицензирование), я потом пол дня с 1с переписывался восстанавливал ключи и регистрационные данные (регистрационных данных нет, и как оказалось что там на каждую коробку по разному было заполнено,а коробок у них было ой как много и все резервные ключи были уже использованы).
Про новые конфиги знаю. но небольшие клиенты работают по принципу: работает - не трожь. Да и денежку за обновление рабочего сервера платят ой как неохотно.
Да и просто обновить сервер 1с, не уронив его, как оказалось еще и не каждый может)

18. AllexSoft 30.01.15 16:54 Сейчас в теме

(17) palsergeich, для программных лицензий

работает - не трожь.

это точно!
могу в копилку свой случай.. Поставили 1С в программной лицензией одному клиенту, на следующий день пришли к ним и установили КриптоПро, а для него надо было сервиспак на винду, разумеется ключ слетел, да причем слетел так что никакие шаманства не помогли, новый ключ активировался и первый раз все запускалось и работало, закрываешь 1С и пытаешься открыть снова - опять нет ключа.. ( с тех пор никому не советую программную лицензию

19. TODD22 19 30.01.15 18:03 Сейчас в теме

(17) palsergeich,

(я ХЗ что они сделали

Да это надо у 1С спрашивать :) То же сталкивался пару раз с тем что после обновления слетают программные лицензии.

20. qwinter 683 30.01.15 20:24 Сейчас в теме

(19) TODD22, надо документацию читать, тогда и таких вопросов не будет. Перекладываем файлы ключей перед установкой в любую из папок которые видят и 8.2 и 8.3 и никаких проблем.

22. alexandr1972_1 31.01.15 02:50 Сейчас в теме

Хорошая статья, запомним на будущее.

23. Pasha1st 849 31.01.15 19:21 Сейчас в теме

Обновил статью разделом про AUTOVACUUM.

24. q_i 584 01.02.15 00:38 Сейчас в теме

Есть прекрасная книга на русском языке о конфигурировании и оптимизировании PostgreSQL: http://postgresql.leopard.in.ua/

Ни в коем случае не хочу приуменьшать заслуги автора данной книги, но и промолчать не могу.
Впервые про эту книгу я узнал несколько лет назад, скачал, начал читать. Первые разделы читал с большим удовольствием, они были написаны грамотным, профессиональным языком. Потом в каких-то разделах начали попадаться опечатки, орфографические ошибки и ошибки пунктуации. Потом дошёл до разделов, текст которых вообще был похож на "машинный перевод". Автору тогда несколько раз высылал списки найденных ошибок и предложения по исправлению стилистики. Он оказался вполне конструктивным товарищем, и даже что-то из моих правок (а может и все или почти все - не знаю) включил в последующие редакции книги. Но в целом, у меня осталось впечатление о книге как о сборнике надёрганных откуда-то статей (если это так, то хотелось бы в книге видеть ссылки на исходные статьи; если же автор написал всё от начала до конца сам - извиняюсь за свои сомнения).
Ещё раз хочу сказать, что заслуга автора, на мой взгляд, огромна. По Postgres-у очень мало вообще хоть какой-то литературы на русском языке, а в этой книге автор сумел собрать материалы практически по всем аспектам, касающимся настройки и использования этой СУБД.
Тем не менее, от себя всем читающим рекомендую "доверять, но проверять", т.е. критически отнестись к информации, представленной в книге, а не рассматривать её как истину в последней инстанции.

25. baracuda 2 03.02.15 10:43 Сейчас в теме

Шикарная статья. Надеюсь когда нибудь дойдут руки перевести весь парк компьютеров нашего скромного предприятия на Unix.

26. Painted 49 04.02.15 14:53 Сейчас в теме

Хулителям Postgre хотелось бы напомнить, что, например, Skype использует именно Postgre. При этом ничего у них не падает и не теряется. Более того, я не слышал про крупные базы на MS SQL. Есть хоть одна база от 1ПБ на MS SQL ?

41. AlexanderKai 16.04.15 13:47 Сейчас в теме

(26) Painted,
Вероятно проблема не в PostgreSQL, а в 1С Предприятии.

27. serge_focus 4 04.02.15 15:06 Сейчас в теме

За раздел про Autovacuum автору отдельное СПАСИБО.
Я все собирал отдельные куски информации а тут написано достаточно доходчиво и все вместе.

28. alex_il 04.02.15 16:53 Сейчас в теме

для linux систем есть утилита pgtune, которая анализирует данные сервера и создает оптимальный конфиг, у нас база 1С около 80 Гб и порядка 120 одновременно работающих, тонкая настройка после утилиты существенного прироста не дала, а вот разнесение базы и xlog по разным массивам заметно ускоряет работу

53. Dimka74 05.11.15 09:12 Сейчас в теме

(28) alex_il,можно поподробнее, что вы сделали?

29. wolfsoft 2421 04.02.15 20:30 Сейчас в теме

Толку от этого "прекрасного PostgreSQL", если 1с при работе с ним иногда глючит непредсказуемым образом. Лично мне таких приключений не нуна, а так - "безумству храбрых поём мы соответствующую песню" ))

30. AllexSoft 05.02.15 10:03 Сейчас в теме

(29) wolfsoft,

если 1с при работе с ним иногда глючит непредсказуемым образом

поделитесь опытом что вы имеете в виду?

32. alex_il 08.02.15 10:08 Сейчас в теме

(29) wolfsoft, а что именно глючит в постгри? у нас она изначально планировалась использоваться, поэтому опыта по mssql нет, были проблемы на стадии внедрения и начала работы, но связаны были в основном с релизами 1с 8.2, начинали с 14-го, точно не помню, там где разделители появились. У нас 1С.Предприятие КАСУП (комплексная атоматизированная система управления предприятием) ведется в одной базе, но с использованием разделителей, в каждом конкретном филиале все было ОК, но если строить отчет по всей базе по регистру бухучета (т.е. в общем режиме без учета разделителя) это могло длиться часами(!) ТОнкая скрупулезная настройка постгри ничего не дала.Тогда уже и подумывали перейти на ms, пробовал подымать db2, но аналогично было и там. Кстати db2 работала медленней постгри, но видимо это связано с бесплатностью (ограничение на ресурсы). Так вот, решилось прописыванием дополнительных индексов руками, одновременно обратились в 1С с проблемой, они это решили не помню, вроде в 18 релизе, сейчас у нас 19 установлен. Еще были проблемы с серверами процессов - отваливались с периодичностью в неделю, но опять таки обновлением решилось. Сейчас все работает стабильно при среднем количестве пользователей 120-130, осталась проблема с аппаратным серверным ключем, но это из-за связки блайд-виртуализация, видно придется аппаратный usb-o-IP докупать, но это уже совсем другая история.

31. BAG211270 5 05.02.15 16:48 Сейчас в теме

Поделюсь своим опытом. Есть в эксплуатации и MS SQL 2012 и Postgres. Ставили их на одинаковые сервера. Так вот как ни крутили Postgres (мнеяли настройки, приглашали человека знающего), но все равно SQL быстрее оказалась в 2 с лишним раза. Так и делаем выгрузку базы с Postgres загружаем на SQL, делаем длительные опрации потом возвращаем обратно. Иначе за разумные сроки перепровести например документы за квартал на Postgres не получается.

33. alex_il 08.02.15 10:33 Сейчас в теме

(31) BAG211270, я с трудом представляю зачем перепроводить документы за квартал, но видно у вас такие условия. У нас баланс закрывается ежемесячно и при общем кол-ве бухов около 100 все строго регламентировано, например в середине месяца, следующего за отчетным всем кроме нескольких чел закрывается доступ на проведение документов отчетного месяца для закрытия баланса, отдельно год закрывается вообще для всех. Сейчас глянул за январь приходных накладных более 1200, расходных почти 2000, оказанных услуг более 6200...

38. BAG211270 5 05.03.15 11:21 Сейчас в теме

(33) alex_il,

У нас оперативный учет в другой программе ведется.. после загрузки все документов в бухгалтерию, чтобы правильно легли авансы, нужно перепровести все документы за период. Документов за месяц более 100000 шт.

Лишь поэтому.

34. tarassov 113 13.02.15 12:58 Сейчас в теме

Правильная статья. Сам работаю с Postgres. Думаю, что удастся взять из статьи полезное для себя.
Из нераскрытых моментов отметил бы вопросы резервного копирования. Postgres умеет на лету делать копии работающих баз в файл или сразу переливом в другую базу/на другой сервер. Мне удавалось таким образом перебрасывать данные между серверами Windows и Linux

35. svbel85 61 25.02.15 18:11 Сейчас в теме

Подскажите, у меня нет в каталоге programfiles/postgresql нет каталога data и файл postgresql.conf я тоже не найду

Прикрепленные файлы:

36. Pasha1st 849 25.02.15 19:09 Сейчас в теме

(35) svbel85, Через "панель управления" найдите "Администрирование", Службы, в списке служб - службу postgresql. В свойствах службы указан исполняемый файл с параметрами, например, так:
E:/Program Files/PostgreSQL/9.1/bin/pg_ctl.exe runservice -N "postgresql-x64-9.1" -D "E:/Program Files/PostgreSQL/9.1/data" -w
Собственно параметр после ключа -D и указывается где находятся конфиги и данные.

37. svbel85 61 25.02.15 19:38 Сейчас в теме

Большое спасибо

39. AlexandrIII 22.03.15 20:08 Сейчас в теме

При выборках у Postgres`a планировщик не всегда работает грамотно именно в реалиях 1С-а, но в целом с учетом спектра имеющихся настроек, добиться максимальной производительности которая не будет уступать MSSQL можно.

42. Veizdem 29.05.15 09:55 Сейчас в теме

Спасибо автору за столь детальную статью, попробовал поставить, вроде бы все нормально, но есть один нюанс. Когда выполняется НаборЗаписей.Записать(Истина) замедление работы 1с просто капитальное. Самым главным тормозом является блокировка, выполняется только это действие только 1 пользователя, все остальные пользователи сидят и ждут. Например документ "назисления з/п" операциями заполнение/расчет/проведение блокирует абсолютно все и всех и выполняется 2645 секунд! PostgreSQL использую версии 9.2.4 от 1С (скачаную с сайта 1С), версия самого 1С используется 8.3.5 и 8.3.6 (для пробы), все имеет разрядность х64, включая клиента. PostgreSQL установлена на CentOS, клиент на Kubuntu, сервер 1С на MS Server 2008 R2. htop на сервере БД показывает что максимально долго висит запрос DELETE. Подскажите пожалуйста, каким образом можно исправить этот недуг? Настраивал сервер БД точно по расчетам этой инструкции, ранее использовал 1С 8.2 и PostgreSQL 9.1.2 - все работало просто идеально, настраивал по сути так же. Может стоит попробовать версию БД 9.1.9? Или какие еще варианты есть? Помогите пожалуйста, кто поборол сего слона, начальство требует, а у меня из-за этого тормоза дела дальше не идут. И если брать Postgre от Ethersoft, то что именно качать из этого каталога?

43. qwinter 683 29.05.15 10:35 Сейчас в теме

(42) Veizdem, лучше попробуйте 9.3.4

44. Veizdem 29.05.15 10:36 Сейчас в теме

(43) qwinter, 9.3.4 чьей сборки?

45. qwinter 683 29.05.15 12:34 Сейчас в теме

(44) Veizdem, 1С конечно.

46. Veizdem 29.05.15 12:41 Сейчас в теме

(45) qwinter, так она же тестовая, нормально на ней держать боевой сервер?

47. qwinter 683 29.05.15 12:58 Сейчас в теме

(46) Veizdem, 9.3 вышел в релиз в 2013, она уже очень давно не тестовая. Если Вы смотрите на то, что она в тестовом столбце на users, то тогда все PostgreSQL от 1С можно считать тестовыми)))

50. Veizdem 29.05.15 13:06 Сейчас в теме

(47) qwinter, попробую, поставил на загрузку.

52. Veizdem 02.06.15 16:34 Сейчас в теме

(47) qwinter, установил 9.3 версию от 1С, теперь происходит следующее: пока работает 1 пользователь, все нормально, но если 2 человека делают что-то в зарплате, то htop показывает что одно подключение выполняет DELETE, а второе - LOCK TABLE waiting. Грубо говоря, все ждут пока кто-то удаляет. Как от подобного избавиться?

Утром еще проверил, оказывается LOCK TABLE waiting вылазит не только во время DELETE другого пользователя, но и при SELECT.

Нашел вот такую статью и оказалось что у меня стояла автоматическая блокировка, поставил управляемую - LOCK TABLE waiting пропал совсем.

57. kf1day 12.01.16 15:54 Сейчас в теме

(52) Veizdem, htop по умолчанию не обновляет статус запроса, висящий DELETE может означает, что он производился в момент запуска htop. Проверьте в настройках htop флаг "Update process names on every refresh" в разделе "Display options". Либо можно использовать связку watch/ps:

watch -n1 ps -vU postgres

48. tarassov 113 29.05.15 13:03 Сейчас в теме

(42) Veizdem,
У нас несколько лет стоит версия 9.1.2 64bit, сборка от 1С, взято было с https://users.v8.1c.ru/
Успели на нем последовательно перейти с 8.2 на 8.3.1, 8.3.4, 8.3.5

49. Veizdem 29.05.15 13:05 Сейчас в теме

(48) tarassov, у меня 1с 8.3.5 с postgresql 9.1.2 не завелся почему-то, ошибки выдавал, почитал просторы интернета - сказали лучше брать версию повыше.

51. Veizdem 29.05.15 13:07 Сейчас в теме

(48) tarassov, ну я еще разок попробую накатить 9.1.2, на 1с 8.2 с ней все отлично работало.

54. CERBER 26.11.15 17:45 Сейчас в теме

Подскажите как влияет изменение параметра в конфиге PostgreSQL
Поставил сервак на Win 2008 R2 64bit
Поставил PostgreSQL 64 bit
В конфиге есть раздел, при установке стоял рус язык и рус локаль.
Проинсталил, полез смотреть и править конфиг, по подобию уже имеющегося на CentOS, там оказалась прописанной локаль 'ru_RU.UTF-8'

# These settings are initialized by initdb, but they can be changed.
lc_messages = 'Russian_Russia.1251' # locale for system error message
# strings
lc_monetary = 'Russian_Russia.1251' # locale for monetary formatting
lc_numeric = 'Russian_Russia.1251' # locale for number formatting
lc_time = 'Russian_Russia.1251' # locale for time formatting

Заменил в конфиге postgresql на винде на 'ru_RU.UTF-8'
Получил
lc_messages = 'ru_RU.UTF-8' # locale for system error message
# strings
lc_monetary = 'ru_RU.UTF-8' # locale for monetary formatting
lc_numeric = 'ru_RU.UTF-8' # locale for number formatting
lc_time = 'ru_RU.UTF-8' # locale for time formatting

В итоге сервак posgtresql не стартует, в журнале винды ошибка с текстом "неправильное значение lc_time = 'ru_RU.UTF-8' ".
Откуда сервак понял, что это значение не правильное?
Где у него еще прописано с чем сравнивать?
Почему он под виндой не хочет в УТФе сохранять?
И насколько сильно этот параметр будет влиять на данные в базе?
Понимаю, что это всего лишь в какой кодировке будут храниться данные в базе постгри.

Данный сервак ставлю для РИБ узла в большом складе, а то там народ загибается по сети в файловом варианте работать.
При этом их узел обменивается с главным серваком на лиуксе. Надеюсь АдинЭска сама сообразит, что к чему. :-)
Хотя не ясно в какой кодировке данные храняться в файле 1Cv8.1CD

55. Pasha1st 849 04.12.15 11:44 Сейчас в теме

Под линуксом на официальном PG 9.2 у меня стоит и работает ru_RU.UTF-8, под Windows не должно бы отличаться. Насколько я помню, при установке PostgreSQL можно (и нужно) выбрать кодировку по умолчанию UTF-8. Если не ошибаюсь, эти параметры могут переопределяться, попробуйте базы создавать непосредственно из 1С (клиента или консоли администрирования сервера 1С). Или переустановите PG ;)

56. Borometr 11 11.01.16 08:10 Сейчас в теме

Postgre научил меня тому, что мало делать архивы, надо ещё и проверять - а разворачиваются ли они. Был неприятный случай у клиента - после внезапного отключения света база 1с перестала открываться. Попытался развернуть базу из свежего архива, ничего не поучилось. Начал проверять все архивы, смог развернуть базу из архива 2-х недельной давности. Из-за чего так произошло не знаю. Postgre ставил на Ubuntu 12.04 консоль.

58. Pasha1st 849 16.01.16 17:24 Сейчас в теме

(56) Borometr, это, в принципе, универсальное правило.
Я лечил базы MSSQL, которые успешно бекапились, восстанавливались, но содержали ошибку. В этом плане PG даже получше будет - можно бекапить не в бинарный формат а в текстовый, на выходе SQL-запросы. Такой файл можно просмотреть, понять что не даёт развернуть архив и отредактировать. Ну и получить определенную гарантию что база с физическими повреждениями как минимум предупредит при формировании бекапа.
В принципе, я только однажды столкнулся с тем что SQL-бекап базы PG (не 1С) не разворачивается - на таблицу было наложено ограничение типа "внешний ключ" через функцию (по некоторым причинам не было возможности использовать обычные внешние ключи), а в архиве таблица на которую были ссылки разворачивалась позже. В результате данные одной таблицы не были восстановлены. Но: 1. причина отображалась в логах восстановления, 2 - из бекапа я вырезал пропущенные данные и загрузил их отдельно.
Но в принципе это универсальное правило - бекапы надо не только делать, но и проверять.

59. shard 281 04.02.16 13:26 Сейчас в теме

Для запуска утилиты pg_test_fsync на линуксе необходимо явно указывать путь, к примеру /usr/lib/postgresql/9.2/bin/pg_test_fsync

61. starik-2005 3087 16.02.16 23:51 Сейчас в теме

Накатил с гитхаба последнюю дев-версию постгреса, собрал с -О3 и прочая для -native, пробую загрузить список недействительных паспортов - хочу с ними поиграться на предмет скорости выборки. Возникает вопрос: как затюнить такой постгрес? В принципе одна очень большая таблица ~100кк строк, 4 и 6 символов в каждой. 4-х символьное поле с индексом, 6-символьное - без.

62. alex_il 23.02.16 16:17 Сейчас в теме

В общую копилку знаний сброшу наши траблы с PG. Итак, выше я писал, работала 1С8.2 3 года на нашем территориально-распределенном предприятии, в одной базе бухучет, ЗП+кадры, автотранспорт и т.д., по сути самописная УПП. Постгри 9.2.1 от Этерсофт. Размер базы - более 120 Гб, пользователей в среднем тоже около 120. В связи с изменением структуры предприятия, изменением плана счетов решили с НГ старую базу закрыть и перейти на новую, заодно поменять на 8.3.6 (требования 1С-ников, что-то им надо было из функционала). Подняли 2 виртуальных сервера 1С 8.3.6 + PG 9.2.1 под дебиан 7, перешли. Далее началась веселуха - при создании/проведении документов не пересчитывались итоги (это уже потом определили напрямую ползая в субд по таблице итогов), 1С-ники клянутся, что в конфигурации все нормально и итогами они не управляют, а сама платформа, на 1С8.3.6 я не грешил, ибо если бы еще у кого это было, то стон стоял бы по всему интернету, админ говорит что постгри ничем не отличаются на старом/новом сервере и даже настройки одни. Как всегда, выяснилось случайно - старая база тоже переехала на новые сервера и активно использовалась в режиме просмотра данных за прошлый период, с итогами там все было нормально, но в последнее время там тоже стали вносить данные для закрытия года и итоги поплыли - значит конфигурация тоже ни при чем. Вечером выгнали всех пользователей и перенесли базу на старый сервер постгри - и о чудо, все стало работать нормально. Разбираясь детально установили, что на старом стояла версия PG postgre-etersoft9.2-server_9.2.1-eter1debian_i386.deb, а на новом postgre-etersoft9.2-server_9.2.1-eter8debian_i386. Вот такие чудеса. Сейчас тестируем постгри 9.4 от postgrespro.ru - пока впечатления приятные.

65. diger1 23.02.16 20:38 Сейчас в теме

При использовании Постгри следует помнить следующие моменты:
1)Использовать с 1с можно ТОЛЬКО дистрибутивы Посгри с оф.дисков ИТС.
2)Все обновления конфигураций ЖЕЛАТЕЛЬНО проводить после выгрузки базы в
файловый или MS SQL формат(первая рекомендация службы тех.поддержки 1с по поводу
ошибок с обновлением развернутых на нем Баз)

66. starik-2005 3087 23.02.16 21:44 Сейчас в теме

(65) diger1, кто-то ввел Вас в заблуждение по поводу 1-го пункта. Постгрес можно собрать руками - и он прекрасно будет работать с 1С, если на него накачены патчи от 1С: http://infostart.ru/public/460864/

А по поводу бэкапов перед обновлением - так это и ежу понятно.

67. volodya_gold 09.03.16 11:10 Сейчас в теме

Хорошая статья. Был опыт использования Postre 9.1 с патчем под 1с. Некоторое время все работало вообще без замечания. Но потом 1с начала вылетать с ошибкой "обнаружен UTF8 символ", при том что в файловом варианте все работало и до и после вообще без ошибок. Перелопатил всю базу, удалил вроде все эти непечатные символы, но ошибки участились и решили обратно вернуться в файловую. Сейчас тестирую 9.5.1, пока полет нормальный. :)

68. Betis 26 17.03.16 13:53 Сейчас в теме

Плюсанул. У меня вопрос: Можно ли чем-то анализировать планы запроса, кроме ТЖ, желательно еще и в графическом виде.

69. starik-2005 3087 17.03.16 18:06 Сейчас в теме

(68) Betis, https://wiki.postgresql.org/wiki/Using_EXPLAIN/ru

Существуют инструменты, упрощающие анализ вывода EXPLAIN:
pgAdmin включает инструмент визуализации вывода EXPLAIN. См. Интерпретация графического представления планов в PgAdmin.
Visual Explain, изначально выпущенный в составе компонента RedHat, и позже доработанный EnterpriseDB, сейчас поставляется в составе пакета EnterpriseDB Advanced Server. Его можно собрать для использования с PostgreSQL из исходного кода Developer Studio.
explain.depesz.com выводит план с акцентом на суммарные и промежуточные временные затраты и выбранные критерии.

70. tarassov 113 23.03.16 17:28 Сейчас в теме

Мне сейчас порекомендовали сайт со сборками инструментами постгресса https://www.postgrespro.ru/products/1c_build

71. torg1c 36 25.03.16 19:48 Сейчас в теме

Добавлю свою ложку опыта с Postgre. (1С 8.3.7, Postgre 9.4.2-1 (64бит) все на windows 7/64)

Обновление не типовой конфигурации стоящей на поддержке, процесс сравнения занял:
MS SQL 20 минут
POSTGRE 15 минут
Файловый режим 21 минута.

С Postgre произведены настройки памяти, fsync=off. Сервер 1С и сервер БД на одном компьютере.

72. kosikov_oleg 20.04.16 09:09 Сейчас в теме

Подскажите пожалуйста, как правильно (эффективно и надежно) организовать дисковое пространство для сервера 1С c Postgree на ubuntu сервере.
В сервере на борту имеется HDD большого объема и SDD небольшого.
1. Вариант. Журнал транзакций нужно располагать на SSD, а данные хранить на большом HDD. (SSD Использовать как кэш)
2. Вариант. Все делать на SSD и данные хранить и журнал.

И еще параллельный вопрос чтобы OC меньше влияла на производительность на какой диск в такой конфигурации сервера ее ставить?

74. Pasha1st 849 20.04.16 21:48 Сейчас в теме

(72) kosikov_oleg, Если объем SSD позволяет, можно на нём держать всё. Но несколько среднеразмерных баз актуальных релизов место будут хорошо подъедать. Я для себя остановился на таком варианте:
базы находятся на массиве из HDD (RAID6 в моём случае). Там находятся не только базы. Массив даёт отличную отказоустойчивость, хорошую скорость чтения и ужасную скорость записи ;)
два SSD по 60Гб объединил в зеркало. Разделил на два раздела - 40Гб и остаток. 40Гб отвел под Write-back кэш flashcache, остаток под прочие нужды. Включение кэша на запись сразу подняло производительность PG с 30-50 tps до 100 tps. Вынес журнал транзакция (x_log) на SSD - лучше не стало, flashcache достаточно эффективно ускоряет запись.
Журнал я все равно перенес и поднял количество CheckPoint.
Производительность измерял встроенной pgbench с указанием -T 20
Сразу советы:
1. flashcache в репозиториях 14.04 битый, надо брать с GIT, инструкции в интернете есть
2. write-back кэш стоит включать только на резервированных массивах, иначе отказ SSD рискует побить кэшируемые устройство. Если SSD в единственном экземпляре разумнее разместить на нём базы или журнал (с точки зрения производительности - если памяти достаточно закэшировать основные данные - достаточно журнала), постоянные бэкапы и готовность их разворачивать с потерей незакопированных данных

76. starik-2005 3087 20.04.16 21:54 Сейчас в теме

(74) а что так мало-то? У меня на ноуте:

Код
$pgbench -T 20 starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 1 query mode: simple number of clients: 1 number of threads: 1 duration: 20 s number of transactions actually processed: 29641 latency average: 0.675 ms tps = 1482.026139 (including connections establishing) tps = 1482.362037 (excluding connections establishing) Показать полностью

Код

$pgbench -T 20
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
duration: 20 s
number of transactions actually processed: 29641
latency average: 0.675 ms
tps = 1482.026139 (including connections establishing)
tps = 1482.362037 (excluding connections establishing)

Показать полностью

78. Pasha1st 849 20.04.16 23:53 Сейчас в теме

(76) starik-2005, НЕ ВЕРЮ
В смысле, база на рамдрайве, или fsync=off?
Или инициализировал тестовую базу нестандартно?

79. starik-2005 3087 21.04.16 12:33 Сейчас в теме

(78) инициализировал просто -i. SSD, fsync=off - это же ноутбук. Но на тест Гилева синк мало влияет, как я понял. А вот буст влияет весьма. При j10 c10 я при компиляции с -flto -O3 -march=native получал до 10 800 tps. При этом тест Гилева выдавал все те же 15 баллов. При cpu-frequency-set -g performance для всех ядер у меня тест Гилева стал выдавать 27.

80. Pasha1st 849 21.04.16 15:44 Сейчас в теме

(79) starik-2005, fsync=off это чит, не для боевого режима. Первый же сбой (питание, зависание и т.д.) практически гарантированно кладут базу. Оно мне надо?

81. starik-2005 3087 21.04.16 17:27 Сейчас в теме

(80) попробую с синком сегодня.

Но вообще, я замечал такую штуку: если кеша записи нет, то количество потоков, пишущих данные, сильно влияет на производительность (практически линейно). При включенном кеше производительность упирается в 5-6 потоков и дальше почти не растет.

С другой стороны, у Вас же должен как-то влиять кеш контроллера на производительности системы.

77. starik-2005 3087 20.04.16 21:59 Сейчас в теме

(74) а если ядра в перформенс выставить, то и вообще так:

Код
$ pgbench -T 20 starting vacuum...end. transaction type: TPC-B (sort of) scaling factor: 1 query mode: simple number of clients: 1 number of threads: 1 duration: 20 s number of transactions actually processed: 35376 latency average: 0.565 ms tps = 1768.244506 (including connections establishing) tps = 1768.417314 (excluding connections establishing) Показать полностью

Код

$ pgbench -T 20
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 1
number of threads: 1
duration: 20 s
number of transactions actually processed: 35376
latency average: 0.565 ms
tps = 1768.244506 (including connections establishing)
tps = 1768.417314 (excluding connections establishing)

Показать полностью

73. sml 41 20.04.16 10:47 Сейчас в теме

Спасибо за подробную статью автору, а также за комментарии имеющим опыт. ИМХО, ПГ - это наше будущее, а 1С в ближайшее время будет оптимизировать свою платформу под ПГ. Выход вин10 это только подтверждает

75. Pasha1st 849 20.04.16 21:52 Сейчас в теме

(73) sml, жду когда MS опубликует анонсированный MSSQL/Linux. Мне кажется что часть клиентов у PG он перехватит. На то что 1C дает альтернативу не может не радовать, PG заслуженно используется всё шире ИМХО.

82. ansh15 22.04.16 02:24 Сейчас в теме

Обычно в среде 1С про pgbench и не вспоминают, а инструмент простой и результаты доходчиво показывают где что и как.
Попробовал у себя, вот что получилось:

pgbench -c 1 -j 1 -T 60 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 550
query mode: simple
number of clients: 1
number of threads: 1
duration: 60 s
number of transactions actually processed: 210449
latency average: 0.285 ms
tps = 3507.445570 (including connections establishing)
tps = 3507.571432 (excluding connections establishing)

С включенным max_prepared_transactions

pgbench -c 1 -j 1 -T 60 -M prepared bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 550
query mode: prepared
number of clients: 1
number of threads: 1
duration: 60 s
number of transactions actually processed: 401899
latency average: 0.149 ms
tps = 6698.276030 (including connections establishing)
tps = 6698.481226 (excluding connections establishing)

83. ansh15 22.04.16 02:34 Сейчас в теме

То же самое 12 потоков и 24 клиентских соединения:

pgbench -c 24 -j 12 -T 60 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 550
query mode: simple
number of clients: 24
number of threads: 12
duration: 60 s
number of transactions actually processed: 2051360
latency average: 0.702 ms
tps = 34179.263553 (including connections establishing)
tps = 34182.738154 (excluding connections establishing)

pgbench -c 24 -j 12 -T 60 -M prepared bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 550
query mode: prepared
number of clients: 24
number of threads: 12
duration: 60 s
number of transactions actually processed: 3274456
latency average: 0.440 ms
tps = 54554.779699 (including connections establishing)
tps = 54559.822257 (excluding connections establishing)

Читал где-то, что prepare transaction в 1С не используется, так что просто для сравнения, посмотреть что может влиять на производительность...

84. tata\om 16.11.16 00:36 Сейчас в теме

Здравствуйте. Пишу, может быть, не по теме, но просто не знаю где еще. Всегда работал с файловыми базами и с sql опыта вообще нет.
На предприятии стояла MSSQL Express, но при достижении 4 гб послала лесом.
Пытаюсь поставить PostgreSQL. Использовал версии с оф сайта (9.6.1), с сайта портала 1с (9.4.2), со стороннего сайта (9.4.9 тоже адаптированного для 1с). Ставится без проблем, служба стартует, при запуске pgAdminIII подключение к серверу без проблем.
Ставлю сервак 1с (8.3.9.1850). Служба тоже стартует без проблем.
При создании базы через Администрирование серверов 1с вылезает ошибка:
Сервер баз данных не обнаружен
Fatal: no pg_hba.conf entry for host "fe80::cc88:48ff:8522:dd16%12", user "postgres", database "template1".
В pgAdmin открываю данный файл - вроде все нормально (как во всех описаниях).
При добавлении любой строки (допустим: local all all trust) сервер падает. Error connecting to the server: FATAL: could not load pg_hda.conf
При попытке корректировки (к примеру в строке host all all 127.0.0.1/32 md5 ставлю галочку включен и заменяю md5 на trust) ничего не меняется либо также падает сервер.
Пробовал на разных компах, внутри виртуалки, на компе с доменом, на компе вообще без сети, на серверных и обычных осях(ах да, только в win).
Что я упускаю? Делаю все как по инструкции (нашел несколько на просторах...).
Окна ошибки, создания базы и pg_hda.conf прикреплены.

Прикрепленные файлы:

Pictures.zip

85. Pasha1st 849 16.11.16 07:44 Сейчас в теме

(84) tataom, В pg_hba.conf описаны правила "доверия" пользователям. Действительно, по умолчанию отсутствуют правила для произвольного IPv6 адреса. Решения:
1. Вписать такое правило
2. Отключить IPv6 совсем на сервере. Если сервер 1С находится на этой же машине это из личного опыта практически настоятельная рекомендация
3. В свойствах базы явно указывать IP сервера с PG в формате IPv4. Если сервер 1С и PG находятся на одной машине, можно указать 127.0.0.1, всё равно клиентская часть напрямую к базе не подключается

87. quick 584 16.01.18 13:57 Сейчас в теме

Развернул рабочие базы в postgres и 1С в Docker. (7 баз, одна более 100Гб)
Часть ответственная за postgres выглядит так https://pastebin.com/Rgh2u3bf .
( Сохранить в docker-compose.yml и docker-compose -p test up -d )
Даже с дефолтными настройками производительность на уровне mssql, но при проведении некоторых документов сильно возрастает нагрузка. Пробую оптимизировать по вашей статье.
Если захотите использовать, не забудте пробросить порт postgres.
Если использовать docker то удобно иметь хоть несколько разных версий 1С на одном хосте в связки с любыми версиями postgres одновременно.

P.S. Оптимизированный вариант работает намного быстрее дефолтного, только не стал отключать autovacum. Спасибо за статью!

88. user946113 17.09.18 10:44 Сейчас в теме

Хорошая и полезная статья. Было бы еще лучше, если бы автор привел скорость работы PostgreSQL при стандартных настройках и после их оптимизации в conf-файле.

89. beard1 06.06.19 13:26 Сейчас в теме

Доброго!

просветите, пожалуйста, по параметру max_connection

что-то никак не складывается у меня картинка (

пусть есть 5 пользователей и 5 информационных баз 1С

каждый пользователь открыл 1 базу - сколько connection к PostgreSQL?
каждый пользователь открыл 5 баз - сколько connection к PostgreSQL?

и кроме того, на сервере 1С работают регламентные задания...

90. MaCCapAkIII 13.05.22 17:03 Сейчас в теме

Товарищи, приветствую. Установил связку Debian + PGPro + Server 1C. Настройки по умолчанию + добавил из PGTune. На сервере 128 Гб ОЗУ, 100 гигабитная сеть, 16 процессоров. Подключил базу ЗУП в полтора гигабайта размером - работает как черепаха, по полторы минуты загружает каждый документ. Аналогично работает pgAdmin 4 версии 6.9, очень медленно отображает данные и постоянно рвет соединение. Прошу подсказать хотя бы в какую сторону смотреть? Сеть или настройки? Буду признателен.

Прикрепленные файлы:

postgresql.conf

Оставьте свое сообщение

E-mail:

Автор:

(Pasha1st)

Рейтинг: 849

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 325482

Создание 29.01.15 19:20

Обновление 29.01.15 19:20

Статистика:

Просмотры 202659

Загрузки 0

Рейтинг 315

Комментарии 90

Характеристики:

Код открыт Не указано

Рубрики Инструменты администратора БД

Кому Системный администратор

Тип файла Нет файла

Платформа Платформа 1С v8.3

Конфигурация Не имеет значения

Операционная система PostgreSQL

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)