Какую ОС установить:

Процессор

Количество процессов автовакуума. Общее правило — чем больше write-запросов, тем больше процессов. На read-only базе данных достаточно одного процесса.

Ssl = off

Выключение шифрования. Для защищенных ЦОД’ов шифрование бессмысленно, но приводит к увеличению загрузки CPU

Память

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

Temp_buffers = 256MB

Максимальное количество страниц для временных таблиц. Т.е. это верхний лимит размера временных таблиц в каждой сессии.

Work_mem = RAM/32..64 или 32MB..128MB

Лимит памяти для обработки одного запроса. Эта память индивидуальна для каждой сессии. Теоретически, максимально потребная память равна max_connections * work_mem, на практике такого не встречается потому что большая часть сессий почти всегда висит в ожидании. Это рекомендательное значение используется оптимайзером: он пытается предугадать размер необходимой памяти для запроса, и, если это значение больше work_mem, то указывает экзекьютору сразу создать временную таблицу. work_mem не является в полном смысле лимитом: оптимайзер может и промахнуться, и запрос займёт больше памяти, возможно в разы. Это значение можно уменьшать, следя за количеством создаваемых временных файлов:

Maintenance_work_mem = RAM/16..32 или work_mem * 4 или 256MB..4GB

Лимит памяти для обслуживающих задач, например по сбору статистики (ANALYZE), сборке мусора (VACUUM), создания индексов (CREATE INDEX) и добавления внешних ключей. Размер выделяемой под эти операции памяти должен быть сравним с физическим размером самого большого индекса на диске.

Effective_cache_size = RAM - shared_buffers

Оценка размера кеша файловой системы. Увеличение параметра увеличивает склонность системы выбирать IndexScan планы. И это хорошо.

Диски

Оценочное значение одновременных запросов к дисковой системе, которые она может обслужить единовременно. Для одиночного диска = 1, для RAID — 2 или больше.

Random_page_cost = 1.5-2.0 для RAID, 1.1-1.3 для SSD, 0.1 для NVMe

Стоимость чтения рандомной страницы (по-умолчанию 4). Чем меньше seek time дисковой системы тем меньше (но > 1.0) должен быть этот параметр. Излишне большое значение параметра увеличивает склонность PgSQL к выбору планов с сканированием всей таблицы (PgSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс). И это плохо.

Seq_page_cost = 0.1 для NVMe дисков autovacuum = on

Включение автовакуума.

Autovacuum_naptime = 20s

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

Bgwriter_delay = 20ms

Время сна между циклами записи на диск фонового процесса записи. Данный процесс ответственен за синхронизацию страниц, расположенных в shared_buffers с диском. Слишком большое значение этого параметра приведет к возрастанию нагрузки на checkpoint процесс и процессы, обслуживающие сессии (backend). Малое значение приведет к полной загрузке одного из ядер.

Bgwriter_lru_multiplier = 4.0 bgwriter_lru_maxpages = 400

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

Synchronous_commit = off

Выключение синхронизации с диском в момент коммита. Создает риск потери последних нескольких транзакций (в течении 0.5-1 секунды), но гарантирует целостность базы данных, в цепочке коммитов гарантированно отсутствуют пропуски. Но значительно увеличивает производительность.

Checkpoint_segments = 32..256 < 9.5

Максимальное количество сегментов WAL между checkpoint. Слишком частые checkpoint приводят к значительной нагрузке на дисковую подсистему по записи. Каждый сегмент имеет размер 16MB

Checkpoint_completion_target = 0.5..0.9

Степень «размазывания» checkpoint’a. Скорость записи во время checkpoint’а регулируется так, что бы время checkpoint’а было равно времени, прошедшему с прошлого, умноженному на checkpoint_completion_ target.

Min_wal_size = 512MB .. 4G > =9.5 max_wal_size = 2 * min_wal_size > =9.5

Минимальное и максимальный объем WAL файлов. Аналогично checkpoint_segments

Fsync = on

Выключение параметра приводит к росту производительности, но появляется значительный риск потери всех данных при внезапном выключении питания. Внимание: если RAID имеет кеш и находиться в режиме write-back, проверьте наличие и функциональность батарейки кеша RAID контроллера! Иначе данные записанные в кеш RAID могут быть потеряны при выключении питания, и, как следствие, PgSQL не гарантирует целостность данных.

Commit_delay = 1000

паузу (в микросекундах) перед собственно выполнением сохранения WAL

Commit_siblings = 5

Минимальное число одновременно открытых транзакций, при котором будет добавляться задержка commit_delay

Групповой коммит нескольких транзакций. Имеет смысл включать, если темп транзакций превосходит 1000 TPS. Иначе эффекта не имеет.

Temp_tablespaces = "NAME_OF_TABLESPACE"

Дисковое пространство для временных таблиц/индексов. Помещение временных таблиц/индексов на отдельные диски может увеличить производительность. Предварительно надо создать tablespace командой CREATE TABLESPACE. Если характеристики дисков отличаются от основных дисков, то следует в команде указать соответствующий random_page_ cost. См. .

row_security = off >= 9.5

Отключение контроля разрешения уровня записи

Max_files_per_process = 1000 (default)

Максимальное количество открытых файлов на один процесс PostreSQL. Один файл это как минимум либо индекс либо таблица, но таблица/может состоять из нескольких файлов. Если PostgreSQL упирается в этот лимит, он начинает открывать/закрывать файлы, что может сказываться на производительности. Диагностировать проблему под Linux можно с помощью команды lsof.

Сеть

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

Типовая проблема в Windows

Ошибка СУБД: could not send data to server: No buffer space available (0x00002747/10055)

При использовании операционной системы Windows, максимальное стандартное число временных TCP-портов равно 5000. При попытке установить TCP-соединение через порты, номера которых превышают 5000, выдается сообщение об ошибке. Другими словами, надо увеличить количество доступных портов в реестре, где выберите Parameters (HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ Tcpip\Parameters) и добавьте следующий параметр реестра MaxUserPort с типом: DWORD и значением: 65534 (Допустимые значения: 5000-65534)

Блокировки

Максимальное число блокировок индексов/таблиц в одной транзакции

Настройки под платформу 1С

Разрешить использовать символ \ для экранирования

Escape_string_warning = off

Не выдавать предупреждение о использовании символа \ для экранирования

Shared_preload_libraries = "online_analyze, plantuner"

несколько разделяемых библиотек, которые будут загружаться при запуске сервера
если указанная в нём библиотека не будет найдена, сервер не запустится
настройка параметра имеет больше значения для linux, хотя и windows её делать тоже стоит

Модуль online_analyze предоставляет набор функций, которые немедленно обновляют статистику после операций INSERT, UPDATE, DELETE или SELECT INTO в целевых таблицах.
Модуль plantuner добавляет поддержку указаний для планировщика, позволяющих отключать или подключать определённые индексы при выполнении запроса.

Online_analyze.enable = on

Включает анализ статистики временных таблиц, часто используемых в 1С

Оптимизатор

(Улучшение статистики оптимизатора)

Enable_nestloop=off, enable_mergejoin=off

(Изменение параметров оптимизатора)
● Включает или отключает использование планировщиком планов соединения с вложенными циклами
● Включает или отключает использование планов соединения слиянием.
Например ошибки типа out of memory

Join_collapse_limit=1

(отключение при понимании порядка соединений таблиц!)
● При значении, равном 1, предложения JOIN переставляться не будут, так что явно заданный в запросе порядок
соединений определит фактический порядок, в котором будут соединяться отношения.
Прочие настройки влияющие на оптимизатор

From_collapse_limit = 20

● Задаёт максимальное количество элементов в списке FROM, до достижения которого планировщик будет сносить в него явные конструкции JOIN (за исключением FULL JOIN). При меньших значениях сокращается время планирования, но план запроса может стать менее эффективным.
● seq_page_cost = 0.1 random_page_cost = 0.4 cpu_operator_cost = 0.00025

Online_analyze.table_type = "all"

(больше нагрузка)
Типы таблиц, для которых выполняется немедленный анализ: all (все), persistent (постоянные), temporary (временные), none (никакие).

Online_analyze.threshold = 50

● Минимальное число изменений строк, после которого может начаться немедленный анализ (этот параметр подобен autovacuum_analyze_threshold).

Online_analyze.scale_factor = 0.1

Процент от размера таблицы, при котором начинается немедленный анализ (этот параметр подобен autovacuum_analyze_scale_factor).

Online_analyze.min_interval = 10000

● Минимальный интервал времени между вызовами ANALYZE для отдельной таблицы (в миллисекундах).

Online_analyze.local_tracking = off

● Включает в online_analyze отслеживание временных таблиц в рамках обслуживающего процесса. Когда эта переменная отключена (off), online_analyze использует для временных таблиц системную статистику по умолчанию.

Online_analyze.verbose = "off"

● Отключает подробные сообщения расширения online_analyze

Plantuner.fix_empty_table = "on"

● plantuner будет обнулять число страниц/кортежей в таблице, которая не содержит никаких блоков в файле

PostgreSQL — достаточно современная и популярная СУБД в мире. Её не обошла и фирма 1С, выбрав в качестве одной из поддерживаемых для работы СУБД. Рассмотрим инструкцию по установке PostgreSQL и её первоначальной 8.3 под ОС Windows.

PostgreSQL — бесплатная программа, это является одним из решающих факторов по выбору данной СУБД.

Для установки сервера нам понадобится два архива — предприятия (х86-64) и дистрибутив PostgreSQL. В нашем примере платформа версии 8.3.4, а СУБД 9.1.2. Их лучше взять из официальных источников 1С — диска или сайта ИТС.

Первым делом предприятия 8.3 (или 8.2). Для этого запустим файл setup.exe из архива. Установка мало чем отличается от обычной установки клиентского приложения, за исключением некоторых особенностей:

1. Не забудьте выбрать в компонентах нужные пункты:

2. Указать, от чьего имени будет запускаться приложение. Рекомендуется создавать нового пользователя «USR1Cv8». У этого пользователя должны быть установлены нужные права:

Получите 267 видеоуроков по 1С бесплатно:

После установки части 1С можно приступить к работе с СУБД.

Установка PostgreSQL

Запустите файл postgresql-9.1.2-1.1C(x64).msi, в папке windows выбрать подпапку 64 или 86, в зависимости от разрядности ОС. Можно оставить практически всё по умолчанию. Необходимо обратить внимание на следующие моменты:

1. Так же, как с 1С 8.3, СУБД устанавливается как сервис. Необходимо проверить права у используемого пользователя. Система по умолчанию создаст нового пользователя, от чего имени будет запускать службу:

2. Настройка кластера 1C. Здесь необходимо указать пароль для пользователя:

Для выполнения данного пункта должна быть запущена служба «Вторичный вход в систему» (secondary logon). Если он не запущен, его следует запустить в списке всех сервисов:

Создание базы 1С на Постгри

Создание базы — очень простой процесс. В списке баз необходимо нажать «Добавить», выбрать пункт «Создание новой информационной базы», указать название базы и выбрать вариант расположения — «На сервере 1С: Предприятия», где заполнить настройки подобно указанным на скриншоте:

Где пароль и имя пользователя те, которые Вы указывали на этапе настройки кластера.

Вот и всё — можно работать с системой.

Как только размер файловой базы данных 1С:Предприятие одного из наших клиентов достиг размера в 32Гб (да, 32Гб), в следствии чего всё постепенно начало тормозить, а потом и встало намертво, наши клиенты попросили нас решить эту проблемы. SSD Enterprise класса ненадолго подсластил пилюлю, но через некоторое время всё вернулось в исходную точку. Ну что ж, тут и к бабке не ходи – переходим на SQL версию БД.

Поскольку мы ярые пользователи Windows, доступно нам только два варианта СУБД – это MSSql и PostgreSQL. Первый хорош до безумия, но стоимость не порадовала. А ещё больше не порадовала новость о дополнительных лицензиях 1С для работы с MSSQL. Поэтому PostgreSQL.

Подробная инструкция с видео доступна . В этой статье мы пройдёмся по ключевым моментам.

Не забываем про баз данных 1С!

Исходные данные:

• ОС Windows Server 2008R2,
• Intel Core i7-2600K 3.40GHz,
• 32Gb RAM,
• Intel SSD DC3700 100Gb (только под БД, ОС на отдельном SSD),
• от 10 до 20 пользователей в БД ежедневно,
• обмен с 5 узлами распределённой БД в фоне.

Зловеще, не правда ли? Приступим.

1. Установка PostgreSQL и pgAdmin.

Никаких откровений по поводу того, откуда качать PostgreSQL не будет — это наш любимый сайт https://releases.1c.ru , раздел «Технологические дистрибутивы». Скачиваем, ставим. Не забываем установить MICROSOFT VISUAL C++ 2010 RUNTIME LIBRARIES WITH SERVICE PACK 1, который идёт в архиве с дистрибутивом. Сами попались на это: не установили, испытали много боли.

Инициализируем кластер базы данных (галочка). А вот здесь задаём параметры учётной записи для PostgreSQL! Важно: у Вас должна быть запущена служба «Secondary Logon» (или на локализированных ОС: «Вторичный вход в систему» ). Кодировка UTF8 — это тоже важно!

pgAdmin в этой сборке староват. Идём на https://www.postgresql.org/ftp/pgadmin3/release/ . На момент написания статьи самая свежая версия 1.22.1. Качаем её, ставим. Заходим.

На процессе установки оснастки «Администрирование серверов 1С Предприятия» не будем останавливаться. Это совсем другая тема. Да и сложного там ничего нет.

Создаём SQL БД в этой оснастке, проверяем в pgAdmin — БД там появиться, если всё указано верно.

2. Тюнинг PostgreSQL 9.4.2.

• pg_hba.conf
• postgresql.conf
• pgpass.conf

которые лежат здесь:

C:\Program Files\PostgreSQL\9.4.2-1.1C\data

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

Для правки конфига есть удобный инструмент, доступный прямо из главного окна pgAdmin. Вот он:

Что мы здесь меняем:

• shared_buffers — Количество памяти, выделенной PgSQL для совместного кеша страниц. Эта память разделяется между всеми процессами PgSQL. Делим доступную ОЗУ на 4. В нашем случае это 8Gb.
• effective_cache_size — Оценка размера кэша файловой системы. Считается так: ОЗУ — shared_buffers. В нашем случае это 32Gb — 8Gb = 24Gb. Но лично я оставляю этот параметр ещё ниже, где-то 20Gb — всё-таки ОЗУ нужна не только для PostgreSQL.
• random_page_cost = 1.5 — 2.0 для RAID, 1.1 — 1.3 для SSD. Стоимость чтения рандомной страницы (по-умолчанию 4). Чем меньше seek time дисковой системы тем меньше (но > 1.0) должен быть этот параметр. Излишне большое значение параметра увеличивает склонность PgSQL к выбору планов с сканированием всей таблицы (PgSQL считает, что дешевле последовательно читать всю таблицу, чем рандомно индекс). И это плохо.
• temp_buffers = 256Mb . Максимальное количество страниц для временных таблиц. То есть это верхний лимит размера временных таблиц в каждой сессии.
• work_mem — Считается так: ОЗУ / 32..64 — в нашем случае получается 1Gb . Лимит памяти для обработки одного запроса. Эта память индивидуальна для каждой сессии. Теоретически, максимально потребная память равна max_connections * work_mem, на практике такого не встречается потому что большая часть сессий почти всегда висит в ожидании.
• bgwrite_delay — 20ms. Время сна между циклами записи на диск фонового процесса записи. Данный процесс ответственен за синхронизацию страниц, расположенных в shared_buffers с диском. Слишком большое значение этого параметра приведет к возрастанию нагрузки на checkpoint процесс и процессы, обслуживающие сессии (backend). Малое значение приведет к полной загрузке одного из ядер.
• synchronous_commit — off . ОПАСНО! Выключение синхронизации с диском в момент коммита. Создает риск потери последних нескольких транзакций (в течении 0.5-1 секунды), но гарантирует целостность базы данных, в цепочке коммитов гарантированно отсутствуют пропуски. Но значительно увеличивает производительность.

Это далеко не всё, что удалось узнать из Интернета и статей на https://its.1c.ru . НО! Даже этих настроек хватит, чтобы видимо ускорить работу 1С:Предприятие на PostgreSQL.

В этом конкретном случае после перехода на PostgreSQL пользователи стали жаловаться, что 1С начала тормозить ещё сильнее, чем в файловом варианте. Но после этого тюнинга база «полетела». Теперь все наслаждаются быстрой работой. Однако есть и свои минусы в виде блокировок. Останавливаться на это мы не планируем, будем копать дальше и выкладывать полезные изменения конфигурации PostgreSQL сюда.

Если с базой данных возникли какие-то проблемы, возможно, Вам поможет .

Остались вопросы?

Что-то пошло не так? Специалисты нашей компании помогут Вам разобраться с возникшими проблемами! Обращайтесь! →

Вариант использования в качестве сервера баз данных PostgreSQL на windows платформе не очень популярен, но имеет место быть как правило, когда необходимо хоть как-то сэкономить на продуктах от MS. Так же существуют специализированные приложения, которые наилучшим образом работают с PostgreSQL. Для 1с существует модифицированная сборка PostgreSQL дающая как уверяют разработчики сопоставимый с MSSQL уровень производительности и отказоустойчивости. Так ли это на самом деле, проверим на практике:)

1. Установка PostgreSQL

Качаем с сайта 1с последнюю сборку PostgreSQL 64-bit 9.1.2-1.1C, распаковываем архив, запускаем msi-пакет, тот что без int, имеет не большой размер файла.

Нажимаем Start.
Опции установки оставляем по умолчанию.

Задаем пароль пользователю postgres от которого будет стартовать сервис. Нажимаем Далее. Если установка PostgreSQL производится впервые, то мастер предложит создать пользователя postgres.

На этапе инициализации БД, выбираем кодировку UTF8. Задаем логин и пароль внутреннему пользователю postgres. Внимание! Пароли пользователя сервиса PostgreSQL и пароль внутреннего пользователя БД PostgreSQL не должны совпадать. Пароль должен состоять как минимум из четырех символов. Если сервер 1C и PostgreSQL планируется запускать на разных машинах, то необходимо поставить галочку «Поддерживать соединения с любых IP, а не только с localhost». Нажимаем Далее и еще раз Далее. :)

Нажимаем еще два раза Далее и дожидаемся окончания установки.

Затем идем в Start\All Programs\PostgreSQL 9.1.2-1.1C(x64). Запускаем утилиту администрирования pgAdmin III. Пробуем подключится к БД. Вводим пароль, который указывали во время установки.
И получаем следующую ошибку: Error connecting to the server: FATAL: password authentication failed for user «postgres».

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

# TYPE DATABASE USER ADDRESS METHOD # IPv4 local connections: host all postgres::1/128 md5 host all postgres 127.0.0.1/32 md5 host all postgres 192.168.1.0/24 md5

Решил, поменять метод авторизации с md5 на trust. Перезапускаю сервис и снова пробую подключится к БД. На этот раз получаю такое сообщение.
Действительно на сайте pgAdmin доступна уже более новая версия. После чего подключение к БД завершается успехом!!?!! Помнится, ранее md5 не вызывал подобных проблем, видимо данный глюк действительно связан со старой версией pgAdmin’a.
Теперь можем создать базу для нужд 1С, либо сделать это при помощи самой 1С:)

2. Установка 1C предприятие 8.2.

Для установки отметим, следующие компоненты: 1С:Предприятие, Сервер 1С:Предприятия, Модули расширения веб-сервера, Администрирование сервера 1С:Предприятия.
На этапе, установки «Установить 1С Предприятие как сервис», задаем пароль пользователю USR1C82.
Нажимаем далее, следим за ходом установки:) Пользователю USR1CV82 при установке должны быть назначены следующие права:

Вход в систему как сервис (Log on as a service), Вход в систему как пакетное задание (Log on as a batch job). Посмотреть можно в Local Computer Policy\Computer Configuration\Windows Setings\Security Setings\Local Policies\User Right Assigments.

Переходим в оснастку Администрирование серверов 1С Предприятие, смотрим что кластер поднялся, и висит на 1541 порту. На вкладке «Рабочие серверы» так же присутствует наш сервер.Теперь, можно добавить базу на сервер 1С. Для этого переходим на вкладку «Информационные базы » щелкаемся правой кнопкой и выбираем New — Информационная база . Задаем необходимые параметры для подключения к серверу PostgreSQL. Нажимаем ОК.Запускаем 1С: Предприятие. Выбираем, добавить существующую информационную базу на сервере.
Далее, задаем параметры для подключения. Нажимаем «Далее» и наконец «Готово».
Операцию по созданию базы, можно проделать напрямую из 1С: Предприятия. Для этого при запуске, выбираем пункт «Создание новой информационной базы».

Для подключения клиентов 1С к серверу извне и работы сервера баз данных, на файрволе, должны быть открыты следующие порты:

Агент сервера (ragent ) — tcp:1540 Главный менеджер кластера (rmngr ) — tcp:1541 Диапазон сетевых портов, для динамического распределения рабочих процессов — tcp:1560-1591, tcp:5432 — Postgresql. Создадим правило через стандартный интерфейс, либо с помощью команды:

netsh advfirewall firewall add rule name=»1Cv8-Server» dir=in action=allow protocol=TCP localport=1540,1541,5432,1560-1590 enable=yes profile=ANY remoteip=ANY interfacetype=LAN

Теперь с другого компьютера мы спокойно запускаем клиент 1С:Предприятия, добавляем существующую информационную базу newdb . Не забываем про лицензии, программной / аппаратной защиты. Теперь, можем загрузить тест Гилева и померить производительность нашей системы.

На VirtualBox с 1Гб памяти, Dual-Core 2.6 GHz, 319-релиз 1с, тест Гилева выдает — 11.42 баллов, примерно так же как на CentOS. На 16.362 чуть больше 11.60 баллов. Оптимизация настроек при помощи EnterpriseDB Tuning Wizard ощутимого прироста (11.66 и 11.62) не дала, хотя возможно в целом польза от него имеется. :)

3. Регламентные работы на сервере PostgreSQL.

Резервное копирование.

Запускаем утилиту администрирования pgAdmin III, щелкаемся правой кнопкой по нужной базе данных. Выбираем »Резервное копирование».
Выбираем формат (Настраиваемый (степень сжатия от 0 до 9), Tar, Простой, Каталог). По степени сжатия, лучше всего сжимает «настраиваемый формат» любой степени сжатия, затем «каталог», потом «простой» и наконец «tar». Кодировку указываем UTF8, имя роли postgresql. Все дополнительные опции оставляем по умолчанию. Нажимаем кнопку «Резервная копия». В поле «Сообщения» отображается список всех произведенных операций с кодом завершения. Если 0, то успех. Здесь же можно подсмотреть, как запустить подобную операцию из командной строки.

F)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump.backup" "newdb"

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

"C:\Program Files (x86)\pgAdmin III\1.16\pg_dump.exe" --host 192.168.1.200 --port 5432 --username "postgres" --role "postgres" --no-password --format custom --blobs --compress 9 --encoding UTF8 --verbose --file "G:\Backups\gilev_dump_%date:~0,2%_%date:~3,2%_%date:~6,4%.backup" "newdb"

Восстановление.

Для восстановления, выбираем базу, в которую хотим восстановить данные из резервной копии, желательно в пустую. Щелкаемся правой кнопкой и выбираем «Восстановление». Задаем файл бэкапа, имя роли: postgres, нажимаем «Восстановить»
С помощью командной строки:

"C:\Program Files (x86)\pgAdmin III\1.16\pg_restore.exe" --host 192.168.1.200 --port 5432 --username "postgres" --dbname "testdb" --role "postgres" --no-password --verbose "G:\Backups\gilev_dump_26_09_2012.backup"

где, testdb — пустая база, в которую восстанавливается архив резервной копии.

Операции по обслуживанию:

Команда VACUUM (Сжатие):

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

VACUUM — помечает место, занимаемое старыми версиями записей, как свободное. Использование этого варианта команды, как правило, не уменьшает размер файла, содержащего таблицу, но позволяет не дать ему бесконтрольно расти, зафиксировав на некотором приемлемом уровне. При работе VACUUM возможен параллельный доступ к обрабатываемой таблице. Существует несколько дополнительных опций использования VACUUM: VACUUM FULL, VACUUM FREEZE, VACUUM ANALYZE.

VACUUM FULL — пытается удалить все старые версии записей и, соответственно, уменьшить размер файла, содержащего таблицу. Этот вариант команды полностью блокирует обрабатываемую таблицу.

VACUUM FREEZE — Если VACUUM FULL удаляет «мусор» из таблиц и перемещает записи так, чтобы таблицы располагались на диске компактно и состояли из наименьшего числа фрагментов, при этом сжатие выполняется долго и блокирует записи, то VACUUM FREEZE просто удаляет «мусор» из таблиц, но сами записи не перемещает, поэтому выполняется быстрее и не блокирует записи. В настоящий момент эту опцию заменяет autovacuum — автоматическая сборка мусора в postgresql.conf плюс несколько дополнительных опций расширяющих функциональность:

autovacuum = on # Включает автоматическую сборку мусора.
log_autovacuum_min_duration = -1 # Установка равная нулю регистрирует все действия autovacuum. Минус один (по умолчанию) запрещает вывод в лог. Например, если вы установите значение
равное 250 мс, то все действия autovacuum и analyzes, которые работают 250 мс и более, будут заноситься в журнал. Включение этого параметра может быть полезно для отслеживания autovacuum.
Этот параметр может быть установлен только в файле postgresql.conf или в командной строке сервера.
autovacuum_naptime = 10min # Время в секундах через которое база данных проверяется на необходимость в сборке мусора. По умолчанию это происходит раз в минуту.
autovacuum_vacuum_threshold = 1800 # Порог на число удалённых и изменённых записей в любой таблице по превышению которого происходит сборка мусора (VACUUM).
autovacuum_analyze_threshold = 900 # Порог на число вставленных, удалённых и изменённых записей в любой таблице по превышению которого запускается процесс анализа (ANALYZE).
autovacuum_vacuum_scale_factor = 0.2 # Процент изменённых и удалённых записей по отношению к таблице по превышению которого запускается сборка мусора.
autovacuum_analyze_scale_factor = 0.1 # То же, что и предыдущая переменная, но по отношению к анализу.
VACUUM ANALYZE — Если в базе есть таблицы, данные в которых не изменяются и не удаляются, а лишь добавляются, то для таких таблиц можно использовать отдельную команду ANALYZE. Также стоит использовать эту команду для отдельной таблицы после добавления в неё большого количества записей.

Команда ANALYZE (Анализ):

Служит для обновления информации о распределении данных в таблице. Эта информация используется оптимизатором для выбора наиболее быстрого плана выполнения запроса. Обычно команда используется в связке с VACUUM ANALYZE .

Команда REINDEX (переиндексация):

Используется для перестройки существующих индексов. Использовать её имеет смысл в случае

— порчи индекса;

— постоянного увеличения его размера.

Второй случай требует пояснений. Индекс, как и таблица, содержит блоки со старыми версиями записей. PostgreSQL не всегда может заново использовать эти блоки, и поэтому файл с индексом постепенно увеличивается в размерах. Если данные в таблице часто меняются, то расти он может весьма быстро. Если вы заметили подобное поведение какого-то индекса, то стоит настроить для него периодическое выполнение команды REINDEX. Учтите: команда REINDEX, как и VACUUM FULL, полностью блокирует таблицу, поэтому выполнять её надо тогда, когда загрузка сервера минимальна.

Хотя интернет уже переполнен статьями о «правильной» настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самая большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно.

Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

Итак, что имеем: игрушку IBM x3650 M4 c двумя процессорами, 32 GB оперативки, массив RAID 10 из 6-и дисков общим объемом ~900GB. Являясь сторонником опенсорсного ПО и немалый опыт работы с системами а-ля Debian и производные, решил выбрать в качестве операционки самую «человечную» из них - Ubuntu Server x64. Как потом оказалось - это была первая моя ошибка.

С СУБД знаком не понаслышке но, имею пока еще малый опыт работы именно на Linux платформу. Поэтому, если где-то ошибся, прошу пинать строго советами. Не один я такой все-таки.

Наконец 1С выпустила свежую сборку PostgreSQL под Debian/Ubuntu которая работает почти «из коробки».

Процес установки упростился до дюжины консольных комманд.

Admin@srv1c:~# sudo su

1. Увеличиваем максимальный размер сегмента памяти до 8Гб. Для менее мощных машин устанавливают от 64Мб до половины объема оперативки.

Root@srv1c:~# echo "kernel.shmmax=8589934592" >>/etc/sysctl.conf root@srv1c:~# sysctl -p

2. Генерируем русскую локаль и задаем переменную среды LANG, именно с ней будет работать скрипт инициализации базы данных.

