Бэкап баз 1С на postgresql
Без регулярного автоматического бэкапа баз 1С невозможно себе представить эксплуатацию. Так что этим вопросом надо заняться в первую очередь после настройки сервера и добавления баз. Посмотрим, какие базы postgresql у нас существуют:
# sudo -u postgres psql -U postgres -l
Я создал две тестовые базы: buh30 и zup31. Их и будем бэкапить. Я для этого предлагаю использовать обычный pg_dump, а затем дамп сразу же сжимать архиватором pigz. Его отличительная особенность в том, что он умеет жать всеми ядрами процессора, а не только одним, как, к примеру, gzip. Более подробно про pigz я рассказывал в заметке.
В самом простом случае бэкап базы данных выглядит следующим образом:
# sudo -u postgres /usr/bin/pg_dump -U postgres buh30 | pigz > /mnt/backup/buh30.sql.gz
Если посмотреть на dump, то в случае успешного создания, в начале дампа будет строка:
-- PostgreSQL database dump
а в конце:
-- PostgreSQL database dump complete
В будущем эта информация нам понадобится для мониторинга создания бэкапов и получения уведомления, если дамп не завершился корректно.
Для того, чтобы бэкапить автоматически все базы сразу я предлагаю использовать простой скрипт.
#!/bin/bash
BASES=("buh30" "zup31")
#BASES=`sudo -u postgres /usr/bin/psql -U postgres -l | grep "_buh\|_zup" | awk '{print $1}'`
DATA=`date +"%Y-%m-%d_%H-%M"`
LOGS=/var/lib/pgpro/service_logs
BACKUPDIR=/var/lib/pgpro/backup
for i in ${BASES};
do
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup $i" >> $LOGS/$DATA.log
sudo -u postgres /usr/bin/pg_dump -U postgres $i | pigz > $BACKUPDIR/$DATA-$i.sql.gz
echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup $i" >> $LOGS/$DATA.log
done
В скрипте предложены 2 варианта указания списка баз для бэкапа:
- Последовательное перечисление.
- Бэкап всех баз, что имеют в своем названии _zup или _buh.
Я обычно ставлю некоторые метки в именах баз, чтобы потом было проще формировать списки для бэкапа. Например, все тестовые базы можно помечать в имени _test — company_buh30_test и потом исключать из списка бэкапа все базы с дополнением _test в названии. Либо просто все рабочие базы сразу именовать с приставкой _buh или _zup и по этому признаку их выводить в список.
Для работы скрипта в таком виде, не забудьте создать каталоги:
# mkdir -p /var/lib/pgpro/service_logs # mkdir -p /var/lib/pgpro/backup
И еще важно учесть, что так как в скрипте мы запускаем команды от системного пользователя postgres, необходимо, чтобы у него был доступ к скрипту, когда добавите его в планировщик. На выходе у вас получится примерно такой список бэкапов баз 1С из postgresql
На выходе у вас получится примерно такой список бэкапов баз 1С из postgresql.
В дальнейшем мы их будем забирать отсюда и удалять.
Что я могу сделать, чтобы избежать этой проблемы?
Как только файл стал раздутым, кажется, что самый простой способ вернуть базу данных в рабочее состояние — это удалить файл, выполнив следующие шаги:
-
Остановить базу данных
-
Когда БД остановлена, каталог pg_stat_tmp пуст и файл написано. Мы переименовали этот файл в ,
-
Запустите базу данных. Он создает новый набор файлов pgstat. После подтверждения правильной работы сервера вы можете удалить старый файл, который вы переименовали.
Это процесс, который мы использовали, когда один из наших серверов страдал от этой проблемы.
Излишне говорить, что будьте очень осторожны при ручном манипулировании любыми файлами в каталоге Postgresql Data.
После этого вы можете захотеть проконтролировать сервер, чтобы увидеть, не станет ли он снова раздутым. Если это так, вот некоторые дополнительные идеи для рассмотрения:
-
Как упомянуто выше, я видел некоторые ссылки на этот файл, становящийся раздутым, если autovacuum не работает достаточно агрессивно. Вы можете настроить параметры автовакуума
-
Отключение любого из опции, описанные в разделе 18.9.1 руководства, которые не требуются, могут помочь
-
-
Можно разместить каталог в файловой системе tmpfs (или любой другой эквивалентной файловой системе на основе ОЗУ, доступной в windows). Это должно устранить необходимость ввода-вывода в качестве проблемы для этих файлов.
Рекомендации:
- Сборщик статистики Postgres, показывающий высокий дисковый ввод-вывод
- Слишком много операций ввода-вывода, сгенерированных процессом сбора статистики postgres
- сборщик статистики внезапно вызывает много IO
Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо
Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года.
Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании «Деловые линии».
Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность.
Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры.
**update от 04.03.2016 по вопросам из комментариев
Основные операции с БД
Чтобы выполнять базовые действия в СУБД, нужно знать язык запросов к базе данных SQL.
Создание базы данных
Для создания базы данных используется команда:
create database
В приведенном ниже примере создается база данных с именем proglib_db.
Рисунок 3 — Создание базы данных с именем proglib_db
Если забыть точку с запятой в конце запроса, знак «=» в приглашении postgres заменяется на «-». Это зачастую указывает на то, что необходимо завершить (дописать) запрос.
Рисунок 4 — вывод ошибки при создании базы данных
На рисунке 4 видно сообщение об ошибке из-за того, что в нашем случае база уже создана.
Создание нового юзера
Для создания пользователя существует команда:
create user
В приведенном ниже примере создается пользователь с именем author.
Рисунок 5 — Создание пользователя с именем author
При создании пользователя отобразится сообщение CREATE ROLE. Каждый пользователь имеет свои права (доступ к базам, редактирование, создание БД / пользователей и т. д.). Вы могли заметить, что столбец Attributes для пользователя author пуст. Это означает, что пользователь author не имеет прав администратора. Он может только читать данные и не может создать другого пользователя или базу.
Можно установить пароль для существующего пользователя.
С этой задачей справится команда :
postgres=#\password author
Чтобы задать пароль при создании пользователя, можно использовать следующую команду:
postgres=#create user author with login password 'qwerty';
Удаление базы или пользователя
Для этой операции используется команда : она умеет удалять как пользователя, так и БД.
drop database <database_name> drop user <user_name>
Данную команду нужно использовать очень осторожно, иначе удаленные данные будут потеряны, а восстановить их можно только из бэкапа (если он был).
Если вы укажете psql postgres (без имени пользователя), то postgreSQL пустит вас под стандартным суперюзером (postgres). Чтобы войти в базу данных под определенным пользователем, можно использовать следующую команду:
psql
Войдем в базу proglib_db под пользователем author. Выполним команду , чтобы выйти из текущей БД, а затем выполните следующую команду:
Рисунок 6 — Вход в базу данных proglib_db
почему я получаю ошибки «отказано в разрешении» в Windows?
после изучения исходного кода postgresql я думаю, что может быть условие гонки при доступе к файл, который может произойти в любое время, но усугубляется размером файла.
режим работы по умолчанию в Windows заключается в том, что невозможно переименовать или удалить файл, пока он открыт другим процессом. Это отличается от Linux (или Unix), где файл может быть переименован или удален, в то время как другие процессы обращаются к нему.
в последовательности выше вы можете видеть, что если один из бэкэнд-процессов читает файл в то же время, как сборщик статистики переписывает его, то бэкэнд-процесс может все еще имейте файл открытым во время попытки переименования. Это приводит к ошибке «отказано в разрешении», которую вы видите.
естественно, когда файл становится очень большим, то количество времени, необходимое для его чтения, становится более значительным, поэтому вероятность процесса сборщика статистики, пытающегося переименовать, пока бэкэнд все еще открыт, увеличивается.
однако, поскольку файл часто переписывается, влияние этих ошибок относительно мягкое. Он просто означает, что это конкретное обновление терпит неудачу, что приводит к тому, что бэкэнды получают немного устаревшую статистику. Следующее обновление, вероятно, будет успешным.
обратите внимание, что Windows предлагает режим открытия файлов, который позволяет удалять или переименовывать файлы во время их открытия другим процессом, однако, насколько я могу судить, этот режим не используется Postgresql. Я не мог найти никакого отчета об ошибке на этом-кажется, это должно быть сообщено
таким образом, эти ошибки являются побочным эффектом основной проблемы, которая является чрезмерным размером .
Ярлыки
11.1
11.1.1 trial
11.10
12.04
14.04
16.04
17.04
17.10
18.04
1с
1С + postgresql под windows
1С:Отчетность
1С:Предприятие 7.7
1c
20.04
32 бит
3proxy
9.6.2
автономный сервер
админ
администрирование
анализ сервера
архивирование
безопсность
березка
веб доступ
время
второй кластер
выгнать пользователей
госзакупки
диагностика
диагностика postgresql
документация
Дорошкевич
журнал регистрации
Завершение работы пользователей
зависимости postgresql
запуск postgresql
зафиксировать postgresql
ибп
интересно
камин
книги
Конфигурация сервера
КриптоПро
лицензии
лицензия
логи
локальная сеть
минисервер 1с
Моё рабочее
мой сервер
настройка дампов
непрерывное архивирование
обновление 1с
обновление ядра
обновление postgresql
ограничение 1Гб
ОКБ
Олег Харин
ОПО
оптимизация
ошибка
пароли
переименовать хост
перенос win lin
печать
Поиск пакетов
Потоковая репликация
программная лицензия
размер базы
размер таблиц
РИБ
сборка postgresql
сервер хранилища
сессии
скачать дистрибутивы
скрипт
скрипт wal
справочник
спутник
спящие сеансы
сравнение cpu
ссылки
статический ip
тест
тестирование
Тестирование и исправление конфигурации
тестовый сервер
технологический журнал
тюнинг postgresql
удаление 1с
удаление postgresql
управление серверами
установка 1с
установка 2 сервера 1с
файловый режим
фиас
флешка
фрагментация памяти
холодный backup
Шпаргалка PostgreSQL
штрих-коды
энергосбережение
acme.sh
aksusbd
Aladdin Monitor
alt linux
alternative downloads
amcheck
ammyy admin
apache2
apc
apparmor
apport
Asterisk
astra
astra linux
astra lxc
astra lxd
atop
audio
autologon
autovacuum
B360M
B365M
backup
Bash-скрипты
bridge-utils
bug
cache_hit_ratio
cadaver
canon
centos
Certbot
Certificate
checkdb
chromium
chromium-gost
cloak
clonezilla
cpu
cpufreqd
cron
crontab
cryptcp
Crypto-Pro
cryptopro
CryptSync
cups-pdf
curl
cwRsync
Cygwin
cygwin-rsyncd
dante
db2
debian
debian 10
desktop
disk
Dns Leak Test
DO
docker
docker-compose
DokuWiki
dump
elastix
etersoft
excel
fail2ban
Failover
fedora
files
FileZilla
fio
firefox
fragster
freenx
ftp
ghostscript
GIMP
git
gitlab
gnome
gnome-tweak-tool
gost
governor
gpg
GPT to MBR
haproxy
hasp
hasp & lxc
hdd
hold
host
hostname
hostnamectl
Hyper-Threading
i7
i7-7700
icmp
intel
intel graphics 630
Intel Kaby Lake
ip
iperf
IPSec
iptables
journalctl
juju
Junction
kerberos
kvm
L2TP
Let’s Encrypt
linux
live-cd
LMNoIpServer
Load Average
log
LPD
LVM
lxc
lxc in lxd
lxd
lxd & virtualbox
lxd 1c
lxd backup
lxd haproxy
lxd nextcloud
lxd resource control
lxd vps
lxd-p2c
macvlan
Mandos
mariadb
mc
MediaWiki
mining
mint
MobaXterm
mp3
mssql
multipath
mysql
MZ1LB960HAJQ-00007
net.netfilter.nf_conntrack_max
nethasp
nethasp.ini
network
NetworkManager
nextcloud
Nginx
NoMachine
ntp
numactl
numlock
nut
NVMe
nvOC
ondemand
openconnect
OpenSSH
OpenSSL
openvpn
ops
orel. orel docer
performance
pg_basebackup
pg_catalog.pg_statistic
pg_controldata
pg_dump
pg_dump в каталог
pg_probackup
pg_probackup одна база
pg_probackup upgrade
pg_repack
pg_resetxlog
pgadmin4
pgBackRest
pgbench
PGConf
PgTune
phpvirtualbox
Playonlinux
plink
posfix
postfix
postgrespro
postgrespro-std-11
postgresql
PostgreSQL Configurator
postgresql port
postgresql ssl
postgresql win
postgresql.conf
proxmox
pulseaudio
pure-ftpd
python
QtdSyn
RAID
ramdisk
ramfs
rancher
ras
rclone
reverse-proxy
rphost
rsync
Rufus
samba
Samsung SSD
sandisk
Sar
screen
server
Shadowsocks
smartctl
smartmontools
smbclient
snap
snapshot
spice
squid
ssd
ssh
ssh к флешке
ssh по сертификату
ssl
stats_temp_directory
strongSwan
stubby
stunnel
Supermicro
swap
swappiness
sysctl
sysctl.conf
systemd
tap
TCmalloc
teamviewer
telegram
temp_tablespaces
terminal server
test
test Тестовый сервер
test ssd
test2
test3
timedatectl
timezona
tint2
tmpfs
TRIM
ubuntu
ubuntu 18.04
ubuntu 20.04
ufo
ufw
unity
UNIX sockets
ureadahead
usb
v2ray-plugin
vacuum
vacuumdb
vbox
vino
virsh
virt
virt-manager
virt-viewer
virtualbox
vnc
vsftpd
wal
wd my cloud
web
webdav
wget
windows
windows server
windows vs linux
wine
WinSetupFromUSB
WireGuard
wordpress
x11vnc
xming
xrdp
xubuntu
xubuntu-desktop
xvfb
yandex-disk
youtube
youtube-dl
zabbix
zfs
zram
Исходные данные. Задача
Допустим, мы разрабатываем базу данных в PostgreSQL, при этом мы используем обычный клиентский компьютер под управлением операционной системы Windows 10, где собственно локально и установлен PostgreSQL.
В качестве инструмента разработки мы используем стандартное графическое приложение pgAdmin 4.
В итоге базу данных мы разработали, протестировали ее, внесли в нее необходимые данные, заполнили справочники, в общем, база данных готова.
Теперь у нас возникла необходимость перенести эту базу данных на реальный сервер, который и будет выступать в качестве сервера баз данных. И так как мы используем PostgreSQL, в качестве такого сервера баз данных обычно выступает сервер под управлением операционной системы Linux.
Таким образом, нам необходимо перенести базу данных PostgreSQL, разработанную в Windows, в базу данных PostgreSQL на Linux. В моем случае в качестве операционной системы Linux будет выступать дистрибутив Debian.
Создание дампа базы данных PostgreSQL в pgAdmin 4
Весь процесс переноса базы данных PostgreSQL достаточно простой, суть в следующем.
Нам необходимо создать копию нашей базы данных (дамп), затем создать пустую базу на нужном нам сервере и восстановить все данные, используя созданный ранее дамп.
Все это можно сделать с нашего клиентского компьютера, используя pgAdmin 4, если, конечно же, целевой сервер нам доступен, если недоступен, то придётся каким-то другим образом переносить дамп базы данных на нужный сервер и, используя стандартные консольные утилиты, восстановить базу данных из дампа.
Кстати, стоит отметить, что pgAdmin 4 для экспорта/импорта баз данных использует как раз эти стандартные консольные утилиты, в частности pg_dump, pg_dumpall и pg_restore, которые по умолчанию входят в состав PostgreSQL.
pg_dump – утилита для экспорта баз данных PostgreSQL
pg_dumpall – утилита для экспорта кластера баз данных PostgreSQL (всех данных на сервере)
pg_restore – утилита восстановления баз данных PostgreSQL из файла архива
Таким образом, благодаря pgAdmin 4 нам не нужно писать и выполнять команды в командной строке, за нас все это делает pgAdmin 4, мы всего лишь будем пользоваться мышкой, настраивая все параметры в графическом интерфейсе.
Создать дамп базы данных PostgreSQL можно в нескольких форматах, в частности:
Специальный (Custom) – это пользовательский формат, который использует сжатие. Данный формат по умолчанию предлагается в pgAdmin 4 и рекомендован для средних и больших баз данных. Обычно архивные файлы в таком формате создают с расширением backup, однако можно использовать и другое расширение.
Tar (tar) – база данных выгружается в формат tar. Данный формат не поддерживает сжатие.
Простой (plain) – в данном случае база данных выгружается в обычный текстовый SQL-скрипт, в котором все объекты базы данных и непосредственно сами данные будут в виде соответствующих SQL инструкций. Данный скрипт можно легко отредактировать в любом текстовом редакторе и выполнить, используя Query Tool, как обычные SQL запросы. Данный формат рекомендован для небольших баз данных, а также для тех случаев, когда требуется внести изменения в дамп базы данных перед восстановлением.
Каталог (directory) – этот формат файла создает каталог, в котором для каждой таблицы и большого объекта будут созданы отдельные файлы, а также файл оглавления в машиночитаемом формате, понятном для утилиты pg_restore. Этот формат по умолчанию использует сжатие, а также поддерживает работу в несколько потоков.
В данном материале мы рассмотрим создание дампа в специальном формате, а также в формате обычного SQL скрипта, дело в том, что процесс восстановления базы данных из этих форматов в pgAdmin 4 немного отличается.
Создание дампа базы данных в сжатом формате
Чтобы создать дамп базы данных PostgreSQL в pgAdmin 4, необходимо в обозревателе выбрать нужную базу данных, я выбираю базу данных shop, далее необходимо вызвать контекстное меню правой кнопкой мыши и нажать на пункт «Резервная копия».
Затем всего лишь нужно указать имя архивного файла и путь к каталогу, где его сохранить, для этого можно использовать кнопку с тремя точками.
Формат «Специальный», как было отмечено ранее, предлагается по умолчанию, поэтому выбирать его не требуется.
Как я уже отмечал, обычно архив в таком формате создают с расширением backup, я так и поступаю, т.е. архив назову shop.backup и сохраню его в каталоге D:\PostgreSQL_Backup\.
В случае необходимости задать определенный уровень сжатия можно с помощью параметра «Коэффициент сжатия», поддерживаются значения от 0 до 9, где 0 – вообще не использовать сжатие, а 9 самый высокий уровень сжатия, по умолчанию используется умеренное сжатие.
В нашем случае база данных небольшая, поэтому мы можем оставить все по умолчанию.
Больше никаких настроек в нашем случае делать нет необходимости, и мы можем нажать на кнопку «Резервная копия», чтобы запустить процесс создания дампа базы данных.
Когда появится сообщение «Успешно завершено», значит, процесс создания дампа базы данных PostgreSQL завершен успешно, в противном случае Вы будете получать сообщения о неуспешном завершении.
Создание дампа базы данных в простом формате SQL
В данном случае нам необходимо сделать практически все то же самое, только нужно выбрать формат «Простой» и дополнительно включить пару параметров, чтобы добавление данных осуществлялось с помощью обычных инструкций INSERT, а не с помощью команды COPY, которая используется по умолчанию.
Для этого переходим на вкладку «Параметры выгрузки» и включаем два параметра «Использовать команды INSERT» иINSERT с указанием столбцов», хотя данный параметр можно и не указывать.
Установка 1С:Предприятие 8.3 на Debian 10
Начнем нашу настройку с установки сервера 1С. Для этого нам надо установить дополнительные пакеты в систему, которые находятся в разделах системного репозитория contrib и non-free. Их нужно добавить в конфиг репозиториев Debian. Для этого редактируем файл /etc/apt/sources.list и приводим его примерно к следующему виду:
deb http://mirror.yandex.ru/debian buster main contrib non-free deb-src http://mirror.yandex.ru/debian buster main contrib non-free deb http://mirror.yandex.ru/debian buster-updates main contrib non-free deb-src http://mirror.yandex.ru/debian buster-updates main contrib non-free deb http://security.debian.org/ buster/updates main contrib non-free deb-src http://security.debian.org/ buster/updates main contrib non-free
Сами адреса репозиториев у вас могут быть другие. Выполняем обновление списка пакетов:
# apt update
Теперь устанавливаем нужные для работы 1С в linux пакеты. Начнем со шрифтов mscorefonts.
# apt install ttf-mscorefonts-installer
Установка будет идти достаточно долго, так как скачивается целая куча дополнительных пакетов и файлов.
Добавляем еще несколько необходимых пакетов:
# apt install imagemagick unixodbc sudo curl
Следующий важный этап подготовки к установке сервера 1С — настройка локали. Для этого выполняем команду в терминале:
# dpkg-reconfigure locales
Нам нужно выбрать ru_RU.UTF-8 UTF-8. Так же убедитесь на всякий случай, что en_US.UTF-8 тоже выбрана. В дефолте так и должно быть, но я сталкивался с ситуациями, когда эту локаль тоже приходилось добавлять.
По умолчанию выбираем ее же — ru_RU. После того, как вы разлогинитесь из системы и зайдёте снова, у вас в консоли будет русский язык. Немного непривычно с ним работать, но придется потерпеть это неудобство.
Теперь нам необходимо скачать deb пакеты сервера с портала 1С. Для этого логинимся под действующей учетной записью на https://releases.1c.ru и скачиваем файл Cервер 1С:Предприятия (64-bit) для DEB-based Linux-систем.
Имя файла будет deb64_8_3_19_1150.tar.gz. Его нужно передать на Debian сервер. Я обычно winscp для этого использую. Распаковываем архив в отдельную директорию.
# mkdir 1c-server # mv deb64_8_3_19_1150.tar.gz 1c-server/ # cd 1c-server/ # tar xzvf deb64_8_3_19_1150.tar.gz # rm deb64_8_3_19_1150.tar.gz
Вы получите список распакованных пакетов для сервера 1С.
# ls -lh итого 470M -rwxrwxrwx 1 1001 1001 29M июн 2 03:27 1c-enterprise-8.3.19.1150-common_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 8,9M июн 2 03:27 1c-enterprise-8.3.19.1150-common-nls_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 31K июн 2 03:27 1c-enterprise-8.3.19.1150-crs_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 323M июн 2 03:27 1c-enterprise-8.3.19.1150-server_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 110M июн 2 03:27 1c-enterprise-8.3.19.1150-server-nls_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 311K июн 2 03:27 1c-enterprise-8.3.19.1150-ws_8.3.19-1150_amd64.deb -rwxrwxrwx 1 1001 1001 22K июн 2 03:27 1c-enterprise-8.3.19.1150-ws-nls_8.3.19-1150_amd64.deb drwxr-xr-x 3 root root 4,0K июн 7 23:01 license-tools
Если вы в 1С используете только русский или английский язык, то пакеты с добавлением в имени nls вам не нужны. А все остальное устанавливаем.
# dpkg -i 1c-enterprise-8.3.19.1150-common_8.3.19-1150_amd64.deb 1c-enterprise-8.3.19.1150-server_8.3.19-1150_amd64.deb 1c-enterprise-8.3.19.1150-ws_8.3.19-1150_amd64.deb
Не забудьте изменить версию платформы в имени файла на свою.
Запускаем Сервер 1С на Debian:
# systemctl start srv1cv83
Если получили ошибку: «Failed to enable unit: Unit file srv1cv83.service does not exist.», значит при установке пакета не был добавлен init скрипт для запуска сервера. Сделаем это вручную, создав символьную ссылку:
# ln -s /opt/1cv8/x86_64/8.3.19.1150/srv1cv83 /etc/init.d/srv1cv83 # systemctl daemon-reload
После этого запускаем сервер 1С еще раз той же командой выше. Ошибки теперь быть не должно.
Проверим, все ли службы запустились:
# netstat -tulnp | grep "rphost\|ragent\|rmngr"
Всё на месте. Если у вас включен Firewall на сервере, не забудьте открыть указанные порты. Данная настройка не относится к тематики статьи, так что я ее опускаю.
На этом установка самого Сервера 1С закончена. Переходим к установке и настройке базы PostgreSQL для него.
На помощь внезапно приходят большие страницы
Множество процессорных микро-архитектур обычно используют страницы размером 4KiB, но также могут использовать и страницы большего размера, например широко распространенный вариант это 2MiB.
В зависимости от операционной системы, конфигурации и типа приложений, такие большие страницы могут использоваться и самой операционной системой и приложениями. Для больших подробностей можно в качестве примера взять статью из Debian wiki об использовании больших страниц.
Если повторить вышеописанный эксперимент с huge_pages=on, можно увидеть гораздо более приятные глазу результаты. Для начала, взглянем на «новый процесс»:
Теперь, новый процесс использует всего около 7MiB. Такое уменьшение вызвано тем что таблицы управления страницами (page table) теперь требуют меньше места, из-за того что используются большие страницы, для управления тем же объемом памяти нужно в 512 раз меньше элементов чем раньше (4KiB * 512 = 2MiB).
Теперь давайте посмотрим что произойдет при доступе к большим объемам данных в памяти:
В отличие от самого первого эксперимента, эти процессы используют всего 12MiB и 9MiB соответственно, в то время как в прошлый раз использовалось 3GiB и 2.7GiB.
Разница довольно очевидна.
Это следствие того, как в Linux реализован учёт использования больших страниц, а не потому, что мы использовали на порядки меньше памяти: используемые большие страницы не отображаются как часть значения RSS в выводе ps и top.
Для чего используются файлы global.stat / global.tmp?
Postgresql содержит функциональные возможности для сбора статистики и информации о состоянии своей работы. Функция описана в разделе 27.2 данного руководства.
Эта информация сопоставляется , Он доступен для других процессов postgresql через файл. При первом запуске запроса, который обращается к этим данным в транзакции, сервер, к которому вы подключены, будет читать файл и кешировать результат, используя его до конца транзакции.
Для поддержания этого файла в актуальном состоянии процесс сбора статистики периодически перезаписывает его с обновленной информацией. Обычно это происходит несколько раз в секунду. Процесс выглядит следующим образом:
- Создайте новый файл global.tmp
- Запишите данные в этот файл
- Переименуйте global.tmp в global.stat, перезаписав предыдущий global.stat
а также файлы записываются в каталог, настроенный параметром конфигурации stats_temp_directory. Обычно это установлено на ,
При выключении файл статистики записывается в файл и файлы в директории tmp выше удалены. Этот файл затем читается и удаляется при повторном запуске базы данных.
Увеличиваем точность
Однако даже если считать использование памяти без учета разделяемой памяти, это всё еще является переоценкой реального использования памяти. Тут есть две причины:
Первое, на самом деле учет RssFile в использовании памяти не играет роли — по факту это всего лишь исполняемый файл и используемые им разделяемые библиотеки (Postgres не использует mmap() для каких-либо файлов). Все эти файлы являются общими для всех процессов в системе и практически не дают накладных расходов для постгресовых процессов.
Второе, RssAnon также переоценивает использование памяти. Смысл тут в том что ps показывает всю память процесса целиком, при том что большая часть этой памяти в случае создания нового процесса делится между пользовательским соединением и памятью родительского процесса postgres (так же известен как postmaster). Это следует из того что Linux не копирует всю память целиком когда создает новый процесс (при выполнении операции fork()), вместо этого используется механизм Copy-on-Write для копирования в новый процесс, набора только измененных страниц.
Таким образом, пока нет хорошего способа аккуратно и точно измерить использование памяти отдельно взятого нового процесса. Но все не так плохо, начиная с версии 4.14 ядро предоставляет еще одну статистику (коммит с описанием) процесса в /proc/$pid/smaps_rollup файле. Pss показывает «принадлежащую процессу пропорциональную долю отображения» среди всех отображений этого процесса (детали можно найти в документации поиском по smaps_rollups и Pss которые сами по себе не имеют прямых ссылок). Для сегмента памяти используемого совместно между несколькими процессами, доля будет представлять собой отношение размера этого сегмента на количество процессов которые используют этот сегмент.
Pss_Anon включает в себя анонимную память используемую процессом, Pss_File включает память используемую под разделяемые библиотеки задействование процессом, и Pss_Shmem (если не используются большие страницы) показывает использование общей памяти разделенное на все процессы которые обращались к соответствующим страницам.
Но у пропорциональных значений есть небольшой недостаток, это использование делителя который зависит от числа подключений к серверу. Здесь я использовал pgbench (scale 1000, -S -M prepared -c 1024) чтобы создать большое число подключений:
И с использованием huge_pages=on:
К сожалению Pss значения учитывают только те ресурсы, что видны приложению. Например, размер таблицы страниц не учитывается. Размер таблицы страниц можно увидеть в уже упоминавшемся `/proc/$pid/status`.
Я не уверен, но насколько я знаю, VmPTE (размер таблицы страниц) полностью приватный для каждого процесса, но остальное большинство Vm* значений, включая стек VmStk являются общими через copy-on-write.
Учитывая всё это, накладные расходы с учетом таблицы страниц и с huge_pages=off:
и с huge_pages=on:
Конечно обслуживание каждого процесса в ядре наверняка предполагаются еще какие-то отдельные небольшие накладные расходы, но они настолько малы, что они даже не представлены в файле статистики.
Почему процессор сборщика статистики создает такую большую нагрузку ввода / вывода?
Как правило, объем данных, записываемых в global.stats, относительно скромен, и запись его не генерирует такой большой трафик ввода-вывода. Однако при некоторых обстоятельствах это кажется очень раздутым. Когда это происходит, объем создаваемой нагрузки может стать чрезмерным, поскольку весь файл перезаписывается чаще, чем раз в секунду.
У меня был один опыт, когда он вырос в 10 или более раз по сравнению с другими подобными серверами. У этой машины было необычайно большое количество баз данных (по крайней мере, для нашего приложения — 30-40 баз данных, но ничего похожего на 6000, как вы говорите, у вас есть). Возможно, что наличие большого количества баз данных усугубляет это.
В некоторых из приведенных ниже ссылок говорится о шаблоне создания / удаления большого количества таблиц, вызывающих раздувание в этих файлах, и о том, что, возможно, автоочистка работает недостаточно агрессивно, чтобы удалить связанный с этим раздув. Вы можете рассмотреть ваши настройки autovac.
