gifts2017

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

Опубликовал Pavel Fomin (Pasha1st) в раздел Администрирование - Системное

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

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

  1. Вступление
  2. Тестирование
  3. Конфигурирование
  4. Настройка использования памяти
  5. Настройка Autovacuum
  6. Настройка записи данных на диск
  7. Прочие настройки
  8. Заключение
  9. Полезные ссылки
  10. История правок статьи

Вступление

Я много работал с 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с

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

  1. После добавления третьего ядра PostgreSQL и MSSQL-варианты стали работать в тесте "два клиента" практически с производительностью теста "один клиент", т.е. удачно распараллелились. Что мешало им параллелить работу на двух ядрах для меня осталось загадкой.
  2. MSSQL памяти захватил сразу много, PostgreSQL требовал во всех режимах существенно меньше, и сразу после завершения выполнения запроса почти всю высвобождал.
  3. MSSQL работает единым процессом. PostgreSQL запускает по отдельному процессу на подключение+служебные процессы. Это позволяет даже 32-разрядному варианту эффективно использовать память при обработке запросов от нескольких клиентов.
  4. Увеличение памяти для PostgreSQL в настройках свыше указанных ниже значений не привело к заметному росту производительности.
  5. Первые тесты во всех случаях проходили дольше чем в последующих замерах, специально замеры не производил, но 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, добавлена ссылка на оригинальную документацию.

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

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение
Комментарии
1. борян петров (TODD22) 30.01.15 06:18
Я много работал с PostgreSQL и считаю его прекрасной СУБД. У меня многогигабайтная рабочая база (не 1С) обрабатывает моментально огромные массивы данных.

