gifts2017

Установка Postgresql на Linux систему в качестве сервера базы данных

Опубликовал Константин Титов (xmolex) в раздел Администрирование - Системное

Хочу поделиться алгоритмом установки Postgresql 9.0.3-3.1C на OpenSuse 12.2 в качестве сервера базы данных 1С:Предприятие и оптимизицией под 8Гб ОЗУ и более менее быстрого процессора.

В данной статье описывается настройка выделенного сервера под PosqtgreSql. Сам 1С:Предприятие на данный сервер НЕ УСТАНАВЛИВАЕТСЯ!

 

Статья рассчитана на опытных пользователей и администраторов. Я не буду описывать все досконально, опишу только основные моменты.

 

OpenSuse 12.2 выбрана в связи с тем, что для быстродействия решено было использовать SAS RAID 0, а OpenSuse 12.2 по умолчанию поддерживала RAID контроллер и также под нее подходили установочные файлы для PostgreSQL от 1с.

 

Итак, ищем в сети образ openSUSE-12.2-NET-x86_64, качаем и прожигаем на CD. Вы можете скачать сразу полноценный образ, но у меня были сложности с записью на DVD, поэтому я использовал openSUSE-12.2-NET-x86_64.

Грузимся с нашего CD и начинаем установку системы

Выбираем в качестве носителя «сеть», «http», адрес — download.opensuse.org, репозитории - /distribution/12.2/repo/oss/

YAST – система — сетевые настройки — настраиваем сеть

YAST - безопасность и пользователи — брандмауэр — отключаем

YAST - система — системные службы — активируем sshd

перезапускаем компьютер и коннектимся по ssh (utf-8)

 

# устанавливаем необходимые пакеты

zypper install nano

zypper install termcap

 

# проверяем настройки сети

ethtool -s eth0 speed 1000 duplex full autoneg off

# 192.168.110.1 – в данном случае IP DNS сервера

echo "nameserver 192.168.110.1" > /etc/resolv.conf

nano /etc/sysconfig/network/ifcfg-eth0

BOOTPROTO='static'BROADCAST=''ETHTOOL_OPTIONS='speed 1000 duplex full autoneg off'# 192.168.110.10 – в данном случае IP этого компьютераIPADDR='192.168.110.10'MTU=''NAME='RTL8111/8168B PCI Express Gigabit Ethernet controller'NETMASK='255.255.255.0'NETWORK=''REMOTE_IPADDR=''STARTMODE='onboot'USERCONTROL='no' 

# убираем автологин, зачем тратить лишние ресурсы

nano /etc/sysconfig/displaymanager

DISPLAYMANAGER_AUTOLOGIN="no"

 

# устанавливаем PostgreSQL

mkdir ~/postgres

cd ~/postgres

wget http://koladigesta.ru/files/postgresql/9.0x64/postgresql-9.0.3-3.1C.x86_64.rpm

wget  http://koladigesta.ru/files/postgresql/9.0x64/postgresql-contrib-9.0.3-3.1C.x86_64.rpm

wget  http://koladigesta.ru/files/postgresql/9.0x64/postgresql-devel-9.0.3-3.1C.x86_64.rpm

wget  http://koladigesta.ru/files/postgresql/9.0x64/postgresql-docs-9.0.3-3.1C.x86_64.rpm

wget  http://koladigesta.ru/files/postgresql/9.0x64/postgresql-libs-9.0.3-3.1C.x86_64.rpm

wget  http://koladigesta.ru/files/postgresql/9.0x64/postgresql-server-9.0.3-3.1C.x86_64.rpm

wget  http://koladigesta.ru/files/postgresql/9.0x64/postgresql-test-9.0.3-3.1C.x86_64.rpm