Root@srv1c:~# locale-gen en_US ru_RU ru_RU.UTF-8 root@srv1c:~# export LANG="ru_RU.UTF-8"

3.Устанавливаем необходимые зависимисти.

Root@srv1c:~# apt-get install libssl0.9.8 ssl-cert postgresql-common libossp-uuid16 libxslt1.1

4. Берем с сайта users.v8.1c.ru архив с PostgreSQL 9.1.2 для 64-битных DEB-систем, распаковываем и устанавливаем нужные компоненты. Нужных и не нужных компонентов в архиве много, для того что бы все заработало достаточно postgresql, postgresql-client и postgresql-contrib.

Root@srv1c:~# tar zxf postgresql_9_1_2_deb_x86_64_tar.gz

5. Установка пакетов:

Root@srv1c:~# cd ./postgres root@srv1c:~# dpkg -i postgresql-9.1_9.1.2-1.1C_amd64.deb libpq5_9.1.2-1.1C_amd64.deb postgresql-client-9.1_9.1.2-1.1C_amd64.deb postgresql-contrib-9.1_9.1.2-1.1C_amd64.deb

6. После установки нужно еще немного подправить конфигурационный файл, как не странно будучи поставленным в пакете 1с он содержит не правильные настройки для обработки экранирующих символов, и при создании базы 1с выдает ошибки “syntax error at or near “SECOND” at character 127″ или “syntax error at or near “SECOND” at character 227″. Исправляем в файле /etc/postgresql/9.1/main/postgresql.conf следующие параметры.

Root@srv1c:~# nano /etc/postgresql/9.1/main/postgresql.conf

Backslash_quote = on escape_string_warning = off standart_conforming_strings = off
И закрываем с сохранением: Ctrl+x, Y

7. Перезапускаем сервис.

Root@srv1c:~# service postgresql restart

8.Меняем пароль для пользователя postgres – это тот пароль который мы будем задавать при создании базы данных.

Root@srv1c:~# su postgres postgres@srv1c:/root$ cd ~ postgres@srv1c:~$ psql -U postgres -c "alter user postgres with password "ваш пароль";" postgres@srv1c:~$ exit

9. Отключаем обновление для пакетов 1с-овского PostgreSQL.

Root@srv1c:~# echo "libpq5" hold | dpkg --set-selections root@srv1c:~# echo "postgresql-9.1" hold | dpkg --set-selections root@srv1c:~# echo "postgresql-client-9.1" hold | dpkg --set-selections root@srv1c:~# echo "postgresql-contrib-9.1" hold | dpkg --set-selections

10. Перезапускаем службу и проверяем, запустился ли PostgreSQL:

Root@srv1c:~# service postgresql restart root@srv1c:~# netstat -atn|grep 5432

Ответ должен быть примерно таким:

Tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN

Tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN

Здесь установка PostgreSQL закончена можно считать законченной.

При сравнении скорости работы связки 1C 8.2.16 + PostgeSQL 9.1.2 были обнаружены жуткие тормоза под Ubuntu Server 12.04. Тест от Гилёва «TPC_1С_GILV» в Ubuntu в среднем показал 10-14 баллов, что обусловлено тестовой базой, которая не задействует управляемые блокировки. Для сравнения, на менее мощную систему с четырехядерным процессором i5, 8GB оперативки, под Win 2k8 и IBM DB2 тот же тест показал 52 попугая. Проведение документов за месяц занимало в трое меньше времени на младшую машину. Аналогичные результаты получены и с PostgreSQL. Некоторые коллеги отзываются о результатах на CentOS при аналогичных параметрах. Так на CentOS получают по тому же тесту 56-62 балла а на чистую Debian - от 54 балла. Во всех тестах использовались идентичные настройки PG с отключенным fsync. В Ubuntu проверялись ext4, в CentOS LVM+ext3.

На всех платоформах ничего не ставилось кроме PG и 1C. На Ubuntu проверялись несколько версий PG, от Etersoft, собранная вручную с патчами от 1С и сборка от 1С, под CentOS использовалась версия Etersoft.

Есть какие-то варианты улучшения производительности в Ubuntu?

Я уже готовлю систему под CentOS. О результатах тестирования отпишусь в новой статье.