А опыт эксплуатации многогигабайтной рабочей базы есть?
А то проблема может быть не в СУБД. А в работе 1С с этой самой СУБД.
2. Pavel Fomin (Pasha1st) 30.01.15 08:09
(1) TODD22, у себя запускал относительно небольшие базы, а вот у пары знакомых 1С на PostgreSQL работает с крупными базами. Отзывы были положительные.
3. Михаил Курилов (MishaHD) 30.01.15 09:07
Пробежался мельком по статье, полезная, спасибо! Но в тексте нет ничего про блокировки. При взаимодействии Postgre и 1С, 1с не умеет выставлять блокировки на отдельные записи таблиц базы данных в режиме автоматических блокировок (актуально например для УТ 10.3), то есть всегда блокируется таблица целиком. Страдает производительность, причем на порядки, а самое неприятное что при большом объеме данных начинается проблема с deadlock. Получается два варианта: писать управляемые блокировки и переходить на MS SQL. Если у вас большая и сильно переписанная база, то экономически не целесообразно переписывать все под управляемые блокировки, проще перейти на MS SQL.
Вообще по моему мнению сейчас Postgre можно рассматривать как альтернативу файловой только на относительно небольшой базе с небольшим количеством пользователей.
4. Дмитрий Т (Dmitri_1C) 30.01.15 09:09
По опыту работы с PostgreSQL - это очень хорошая вещь, если конечно научить её пользоваться.
Я не ставил её на Windows, но в связке с Linux, даже при стандартных настройках работает замечательно.
Мне кажется, что на PostgreSQL жалуются только те, кто не смог разобраться как её устанавливать (установка её на Linux это отдельная история), вот и придумывают всё, чтоб народ даже не смотрел в сторону PostgreSQL.
5. Павел Алексеенко (qwinter) 30.01.15 11:03
(3) MishaHD, постгря версионник, он никогда не будет выставлять блокировки. Блокировки накладывает сервер 1С. И тут мы уже возвращаемся к уже измусоленному вопросу, что 1С поддерживает все остальные базы данных кроме мс на отъебись.
6. Павел Алексеенко (qwinter) 30.01.15 11:17
Статья не полная, по сути нет ничего полезного. Во первых почему не написана про параметры "Autovacuum"? Если с чего в постгре и начинать, то так именно с этого раздела. И раздел настроек "Planner Cost Constants" тоже не важен?))))
7. Алексей Белоусов (AllexSoft) 30.01.15 11:45
Спасибо за статью! Хорошо написано и разжевано именно то что нужно при настройке PostgreSQL + 1С. Собственно из своего опыта: по операциям чтения от PostgreSQL добиться неплохой производительности можно довольно просто - выставив подходящие параметры буферов и использования памяти.. обычно это получается почти сразу "на глаз".. а вот с записью беда( мне например пришлось полностью отключать fsync на операциях массовой перезаписи (при закрытии месяца - восстановление последовательности, при обновлении конфигурации) - вот тут PostgreSQL показала себя не с лучшей стороны, к сожалению замеров не делал но визуально с включенным fsync операции записи шли в 2 раза дольше чем на файловой, с отключенным fsync - сравнимо с файловой..
К автору - хотелось бы увидеть более детальное рассмотрение параметров связанных с синхронизацией транзакционных логов с базой и Autovacuum + сравнение файловой, PostgreSQL и MSSQL именно на операциях записи, потому что это узкое место PostgreSQL
8. борян петров (TODD22) 30.01.15 13:03
(4) Dmitri_1C,
Мне кажется, что на PostgreSQL жалуются только те, кто не смог разобраться как её устанавливать (установка её на Linux это отдельная история), вот и придумывают всё, чтоб народ даже не смотрел в сторону PostgreSQL.

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

У меня знакомый эксплуатировал слона на относительно небольшой базе... всё до определённого момента было хорошо. Потом появились какие то ошибки СУБД. С которыми он героически сражался и даже отсылал базу в 1С. После этого плюнул на этот гемор и завёл всё ms sql.
ShantinTD; +1 1 Ответить
9. Павел Алексеенко (qwinter) 30.01.15 15:24
(7) AllexSoft, не надо забывать, что PostgreSQL использует множество мелких файлов (отсюда и растут ноги многочисленных тормозов), поэтому при развертывании на linux надо подобрать соответствующую файловую систему которая быстро работает с мелкими файлами (перейдя с самой распространенной ext4 на ext3 можно получить 20-30% прироста производительности, а есть файловые системы которые с мелкими файлами работают еще быстрее), а для windows очень желателен SSD диск.
AllexSoft; +1 Ответить
10. борян петров (TODD22) 30.01.15 15:53
а для windows очень желателен SSD диск.

SSD диск желателен не только для винды. После того как у меня процедура чистки базы на зеркале из 2х HDD длилась около 5 часов и та же самая операция на SSD на той же базе прошла за 40 минут я думаю пора активно переходить на SSD.
2PRV; gigapevt; scarfase; +3 Ответить 2
11. Михаил Сединкин (mms76) 30.01.15 16:08
(10) TODD22, Живучесть SSD пока под вопросом
12. борян петров (TODD22) 30.01.15 16:20
(11) mms76, Да у меня и винты в серверах HP из строя выходили. Хотя нагрузки на них особой то и не было.
Вполне нормально работают 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) 30.01.15 16:36
(13) palsergeich, а резервные копии их делать не учили? Подобные высказывания у меня только смех вызывают, и очень много говорит о таких "горе" специалистах.
serge_focus; gfo; Spec1c82; 2PRV; sorb; +5 Ответить 1
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) 30.01.15 18:03
(17) palsergeich,
(я ХЗ что они сделали

Да это надо у 1С спрашивать :) То же сталкивался пару раз с тем что после обновления слетают программные лицензии.
20. Павел Алексеенко (qwinter) 30.01.15 20:24
(19) TODD22, надо документацию читать, тогда и таких вопросов не будет. Перекладываем файлы ключей перед установкой в любую из папок которые видят и 8.2 и 8.3 и никаких проблем.
21. Pavel Fomin (Pasha1st) 30.01.15 20:41
(6) qwinter, Дополню, напишу поподробнее про Autovacuum. Но первое, что надо делать, это именно настройка памяти - практика показывает что многие не читают даже рекомендаций 1С по настройке, не говоря уже об остальном. Planner Costs - это уже сверхтонкая настройка, результат которой зависит и от данных, и от запросов (читай - версии 1С), и от версии PostgreSQL, испортить производительность тут намного проще чем выиграть. Да и не ставил я задачи описать все возможности по настройке, заинтересовавшиеся могут сами изучить оставшиеся возможности.
(7) AllexSoft, постараюсь провести тестирование с добавлением/изменением данных, но быстро не получится, постараюсь в течении следующей недели сделать.
22. Александр Романов (alexandr1972_1) 31.01.15 02:50
Хорошая статья, запомним на будущее.
23. Pavel Fomin (Pasha1st) 31.01.15 19:21
Обновил статью разделом про AUTOVACUUM.
24. q_i 01.02.15 00:38
Есть прекрасная книга на русском языке о конфигурировании и оптимизировании PostgreSQL: http://postgresql.leopard.in.ua/

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

26. Марат Хафизов (Painted) 04.02.15 14:53
Хулителям Postgre хотелось бы напомнить, что, например, Skype использует именно Postgre. При этом ничего у них не падает и не теряется. Более того, я не слышал про крупные базы на MS SQL. Есть хоть одна база от 1ПБ на MS SQL ?
27. serge_focus (serge_focus) 04.02.15 15:06
За раздел про Autovacuum автору отдельное СПАСИБО.
Я все собирал отдельные куски информации а тут написано достаточно доходчиво и все вместе.
28. Alex Il (alex_il) 04.02.15 16:53
для linux систем есть утилита pgtune, которая анализирует данные сервера и создает оптимальный конфиг, у нас база 1С около 80 Гб и порядка 120 одновременно работающих, тонкая настройка после утилиты существенного прироста не дала, а вот разнесение базы и xlog по разным массивам заметно ускоряет работу
29. Антон Рощин (wolfsoft) 04.02.15 20:30
Толку от этого "прекрасного PostgreSQL", если 1с при работе с ним иногда глючит непредсказуемым образом. Лично мне таких приключений не нуна, а так - "безумству храбрых поём мы соответствующую песню" ))
30. Алексей Белоусов (AllexSoft) 05.02.15 10:03
(29) wolfsoft,
если 1с при работе с ним иногда глючит непредсказуемым образом

поделитесь опытом что вы имеете в виду?
31. Анатолий Быков (BAG211270) 05.02.15 16:48
Поделюсь своим опытом. Есть в эксплуатации и MS SQL 2012 и Postgres. Ставили их на одинаковые сервера. Так вот как ни крутили Postgres (мнеяли настройки, приглашали человека знающего), но все равно SQL быстрее оказалась в 2 с лишним раза. Так и делаем выгрузку базы с Postgres загружаем на SQL, делаем длительные опрации потом возвращаем обратно. Иначе за разумные сроки перепровести например документы за квартал на Postgres не получается.
32. Alex Il (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 докупать, но это уже совсем другая история.
33. Alex Il (alex_il) 08.02.15 10:33
(31) BAG211270, я с трудом представляю зачем перепроводить документы за квартал, но видно у вас такие условия. У нас баланс закрывается ежемесячно и при общем кол-ве бухов около 100 все строго регламентировано, например в середине месяца, следующего за отчетным всем кроме нескольких чел закрывается доступ на проведение документов отчетного месяца для закрытия баланса, отдельно год закрывается вообще для всех. Сейчас глянул за январь приходных накладных более 1200, расходных почти 2000, оказанных услуг более 6200...
34. Дмитрий Тарасов (tarassov) 13.02.15 12:58
Правильная статья. Сам работаю с Postgres. Думаю, что удастся взять из статьи полезное для себя.
Из нераскрытых моментов отметил бы вопросы резервного копирования. Postgres умеет на лету делать копии работающих баз в файл или сразу переливом в другую базу/на другой сервер. Мне удавалось таким образом перебрасывать данные между серверами Windows и Linux
35. Сергей Беленченко (svbel85) 25.02.15 18:11
Подскажите, у меня нет в каталоге programfiles/postgresql нет каталога data и файл postgresql.conf я тоже не найду



Прикрепленные файлы:
36. Pavel Fomin (Pasha1st) 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) 25.02.15 19:38
38. Анатолий Быков (BAG211270) 05.03.15 11:21
(33) alex_il,

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

Лишь поэтому.
39. Александр (AlexandrIII) 22.03.15 20:08
При выборках у Postgres`a планировщик не всегда работает грамотно именно в реалиях 1С-а, но в целом с учетом спектра имеющихся настроек, добиться максимальной производительности которая не будет уступать MSSQL можно.
40. Александр Топольский (AlexanderKai) 16.04.15 13:45
(11) mms76,
На хабре где-то есть тест живучести.
41. Александр Топольский (AlexanderKai) 16.04.15 13:47
(26) Painted,
Вероятно проблема не в PostgreSQL, а в 1С Предприятии.
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) 29.05.15 10:35
(42) Veizdem, лучше попробуйте 9.3.4
44. Александр Скиф (Veizdem) 29.05.15 10:36
45. Павел Алексеенко (qwinter) 29.05.15 12:34
46. Александр Скиф (Veizdem) 29.05.15 12:41
(45) qwinter, так она же тестовая, нормально на ней держать боевой сервер?
47. Павел Алексеенко (qwinter) 29.05.15 12:58
(46) Veizdem, 9.3 вышел в релиз в 2013, она уже очень давно не тестовая. Если Вы смотрите на то, что она в тестовом столбце на users, то тогда все PostgreSQL от 1С можно считать тестовыми)))
48. Дмитрий Тарасов (tarassov) 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 не завелся почему-то, ошибки выдавал, почитал просторы интернета - сказали лучше брать версию повыше.
50. Александр Скиф (Veizdem) 29.05.15 13:06
(47) qwinter, попробую, поставил на загрузку.
51. Александр Скиф (Veizdem) 29.05.15 13:07
(48) tarassov, ну я еще разок попробую накатить 9.1.2, на 1с 8.2 с ней все отлично работало.
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 пропал совсем.
WellMaster; +1 Ответить 1
53. Dimka74 Dimka174 (Dimka74) 05.11.15 09:12
(28) alex_il,можно поподробнее, что вы сделали?
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. Pavel Fomin (Pasha1st) 04.12.15 11:44
Под линуксом на официальном PG 9.2 у меня стоит и работает ru_RU.UTF-8, под Windows не должно бы отличаться. Насколько я помню, при установке PostgreSQL можно (и нужно) выбрать кодировку по умолчанию UTF-8. Если не ошибаюсь, эти параметры могут переопределяться, попробуйте базы создавать непосредственно из 1С (клиента или консоли администрирования сервера 1С). Или переустановите PG ;)
56. Рустам (Borometr) 11.01.16 08:10
Postgre научил меня тому, что мало делать архивы, надо ещё и проверять - а разворачиваются ли они. Был неприятный случай у клиента - после внезапного отключения света база 1с перестала открываться. Попытался развернуть базу из свежего архива, ничего не поучилось. Начал проверять все архивы, смог развернуть базу из архива 2-х недельной давности. Из-за чего так произошло не знаю. Postgre ставил на Ubuntu 12.04 консоль.
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
58. Pavel Fomin (Pasha1st) 16.01.16 17:24
(56) Borometr, это, в принципе, универсальное правило.
Я лечил базы MSSQL, которые успешно бекапились, восстанавливались, но содержали ошибку. В этом плане PG даже получше будет - можно бекапить не в бинарный формат а в текстовый, на выходе SQL-запросы. Такой файл можно просмотреть, понять что не даёт развернуть архив и отредактировать. Ну и получить определенную гарантию что база с физическими повреждениями как минимум предупредит при формировании бекапа.
В принципе, я только однажды столкнулся с тем что SQL-бекап базы PG (не 1С) не разворачивается - на таблицу было наложено ограничение типа "внешний ключ" через функцию (по некоторым причинам не было возможности использовать обычные внешние ключи), а в архиве таблица на которую были ссылки разворачивалась позже. В результате данные одной таблицы не были восстановлены. Но: 1. причина отображалась в логах восстановления, 2 - из бекапа я вырезал пропущенные данные и загрузил их отдельно.
Но в принципе это универсальное правило - бекапы надо не только делать, но и проверять.
59. shard (shard) 04.02.16 13:26
Для запуска утилиты pg_test_fsync на линуксе необходимо явно указывать путь, к примеру /usr/lib/postgresql/9.2/bin/pg_test_fsync
60. UMix У (Umix) 16.02.16 20:51
(10) TODD22, итак простое тестирование на чтение (формирование отчета) и запись (запись+проведение) документа на разных винтах на сервере HP PL380G8 показали, что HP SAS винты на секунды, но выигрывают
а дальше судите сами винт HP порядка 40-50 тыс. руб, ssd - кажется в половину меньше...
но было пару раз когда базы на ssd просто начинали сыпаться...
во и решайте сами
61. Sergey Andreev (starik-2005) 16.02.16 23:51
Накатил с гитхаба последнюю дев-версию постгреса, собрал с -О3 и прочая для -native, пробую загрузить список недействительных паспортов - хочу с ними поиграться на предмет скорости выборки. Возникает вопрос: как затюнить такой постгрес? В принципе одна очень большая таблица ~100кк строк, 4 и 6 символов в каждой. 4-х символьное поле с индексом, 6-символьное - без.
62. Alex Il (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 - пока впечатления приятные.
63. Василий Залукаев (vasyna) 23.02.16 16:53
(4) Dmitri_1C, а что там сложного? Там и без мануалов раз-два и готово. А с ними и того проще. Я ставил года 4 назад знакомым. Они с фс по сети и 5 пользователей по 2 минуты ждали открытия или проведения документа. 4 часа и я им поставил ubuntu server + PostgreSQL + 1с Сервер + webMin (там же влепил архивацию базы и на ваял скриптик который каталагизировал архивы). Ни чего сложного. Конечно работать стало быстрее и комфортнее, но потом сервер изъяли и купили такое же железо, но уже взяли лицуху на 1с и sql сервер и вот там вот действительно увидели разницу.
64. Василий Залукаев (vasyna) 23.02.16 17:00
(11) mms76, Живучесть HDD так же. У меня есть Segate чего-то там Enterprise встал просто так без предупреждения через 2 недели ( Спасибо raid ) Так что ssd в зеркале очень спасают.
65. diger diger (diger1) 23.02.16 20:38
При использовании Постгри следует помнить следующие моменты:
1)Использовать с 1с можно ТОЛЬКО дистрибутивы Посгри с оф.дисков ИТС.
2)Все обновления конфигураций ЖЕЛАТЕЛЬНО проводить после выгрузки базы в
файловый или MS SQL формат(первая рекомендация службы тех.поддержки 1с по поводу
ошибок с обновлением развернутых на нем Баз)
66. Sergey Andreev (starik-2005) 23.02.16 21:44
(65) diger1, кто-то ввел Вас в заблуждение по поводу 1-го пункта. Постгрес можно собрать руками - и он прекрасно будет работать с 1С, если на него накачены патчи от 1С: http://infostart.ru/public/460864/

А по поводу бэкапов перед обновлением - так это и ежу понятно.
67. volodya (volodya_gold) 09.03.16 11:10
Хорошая статья. Был опыт использования Postre 9.1 с патчем под 1с. Некоторое время все работало вообще без замечания. Но потом 1с начала вылетать с ошибкой "обнаружен UTF8 символ", при том что в файловом варианте все работало и до и после вообще без ошибок. Перелопатил всю базу, удалил вроде все эти непечатные символы, но ошибки участились и решили обратно вернуться в файловую. Сейчас тестирую 9.5.1, пока полет нормальный. :)
68. Игорь Шкурин (Betis) 17.03.16 13:53
Плюсанул. У меня вопрос: Можно ли чем-то анализировать планы запроса, кроме ТЖ, желательно еще и в графическом виде.
69. Sergey Andreev (starik-2005) 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 выводит план с акцентом на суммарные и промежуточные временные затраты и выбранные критерии.
tarassov; +1 Ответить
70. Дмитрий Тарасов (tarassov) 23.03.16 17:28
Мне сейчас порекомендовали сайт со сборками инструментами постгресса https://www.postgrespro.ru/products/1c_build
71. torg1c (torg1c) 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С и сервер БД на одном компьютере.
kosikov_oleg; +1 Ответить
72. Олег Козиков (kosikov_oleg) 20.04.16 09:09
Подскажите пожалуйста, как правильно (эффективно и надежно) организовать дисковое пространство для сервера 1С c Postgree на ubuntu сервере.
В сервере на борту имеется HDD большого объема и SDD небольшого.
1. Вариант. Журнал транзакций нужно располагать на SSD, а данные хранить на большом HDD. (SSD Использовать как кэш)
2. Вариант. Все делать на SSD и данные хранить и журнал.

И еще параллельный вопрос чтобы OC меньше влияла на производительность на какой диск в такой конфигурации сервера ее ставить?
73. Олег Веселов (sml) 20.04.16 10:47
Спасибо за подробную статью автору, а также за комментарии имеющим опыт. ИМХО, ПГ - это наше будущее, а 1С в ближайшее время будет оптимизировать свою платформу под ПГ. Выход вин10 это только подтверждает
74. Pavel Fomin (Pasha1st) 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 в единственном экземпляре разумнее разместить на нём базы или журнал (с точки зрения производительности - если памяти достаточно закэшировать основные данные - достаточно журнала), постоянные бэкапы и готовность их разворачивать с потерей незакопированных данных
kosikov_oleg; +1 Ответить 2
75. Pavel Fomin (Pasha1st) 20.04.16 21:52
(73) sml, жду когда MS опубликует анонсированный MSSQL/Linux. Мне кажется что часть клиентов у PG он перехватит. На то что 1C дает альтернативу не может не радовать, PG заслуженно используется всё шире ИМХО.
76. Sergey Andreev (starik-2005) 20.04.16 21:54
(74) Pasha1st, а что так мало-то? У меня на ноуте:

Код
$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)
Показать полностью
77. Sergey Andreev (starik-2005) 20.04.16 21:59
(74) Pasha1st, а если ядра в перформенс выставить, то и вообще так:
Код
$ 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)
Показать полностью
78. Pavel Fomin (Pasha1st) 20.04.16 23:53
(76) starik-2005, НЕ ВЕРЮ
В смысле, база на рамдрайве, или fsync=off?
Или инициализировал тестовую базу нестандартно?
79. Sergey Andreev (starik-2005) 21.04.16 12:33
(78) Pasha1st, инициализировал просто -i. SSD, fsync=off - это же ноутбук. Но на тест Гилева синк мало влияет, как я понял. А вот буст влияет весьма. При j10 c10 я при компиляции с -flto -O3 -march=native получал до 10 800 tps. При этом тест Гилева выдавал все те же 15 баллов. При cpu-frequency-set -g performance для всех ядер у меня тест Гилева стал выдавать 27.
80. Pavel Fomin (Pasha1st) 21.04.16 15:44
(79) starik-2005, fsync=off это чит, не для боевого режима. Первый же сбой (питание, зависание и т.д.) практически гарантированно кладут базу. Оно мне надо?
81. Sergey Andreev (starik-2005) 21.04.16 17:27
(80) Pasha1st, попробую с синком сегодня.

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

С другой стороны, у Вас же должен как-то влиять кеш контроллера на производительности системы.
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. Pavel Fomin (Pasha1st) 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, всё равно клиентская часть напрямую к базе не подключается