rpm -Uvh --nodeps ./*.rpm

mkdir /usr/local/postgresql

groupadd postgres

useradd -g postgres -p postgres -d /usr/local/postgresql postgres

chown postgres:postgres -R /usr/local/postgresql

 

# делаем символьные ссылки на требуемые библиотеки

ln -s /lib64/libssl.so.1.0.0 /lib64/libssl.so.4

ln -s /lib64/libcrypto.so.1.0.0 /lib64/libcrypto.so.4

ln -s /lib64/libreadline.so.6.2 /lib64/libreadline.so.4

 

# инициализируем кластер базы

su postgres -c 'LANG=ru_RU.UTF-8 /usr/pgsql/bin/initdb /usr/local/postgresql/data'

 

# создаем скрипт автозапуска для postgresql

nano /etc/init.d/postgresql

#!/bin/shKIND="postgresql"USER="postgres"BIN="/usr/pgsql/bin/pg_ctl"DIR="/usr/local/postgresql/data"start() {echo -n $"Starting $KIND services: "sudo -u $USER -H $BIN -D $DIR startecho}stop() {echo -n $"Shutting down $KIND services: "sudo -u $USER -H $BIN -D $DIR stopecho}restart() {echo -n $"Restarting $KIND services: "sudo -u $USER -H $BIN -D $DIR restartecho}case "$1" instart)start;;stop)stop;;restart)restart;;*)echo $"Usage: $0 {start|stop|restart}"exit 1esacexit $?

 

chmod u+x /etc/init.d/postgresql

chkconfig postgresql on

sudo systemctl --system daemon-reload

service postgresql start

 

# теперь оптимизируем postgresql

# измененяем значение shmmax (Наибольший допустимый размер сегмента распределенной памяти max 1/4 RAM) в байтах

echo 2064529408 >/proc/sys/kernel/shmmax

echo "kernel.shmmax=2064529408" >>/etc/sysctl.conf

reboot

 

psql -U postgres -d template1 -c "ALTER USER postgres PASSWORD 'postgres'"

rm /usr/local/postgresql/data/pg_hba.conf

echo "local all all trust" >>/usr/local/postgresql/data/pg_hba.conf

echo "host all all 0.0.0.0/0 password" >>/usr/local/postgresql/data/pg_hba.conf

chown postgres:postgres /usr/local/postgresql/data/pg_hba.conf

 

# настройки приведены для нашего сервера, подбирались в течении месяца

# Intel(R) Xeon(R) CPU X3430  @ 2.40GHz

# 8Gb DDR2

nano /usr/local/postgresql/data/postgresql.conf

listen_addresses = '*'port = 5432max_connections = 50shared_buffers = 1792MBwork_mem = 370MBmaintenance_work_mem = 256MBcheckpoint_segments = 32effective_cache_size = 4GBrandom_page_cost = 2.5fsync = onwal_sync_method = fdatasynccpu_tuple_cost = 0.005cpu_index_tuple_cost = 0.001log_min_messages = error

 

 

# перезапускаем postgresql

service postgresql restart

 

# если система проработает без сбоев месяц и у вас есть хороший ИБП, то вы можете намного ускорить свой сервер применив в postgresql.conf опцию fsync = off. Лично у нас сервер работает с такой опцией, т.к. база в sql занимает 200Гб. Однако данная опция опасна и я рекомендую вам почитать о ней, прежде чем вы примените ее на своем боевом сервере.

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Владимир Зеленов (zelevova) 14.08.13 16:51
Работает ли это в продакшане? Сколько пользователей? Какие конфигурации?
Нет ли проблем с транзакциями?
2. Константин Титов (xmolex) 14.08.13 17:48
Да, работает в трех организациях, включая мою.
Самая большая организация: 30 одновременных пользователей, УПП (4 организации), база >200Гб, работают в режиме 24/7. Аптайм сервера базы данных больше года. Проблем с блокировками нет.
3. Dimka74 Dimka174 (Dimka74) 15.08.13 22:34
1. А сервер 1С Предприятия на какой ОСи работает?
2. Почему ПостГрес, DB2 не пробовали?
3. Резервное копирование БД как делаете?
4. Константин Титов (xmolex) 16.08.13 09:15
(3) Dimka74,
1) 1С:Предприятие работает в основном на windows 2003 server.
2) С DB2 у меня нет стольких годов дружбы как с PostgreSQL, поэтому выбрана она.
3) Бэкапирование делается как средствами 1с по ночам:
C:\\Program Files (x86)\\1cv82\\common\\1cestart.exe" CONFIG /S $BASE_IP\\$BASE_NAME /DisableStartupMessages /DumpIB "$DIR_TEMP/base.dt" /N "$BASE_USER" /P "$BASE_PASS" /OUT "$LOG" -NoTruncate

Так и с помощью журналирования PostgreSQL каждые два часа (режим 24/7).
archive_mode = on
5. Dimka74 Dimka174 (Dimka74) 16.08.13 10:31
Какой канал связи используете между windows 2003 server и OpenSuse 12.2. Трафик не считали?
6. Dimka74 Dimka174 (Dimka74) 16.08.13 10:35
Доводилось ли работать с MS SQL, если да, то велика ли разница в работе с постгресом, дело в том, что сами сидим пока на MSSQL на express (бесплатной) версии, но база растет и видно в длижайшем будущем придется перебираться либо на DB2, либо на Postgres.
7. mirco brons (mirco) 16.08.13 10:43
А вот fsync = off не надо делать !!! В случае чего ИБП вам не поможет - будете из архива базу восстанавливать.И разносить 1с и postgresql на разные машины тоже не надо.
Если уж хочется повысить скорость работы- вдумчиво прочитайте документацию к postgresql.
8. Константин Титов (xmolex) 16.08.13 11:07
(5) Dimka74,
Трафик не считали, канал используется 1Gb/s full duplex (это можно в конфиге в статье заметить).
Вообщем-то, канал не забивается. Даже при заливке бэкапа, при "fsync = off", канал используется на 25%.

(6) Dimka74,
Нет. MS SQL я только устанавливал, администрированием никогда не занимался.
Я понимаю, что 1с сильно дружит с MS SQL, но я считаю, что и на PostgreSQL под Unix можно добиться не меньшей производительности, хотябы просто по тому, что MS SQL работает под windows, а у нее, как мне кажется, странные методы работы с памятью, что для реляционной базы данных критично. Только лишь один Device Polling в нагруженной системе, может повысить производительность.

(7) mirco,
Это спорное утверждение. В любом случае я не говорю, что мое решение абсолютно правильное, хотя у меня есть доводы в пользу этого. Это частный вариант, который работает в продакшене 24/7. Вообщем, это просто пошаговая инструкция для определенной ситуации.
9. Dimka74 Dimka174 (Dimka74) 16.08.13 11:40
С какими проблемами в обслуживании Постгреса чаще всего приходится сталкиваться?
10. Константин Титов (xmolex) 16.08.13 11:45
(9) Dimka74,
Честно говоря даже не знаю, что ответить на этот вопрос.
Сложно подобрать значения, чтобы PostgreSQL использовал систему на 100%, а проблем в обслуживании я не знаю. Аптайм сервера больше года в продакшене 24/7 говорит сам за себя.
11. Dimka74 Dimka174 (Dimka74) 16.08.13 12:16
Год аптайма - это не плохо. Был на учебе по Администрированию баз 1С, так преподаватель говорил, мол Постгрес для маленьких компаний до 30 юзверей, потом МС Скуль с ДБ2, а уж потом Оракле. Учитывая ваш опыт, то границы пользования постгреса можно увеличить.
Как регулярно производите обновление самого Постгреса? Как только появляется обновление, или вообще не делаете ("Один раз настроили и забыли"-так говорил препод про машины под управлением ОС Linux).
12. Константин Титов (xmolex) 16.08.13 12:57
(11) Dimka74,
Обновлял 8.3.
9 версию еще не трогал.
Обновления в postgresql - это в основном дополнительные инструменты и ошибки повышения привилегий.
Дополнительные инструменты не нужны, ошибки повышения привилегий не страшны.
Если все работает без ошибок, то зачем трогать?
13. Dimka74 Dimka174 (Dimka74) 16.08.13 13:23
Спасибо за ответы, статья полезная.
14. mirco brons (mirco) 16.08.13 19:14
(8) А вот возьмите тест гилева и покажите результат.
"В любом случае я не говорю, что мое решение абсолютно правильное" - мудрость приходит со временем. Если знаете язык - читайте официальную документацию и best practice на форумах PostgreSQL.
15. Константин Титов (xmolex) 17.08.13 10:33
(14) mirco,
Если взять это предприятие о котором я говорю, которое 24/7, то работаем мы с ним уже три года. Это производство хлебной продукции. Тоесть постоянный прием заявок, формирование маршрутов, сопровождающая документация, бухгалтерия и т.д. Нужно отметить, что состоит производство из 4х организаций, тоесть одни пекут, другие доставляют, третие продают, четвертые управляют. И все это в одной базе.
Началось все от локальной файловой базы в 30Гб (терминальный доступ), потом была клиент-серверная система с postgresql на этом же сервере уже с 50Гб базы (терминальный доступ), потом отдельный выделенный сервер под sql базу (все также терминальный доступ) и в конце "fsync = off", который работает уже больше года.
Каждая такая модификация принципа работы системы возникала из-за жалоб пользователей касаемых производительности, это и не удивительно, база растет быстрыми темпами. Все это время конфигурация тестировалась с помощью ЦУП (центр управления производительностью - пакет от 1с), удавалось отслеживать слабые места, но нагрузка всеравно с течением времени возрастала. Сейчас одни только индексы таблиц регистров в базе занимают десятки гигабайт.
А вы говорите, что лучше postgres обратно вернуть на машину где сервер 1с предприятия. Для нас это пройденный этап и ушли мы от него, т.к. он показал свою несостоятельность в нашем случае.
Тесты это конечно хорошо. Но где гарантия, что они создают нагрузку рабочей системы? Проведите тесты от одного пользователя, от 30, от 100 и от 1000 и вы получите противоречивые результаты. Один пользователь вам покажет наилучшее быстродействие в файловой базе на одной машине. 1000 - только в sql'ном варианте на разных машинах.
Расскажите о себе, какой объем вашей базы, что за конфигурация, сколько одновременно пользователей 1с работают у вас. Может и правда все мои пройденные этапы ничто по сравнению с вашими и я нахожусь в самом начале вашего пути.
16. Андрей (ansh15) 18.08.13 12:25
(15) xmolex,
Так как обсуждение публикации плавно перетекло в дискуссию о нагрузке и производительности,
хочу спросить - вы считаете, что что одного четырехъядерного процессора не первой свежести и восьми ГБ памяти хватает для комфортной работы 30-и пользователей с >200 ГБ базой данных? В том, что на этот сервер не надо ставить еще и сервер приложений 1С, вы, безусловно, правы.
17. mirco brons (mirco) 19.08.13 00:23
(15) люди любят обижаться, если в их решениях сомневаются )))))))
18. Константин Титов (xmolex) 19.08.13 09:41
(16) ansh15,
Все зависит от особенностей использования системы. У нас очень часто правятся накладные задним числом, тоесть в день происходит тысячи перепроведений документов. Пока такой сервер справляется, но думаю, что при таком же росте базы через год уже будут тормоза.
Но вообще, когда у вас база сильно превышает оперативку, вам стоит очень серьезно подойти к дисковой подсистеме. У нас стоит рейд 0 из двух sas (2.0) дисков.

(17) mirco,
Я бы не сказал, что я обижаюсь. Я просто не понимаю вас, но способен принимать критику от более опытных товарищей. Я работаю с postgresql уже семь лет (вначале была разработка интернет-проектов). И всегда я видел, что postgresql требователен к скорости диска и оперативке. Об этом и пишут и сама эксплуатация это показывает. Возьмем сервер 1с:предприятие. Ему также нужна память. Приплюсуем сюда рекомендацию запускать более одного рабочего процесса и вот у нас уже съедается два гига оперативы, приплюсуем операционку (которая в идеале расчитывает на два гига оперативы, т.к. без ключа /3Gb), приплюсуем терминальные сессии с 30 пользователями, которые запустили 1с и который с легкостью может скушать 512Mb, это еще гигов под 14. И что получается? А получается, что по памяти система и так загружена по самое нихочу (не забудем про то, что win очень активно работает с swap файлом, хоть памяти и достаточно), а вы решаете еще вклинить в нее приложение очень требовательное к памяти, да еще и с базой >200Гб. У вас одних прерываний будет столько, что вы получите неслабый простой. Какие настройки здесь спасут? Ни один тюнинг не сможет разгрузить систему.
Конечно, если пользователи не работают, а чай пьют в 1с, то конечно система будет справляться, но если хоть один человек начнет активно данные перепроводить, вашей системе придется не слабо.
Если вы не согласны с моими словами, то прошу вас быть более аргументированнее.
19. mic auto (4ur) 19.08.13 18:36
Спасибо за статью. Возможно эта информация позволит сэкономить денег фирме, т.к. принципиально надо все лицензионное, хотя не уверен, что программистам и админам от этого будет легче. Может и у себя дома решусь перейти на Linux, хотя в 8.3 еще хватает багов, но надо попробовать...
20. Сергей Маслов (sirm) 31.03.14 19:30
У меня клиенты работают уже два года: 20 пользователей Centos 5.9+Postgresql 9.1.2 (1С)+1С Сервер x86_64 (8.2).
Пока все отлично. Слетало только из-за проблем в сети и ключи HASP бились между собой.
Единственная проблема, которая осталась (1С пока не смогли что-то сказать понятное) это формирование в 1С-Бухгалтерии 2.0 расчета себестоимости. Что вешает не понятно. 1С утверждают, что это проблема Postgresql. Может кто сталкивался? Как решили эту проблему?
21. Андрей (ansh15) 01.04.14 12:16
(20) sirm, была такая проблема, с PostgreSQL 9.0.3 http://downloads.v8.1c.ru/content//Platform/8_2_19_90/Err_Other.htm
Может у вас сбор статистики не выполняется регулярно, попробуйте vacuum analyze выполнить на проблемной базе.
Тут https://wiki.postgresql.org/wiki/%D0%A7%D0%B0%D1%81%D1%82%D0%BE_%D0%97%D0%B0%D0%B4%D­0%B0%D0%B2%D0%B0%D0%B5%D0%BC%D1%8B%D0%B5_%D0%92%D0%BE%D0%BF%­D1%80%D0%BE%D1%81%D1%8B можно почитать немного подробнее про статистику. Ну и обновиться до 9.1.9/9.2.4 имеет смысл.
22. Константин Титов (xmolex) 01.04.14 12:40
(20) sirm, если проблема с postgresql, то лезь в его логи и ищи там ошибки. Если найдешь ругань при запуске расчета себестоимости, то значит проблема в postgresql. В зависимости от типа ругани и следует выбирать направление действий. А вот, если ругани нет, то стоит обратить внимание на сервер 1с предприятие: проверить правильность данных в конфигурации, обнулить рабочий каталог сервера 1с предприятие и т.д.
23. Сергей Маслов (sirm) 01.04.14 13:34
(21) ansh15,
Про решение текущих проблем у 1С они уже и не помню с какого релиза пишут, что это решено, но у меня воз и ныне там.
1С сервер обновляем регулярно, переходя на новый релиз. Причем последний раз снес начисто все и 1С Сервер и Postgersql и поставил заново (1С-овцы порекомендовали). Проблема осталась.
Vacuum analyze выполнял...
24. Сергей Маслов (sirm) 01.04.14 13:36
(22) xmolex,
Вроде логи смотрел. Особых ошибок не увидел, только когда начинали отваливаться клиенты, но эти ошибки вылезают и при простом отключении от базы по причине обрыва сети и т.д.
"...проверить правильность данных в конфигурации..." что имеете ввиду?
25. Константин Титов (xmolex) 01.04.14 13:56
(24) sirm, тестирование и исправление.
Что значит "Особых ошибок не увидел", они либо есть, либо их нет.
В конфиге log_min_error_statement = error стоит, может не ведутся логи?
26. Сергей Маслов (sirm) 01.04.14 13:59
Как к клиентам попаду посмотрю. Сейчас логи отключены.
На что стоит обратить внимание, т.к. попадаю я к клиентам или в выходные или поздно вечером.
27. Константин Титов (xmolex) 01.04.14 14:11
(26) sirm, на различные ошибки конечно. Если в логах нет никаких ошибок и внеплановых вылетов, значит проблема не в postgresql и копать нужно в сторону сервера 1с, конфигурации и толстого клиента.
28. Андрей (ansh15) 01.04.14 16:02
(23) sirm, http://training1c.org.ua/materialy.htm?a=reshenie_problemy_s_zavisaniem_postgresql
тут еще можно посмотреть(если не смотрели уже), поэкспериментировать с различными настройкам оптимизатора.
Хорошо бы выявить запрос(ы) SQL, на которых виснет и на них менять параметры оптимизатора, в psql, посредством explain analyze
Понятно, что нужно чтобы работало быстро и без проблем. а в PostgrеSQL совсем без затрат не получается, к сожалению.
29. Сергей Маслов (sirm) 23.10.14 13:33
(27) xmolex,
1C вот разродилось. После длительной переписки и высылания баз и различных дампов и логов прислали ответ:

Здравствуйте!

1. ОТВЕТ отдела разработки программ:

Проблема не в PostgreSQL.
При использовании MS SQL Server наблюдается аналогичная проблема.

В отчете СправкаРасчетКалькуляцияСебестоимости используется слишком сложный запрос,
который плохо отрабатывается сервером СУБД.
Нужно его упростить.

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

Разработчики конфигурации спустя некоторое время прислали:

Здравствуйте!

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

Направляем ответ отдела разработки конфигурации Бухгалтерия предприятия:

1. В редакции 2.0 конфигурации Бухгалтерия предприятия решать проблему не планируется.
Рекомендуем переходить на редакцию 3.0 конфигурации Бухгалтерия предприятия.

2. Мы провели тест:

- Обновили полученную от Вас базу до редакции 3.0

- На PostgreSQL Database Server версии 9.1.2-1
отчет "Калькуляция себестоимости" за 2013 год
сформировался меньше чем за 1 минуту.

Если честно я вздохнул с облегчением:)))
30. ZLENKO.PRO (ZLENKO) 23.10.14 13:49
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа