Профессиональные
IT услуги

+7 (499) 390-44-68

Заказать звонок

Задать вопрос

Войти

Ваш город

Москва

info@it-domain.ru

Москва, ул.Ратная, д.16, корп.3

Сравнение0 Избранные товары 0 Корзина 0

Контактная информация

Москва, ул.Ратная, д.16, корп.3

info@it-domain.ru

Установка 1C Server + PostgreSQL 13 + Apache + Эмулятор HASP в CentOS 8 на VDS Timeweb

28 марта 2024 12:00

Актуальная инструкция со всеми работающими ссылками на текущую дату.

Основные разделы

Программы для работы
Установка и настройка ОС CentOS 8 Timeweb
Установка и настройка PostgreSQL 13
Установка и настройка 1C сервера
Установка и настройка драйвера HASP
Настройка Firewalld
Создание базы 1C
Установка и настройка публикации 1С на вебсервере Apache
Установка и настройка драйвера и эмулятора HASP
Резервное копирование и обслуживание баз 1С
Восстановление базы
Обновление платформы 1C
Тестируем производительность тарифов Timeweb
Тюнинг PostgreSQL 13
1C файловый режим на Windows Server 2022 Timeweb
1C сервер на PostgreSQL 13 и Windows Server 2022 Timeweb
Тест Гилева на локальной конфигурации

Программы для работы

WinSCP - это графический клиент SFTP (SSH File Transfer Protocol) для Windows с открытым исходным кодом
Download latest WinSCP

PuTTY — свободно распространяемый клиент для различных протоколов удалённого доступа, включая Telnet, SSH, SFTP, SCP, Rlogin.
Download latest PuTTY

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

Установка и настройка ОС CentOS 8 Timeweb

1. Используем конструктор VDS Timeweb и выбираем нужные параметры (CPU, RAM, NVME) под нужное кол-во пользователей и баз данных 1С и выбираем ОС CentOS 8

Для моей конфигурации было выбрано CPU-4, RAM-4, NVME-50Гб – 1092 руб/мес. В любой момент можно поменять значения (кроме уменьшения размера NVME). Регион выбран Санкт-Петербург SPB-1 (IP Адрес сети 2xx.xxx.xxx), на других были проблемы разного характера или просто попал в момент теста в пиковую нагрузку (SPB-3 проблемы с сетью, SPB-4 медленный тариф без перехода на тариф High CPU). Самостоятельно тестируем и выбираем оптимальный вариант.

2. Обновляем CentOS, устанавливаем исходники ядра и необходимые пакеты

yum -y update
yum -y install epel-release
yum -y install wget bzip2 traceroute net-tools nano bind-utils telnet htop atop iftop lsof tar zip unzip mc git rsync policycoreutils-python-utils

Hostname сервера

Узнаем текущее имя Timeweb

nano /etc/hosts

127.0.0.1 xxxxxx-cmxxxxx.twc1.net

Можем оставить его или установить своё

На клиентской машине вносим изменения и добавляем строчку (IP адрес берём из панели Timeweb)
xxx.xxx.xxx.xxx xxxxxx-cmxxxxx.twc1.net

Для Linux

nano /etc/hosts

Для Windows
c:\Windows\System32\drivers\etc\hosts

На клиентской машине сервер должен отвечать на ping по доменному имени

Установка и настройка PostgreSQL 13

3. Обновляем доступные репозитории пакетов согласно инструкции.

curl -o pgpro-repo-add.sh https://repo.postgrespro.ru/std-13/keys/pgpro-repo-add.sh
sudo sh pgpro-repo-add.sh

4. Устанавливаем PostgreSQL PRO std 13 версии

yum -y install postgrespro-std-13

5. Проверяем статус

systemctl status postgrespro-std-13

6. Останавливаем сервис СУБД и удаляем базу, которая создалась по умолчанию

systemctl stop postgrespro-std-13
rm -rf /var/lib/pgpro/std-13/data

7. Инициализируем БД, модифицируем настройки под работу с 1C и добавляем поддержку русского языка

/opt/pgpro/std-13/bin/pg-setup initdb --tune=1c --locale=ru_RU.UTF-8

8. Добавляем сервис в автозагрузки и проверяем доступность порта 5432

systemctl enable --now postgrespro-std-13
ss -nltup

Настройка Postgres PRO

9. Разрешим авторизовываться пользователям из нашей сети

nano /var/lib/pgpro/std-13/data/pg_hba.conf

Добавляем локальную подсеть в данной области

#IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all 192.168.0.0/24 md5

10. Создадим пароль для пользователя postgres. Указываем свой пароль

su - postgres 
psql
ALTER USER postgres WITH ENCRYPTED PASSWORD 'DJcn@1kdSmzxS^';
\q
exit

11. Перезапускаем сервис postgrespro-std-13

systemctl restart postgrespro-std-13

Установка и настройка 1C сервера

12. Скачиваем не последнюю версию 1C сервера с сайта 1С

Почему не последнюю, потому что, в ней могут быть ошибки, баги. Если вы переносите вашу базу и она стабильно работает на последней версии, тогда качаем последнюю.

Необходимо скачать и установить Cервер 1С:Предприятия (64-bit) для RPM-based Linux-систем. Идем на https://releases.1c.ru/total и скачиваем нужную вам версию.

Используем WinSCP и передаем файл в папку tmp или загружаем со своего ресурса, куда предварительно загрузили пакет

cd /tmp
wget https://%сайт%/rpm64_8_3_23_1912.tar.gz

13. Распаковываем архив с сервером 1C и устанавливаем его

cd /tmp
tar xvf rpm64_8_3_23_1912.tar.gz
yum -y localinstall *.rpm

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

14. Запуск как сервиса

Документация

Для ОС Linux (кроме CentOS 8) необходимо выполнить команду (заменяем номер версии 8.3.23.1912 на свой)

systemctl link /opt/1cv8/x86_64/8.3.23.1912/srv1cv8-8.3.23.1912@.service

15. Меняем владельца и группу директории /opt/1C

chown -R usr1cv8:grp1cv8 /opt/1cv8/

16. Если мы сейчас попытаемся запустит юнит или добавить в автоматический запуск, то может появиться ошибка - Failed to enable unit: Unit file /opt/1cv8/x86_64/8.3.23.1912/srv1cv8-8.3.23.1912@.service is masked. Так как симлинк идет на файл srv1cv8-8.3.23.1912@.service нулевого размера (он пустой), то это равносильно /dev/null, поэтому и происходит mask. Проверим не пустой ли файл и если пустой, то запишем в него эти данные (заменяем номер версии 8.3.23.1912 на свой)

nano /opt/1cv8/x86_64/8.3.23.1912/srv1cv8-8.3.23.1912@.service

[Unit]
Description=1C:Enterprise Server 8.3 (8.3.23.1912) (%I)
Requires=network.target
[Service]
# 1C:Enterprise server keytab file.
# default - usr1cv83.keytab file in 1C:Enterprise server
#           installation directory
#
Environment=SRV1CV8_KEYTAB=/opt/1cv8/x86_64/8.3.23.1912/usr1cv8.keytab
# Cluster agent main port
Environment=SRV1CV8_PORT=1540
# Cluster main port for default cluster.
# This port is used by the cluster agent to address
# the central server. Cluster port is also specified
# as the IP port of the working server.
Environment=SRV1CV8_REGPORT=1541
# Port range for connection pool
# example values:
#   45:49
#   45:67,70:72,77:90
Environment=SRV1CV8_RANGE=1560:1591
# 1C:Enterprise server configuration debug mode
# DEBUG off: empty (default)
# TCP    on: -debug or "-debug -tcp"
# HTTP   on: "-debug -http"
Environment=SRV1CV8_DEBUG=
# Path to directory with cluster data
Environment=SRV1CV8_DATA=/home/usr1cv8/.1cv8/1C/1cv8
# Security level:
# 0 - default - unprotected connections
# 1 - protected connections only for the time of user
#     authentication
# 2 - permanently protected connections
Environment=SRV1CV8_SECLEV=0
# Check period for connection loss detector, milliseconds
Environment=SRV1CV8_PINGPERIOD=1000
# Response timeout for connection loss detector, milliseconds
Environment=SRV1CV8_PINGTIMEOUT=5000

Type=simple
User=usr1cv8
Group=grp1cv8
ExecStart=/opt/1cv8/x86_64/8.3.23.1912/ragent \
                        -d ${SRV1CV8_DATA} \
                        -port ${SRV1CV8_PORT} \
                        -regport ${SRV1CV8_REGPORT} \
                        -range ${SRV1CV8_RANGE} \
                        -seclev ${SRV1CV8_SECLEV} \
                        -pingPeriod ${SRV1CV8_PINGPERIOD} \
                        -pingTimeout ${SRV1CV8_PINGTIMEOUT} \
                        $SRV1CV8_DEBUG
Restart=always
RestartSec=1
[Install]
DefaultInstance=default
WantedBy=multi-user.target

17. Добавляем в автозагрузку и запускаем

Включить автоматический запуск

systemctl enable srv1cv8-8.3.23.1912@.service

Команда запуска сервиса:

systemctl start srv1cv8-8.3.23.1912@default.service

Команда проверки статуса сервиса:

systemctl status srv1cv8-8.3.23.1912@default.service

В выводе команды должно быть отображено "Active: active (running)".

Проверка открытых портов сервера 1С

ss -tlnpu | grep 15

На экране должны отобразиться открытые сетевые сокеты.

Установка и настройка драйвера HASP

18. Устанавливаем необходимую утилиту

yum -y install glibc

19. Скачиваем и устанавливаем драйвер HASP

cd /tmp
wget https://download.etersoft.ru/pub/Etersoft/HASP/last/CentOS/7/haspd-8.23-eter3centos.x86_64.rpm
yum -y localinstall haspd*

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

systemctl restart haspd

Смотрим статус

systemctl status haspd

Настройка Firewalld

20. Открываем порты

firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=475/tcp
firewall-cmd --permanent --add-port=1540/tcp
firewall-cmd --permanent --add-port=1541/tcp
firewall-cmd --permanent --add-port=1560/tcp
firewall-cmd --permanent --add-port=5432/tcp
firewall-cmd --reload
firewall-cmd --list-all

Создание базы 1C

21. На компьютер устанавливаем толстый клиент 1С Предприятие той же версии что и сервер, во время установки обязательно выбираем компонент «Администрирование серверов 1С Предприятия»

22. Запускаем «Администрирование серверов 1C Предприятия», в открывшемся окне выбираем Создать - Центральный сервер 1С:Предприятие 8.3, указываем данные сервера

Протокол: TCP
Имя: xxxxxx-cmxxxxx.twc1.net (берем из Hostname сервера п.2)
IP порт: 1540

23. Переходим в раздел Кластеры - Локальный кластер. Выбираем "Local cluster" - Информационные базы - ПКМ - Создать - Информационная база. Указываем данные для создания новой базы

Имя: base1c
Защищенное соединение: выключено
Сервер баз данных: xxxxxx-cmxxxxx.twc1.net (берем из Hostname сервера п.2)
Тип СУБД: PostgreSQL
База данных: base1c
Пользователь сервера БД: postgres
Пароль пользователя БД: DJcn@1kdSmzxS^ (этот пароль был задан на этапе установки БД п.10)
Разрешить выдачу лицензий сервером 1С:Предприятия: Да
Язык (Страна): русский (Россия)
Создать базу данных в случае ее отсутствия: Да
Установить блокировку регламентных заданий: Нет

Установка и настройка публикации 1C на вебсервере Apache

24. Установка шрифтов для публикации на вебсервере

yum -y install rpm-build ttmkfdir fontconfig freetype libgsf unixODBC
cd /tmp
wget https://rpmfind.net/linux/epel/8/Everything/x86_64/Packages/c/cabextract-1.9-7.el8.x86_64.rpm
yum -y localinstall cabextract-1.9-7.el8.x86_64.rpm
wget https://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec

(если не скачиваются шрифты, надо запустить команду еще раз, до тех пор, пока не начнется скачивание)

rpmbuild -bb msttcorefonts-2.5-1.spec

Устанавливаем

yum -y install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm

25. Устанавливаем веб-сервер Apache c поддержкой ssl

yum -y install httpd mod_ssl

Так как компания 1С рекомендует использовать модуль мультипроцессорной обработки worker, выясняем с каким модулем работает наш сервер

apachectl -V | grep -i mpm

И если это prefork или event, то меняем его на mpm_worker в /etc/httpd/conf.modules.d/00-mpm.conf (комментируем старую строчку и расскомментируем новую)

nano /etc/httpd/conf.modules.d/00-mpm.conf

создаем службу, запускаем апач и проверяем статус

systemctl enable --now httpd

Проверяем статус

systemctl status httpd

26. Создадим каталог, он будет использован как путь публикации для web-сервера 1C

mkdir -p /var/www/infobase

27. Создадим пустой файл, он будет указан в качестве конфигурационного файла web-сервера 1С

touch /etc/httpd/conf.d/base.conf

28. Публикуем базу 1C. Указываем свою версию вместо 8.3.23.1912 и Hostname сервера вместо xxxxxx-cmxxxxx.twc1.net из п.2

cd /opt/1cv8/x86_64/8.3.23.1912/
./webinst -apache24 -wsdir base1c -dir /var/www/infobase/ -connStr "Srvr=xxxxxx-cmxxxxx.twc1.net;Ref=base1c;" -confPath /etc/httpd/conf.d/base.conf

Где
-dir — путь к папке вебсервера, ранее созданная директория
-connStr — путь к расположеныю файловой базы 1С
-confPath — путь к файлу конфигурации вебсервера, ранее созданный файл (должен быть быть пустым)
-publish - указывает необходимое действие, в данном случае публикацию, может быть опущен, так как это действие по умолчанию
-wsdir - имя публикации, по которому к базе следует обращаться из браузера, обратите внимание, что оно регистрозависимое
-connstr - строка соединения, состоит из нескольких частей: Srvr - имя сервера, Ref - имя базы на сервере, каждая часть должна заканчиваться служебным символом ";"

29. Меняем владельца и группу созданного файла, перезапускаем Apache

chown apache:apache /var/www/infobase/default.vrd
systemctl restart httpd

Проверяем в браузере: Либо по ip или по имени (берем из Hostname сервера п.2)

http://xxx.xxx.xxx.xxx/base1c
http://xxxxxx-cmxxxxx.twc1.net/base1c

30. Выпуск самоподписанного сертификата

cd /etc/ssl/certs

Указываем Hostname сервера из п.2 вместо xxxxxx-cmxxxxx.twc1.net

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout xxxxxx-cmxxxxx.twc1.net.key -out xxxxxx-cmxxxxx.twc1.net.crt

Во время выполнения команды будет задано несколько вопросов. Для "Common Name (e.g. server FQDN or Your bane)" нужно также указать имя сервера. Остальные поля заполняются произвольно (кроме "Country name" - здесь можно оставить по умолчанию).

Откройте конфигурационный файл Apache для SSL

nano /etc/httpd/conf.d/ssl.conf

Найдите раздел, который начинается с < VirtualHost _default_:443>

Затем раскомментируйте строку ServerName (вместо www.example.com укажите свое доменное имя или IP, в зависимости от того, что было указано в поле Common Name).

Указываем Hostname сервера из п.2 вместо xxxxxx-cmxxxxx.twc1.net

ServerName xxxxxx-cmxxxxx.twc1.net:443

Найдите строки SSLCertificateFile и SSLCertificateKeyFile и укажите в них адрес ключа и сертификата – каталог /etc/ssl/certs:

Указываем Hostname сервера из п.2 вместо xxxxxx-cmxxxxx.twc1.net

SSLCertificateFile /etc/ssl/certs/xxxxxx-cmxxxxx.twc1.net.crt
SSLCertificateKeyFile /etc/ssl/certs/xxxxxx-cmxxxxx.twc1.net.key

После изменений, сохраните и закройте файл.

Перезапустите сервер Apache

systemctl restart httpd

Установка Сервера 1C с базой данных PostgreSQL и публикацией сервера в web завершена. Можно подключать ключ с лицензией к серверу и работать.

Если вы разворачиваете ради тестирования, можно установить эмулятор HASP.

Установка и настройка драйвера и эмулятора HASP

31. Устанавливаем утилиты сборки

yum -y install gcc gcc-c++ make

32. Устанавливаем заголовки ядра

yum install -y kernel-devel-`uname -r`

33. Устанавливаем утилиты для сборки зависимостей

yum -y install jansson-devel libusb.i686 elfutils-libelf-devel

34. Скачиваем исходники VHCI_HCD, LIBUSB_VHCI и USB_HASP в каталог /usr/src

cd /usr/src
wget https://sourceforge.net/projects/usb-vhci/files/linux%20kernel%20module/vhci-hcd-1.15.tar.gz/download -O vhci-hcd-1.15.tar.gz
wget https://sourceforge.net/projects/usb-vhci/files/native%20libraries/libusb_vhci-0.8.tar.gz/download -O libusb_vhci-0.8.tar.gz
git clone https://github.com/sam88651/UsbHasp.git

35. Распаковываем исходники VHCI_HCD и LIBUSB_VHCI

tar -xpf libusb_vhci-0.8.tar.gz
tar -xpf vhci-hcd-1.15.tar.gz

36. Компилируем VHCI_HCD

KVER=`uname -r`
cd vhci-hcd-1.15
mkdir -p linux/${KVER}/drivers/usb/core
cp /usr/src/kernels/${KVER}/include/linux/usb/hcd.h linux/${KVER}/drivers/usb/core
sed -i 's/#define DEBUG/\/\/#define DEBUG/' usb-vhci-hcd.c
sed -i 's/#define DEBUG/\/\/#define DEBUG/' usb-vhci-iocifc.c
sed -i 's/VERIFY_READ, //' usb-vhci-iocifc.c
sed -i 's/VERIFY_WRITE, //' usb-vhci-iocifc.c
make KVERSION=${KVER}

37. Устанавливаем VHCI_HCD

make install

38. Загружаем модуль usb_vhci_hcd

echo "usb_vhci_hcd" | sudo tee /etc/modules-load.d/usb_vhci.conf
modprobe usb_vhci_hcd

39. Загружаем модуль usb_vhci_iocifc

echo "usb_vhci_iocifc" | sudo tee -a /etc/modules-load.d/usb_vhci.conf
modprobe usb_vhci_iocifc

40. Компилируем LIBUSB_VHCI

cd ../libusb_vhci-0.8
./configure
make -s

41. Устанавливаем LIBUSB_VHCI

make install
echo "/usr/local/lib" | sudo tee /etc/ld.so.conf.d/libusb_vhci.conf
ldconfig

42. Компилируем UsbHasp

cd ../UsbHasp

# В /usr/src/UsbHasp/nbproject/Makefile-Release.mk заменить CFLAGS= на CFLAGS=-std=gnu99

nano /usr/src/UsbHasp/nbproject/Makefile-Release.mk

make

если появляется ошибка fatal error: jansson.h: No such file or directory #include < jansson.h>, то переустанавливаем jansson-devel

yum -y install jansson-devel
make

43. Устанавливаем UsbHasp

cp /usr/src/UsbHasp/dist/Release/GNU-Linux/usbhasp /usr/bin

44. Создаем директорию для дампов usb-ключей

mkdir /etc/haspkey/

45. Создаем системный unit usbhaspemul.service

nano /etc/systemd/system/usbhaspemul.service

записываем в него

[Unit]
Description=Emulation HASP key for 1C
Requires=haspd.service
After=haspd.service
[Service]
Type=simple
ExecStart=/usr/bin/sh -c 'find /etc/haspkey -name "*.json" | xargs /usr/bin/usbhasp'
Restart=always
[Install]
WantedBy=multi-user.target

46. Добавляем службу usbhaspemul в автозагрузку

systemctl daemon-reload
systemctl enable usbhaspemul

47. Загружаем дампы usb-ключей (ищем в интернете) в каталог /etc/haspkey/

Используем WinSCP и передаем файлы

Или загружаем со своего ресурса, куда предварительно загрузили файлы

cd /etc/haspkey/
wget https://%сайт%/1c_server_x64.json
wget https://%сайт%/1c_100user.json

48. Запускаем USB HASP Emulator, проверяем статус

systemctl start usbhaspemul
systemctl status usbhaspemul

Резервное копирование и обслуживание баз 1C

49. Создадим папку для бекапов

mkdir /opt/backup

50. Создаем директории Day, Week, Month и назначим владельцем postgres:

mkdir /opt/backup/Day /opt/backup/Week /opt/backup/Month 
chown -R postgres:postgres /opt/backup

51. Создаем папки для записи лог файлов:

mkdir /var/log/postgresql/ /var/log/postgresql/Day /var/log/postgresql/Week /var/log/postgresql/Month
chown -R postgres:postgres /var/log/postgresql/

52. Cоздаем скрипт buckup.sh для резервного копирования и обслуживания базы:

nano /var/log/postgresql/buckup.sh

Записываем в него данный код

#!/bin/sh
#Установим период, по истечению которого удалятся старые бекапы
days=$2
#Установим тип резервного копирования
type=$1
# Устанавливаем дату
DATA=`date +"%Y-%m-%d_%H-%M"`
# Записываем информацию в лог с секундами
echo "----------------------------$DATA---------------------------------------" >> /var/log/postgresql/$type/backup.log
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start backup base1c" >> /var/log/postgresql/$type/backup.log
# Бэкапим базу данных base1c и сразу сжимаем
/usr/bin/pg_dump -U postgres base1c | pigz > /opt/backup/$type/$DATA-base1c.sql.gz
echo "`date +"%Y-%m-%d_%H-%M-%S"` End backup base1c" >> /var/log/postgresql/$type/backup.log
echo "------------------------------------------------------------------------" >> /var/log/postgresql/$type/backup.log
# Удаляем в папке с бэкапами старые архивы
/usr/bin/find /opt/backup/$type -type f -mtime +$days -exec rm -rf {} \;
sleep 2
#Очистка и анализ базы
echo "----------------------------$DATA---------------------------------------" >> /var/log/postgresql/$type/service.log
# Записываем информацию в лог с секундами
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start vacuumdb base1c" >> /var/log/postgresql/$type/service.log
vacuumdb --verbose --analyze --full --quiet --dbname=base1c
echo "`date +"%Y-%m-%d_%H-%M-%S"` End vacuumdb base1c" >> /var/log/postgresql/$type/service.log
echo "------------------------------------------------------------------------" >> /var/log/postgresql/$type/service.log
#Перестроение индекса
sleep 2
echo "`date +"%Y-%m-%d_%H-%M-%S"` Start reindex base1c" >> /var/log/postgresql/$type/service.log
/usr/bin/reindexdb --username postgres --dbname base1c
echo "`date +"%Y-%m-%d_%H-%M-%S"` End reindex base1c" >> /var/log/postgresql/$type/service.log
echo "------------------------------------------------------------------------" >> /var/log/postgresql/$type/service.log

53. Добавляем привилегии на запуск:

chmod +x /var/log/postgresql/buckup.sh

54. Создаем задания для пользователя postgres

nano /var/spool/cron/postgres

Записываем в него данный код

# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
0 1 * * 1-6 sh /var/log/postgresql/buckup.sh Day 6
0 1 * * 7 sh /var/log/postgresql/buckup.sh Week 28
0 0 1 * * sh /var/log/postgresql/buckup.sh Month 121

Назначим владельцем postgres

chown postgres:postgres /var/spool/cron/postgres

Восстановление базы

Восстановление из бэкапа

sudo -u postgres psql base1c < /opt/backup/base1c.backup

Либо заходим в 1C конфигуратор базы и восстанавливаем базу вручную

Обновление платформы 1C

Скачиваем новую версию в данном случае 8.3.23.2040 По аналогии с п.12

Везде указываем свои версии вместо 8.3.23.1912, 8.3.23.2040 и Hostname сервера вместо xxxxxx-cmxxxxx.twc1.net

cd /tmp
wget https://%сайт%/rpm64_8_3_23_2040.tar.gz

или пользуемся WinSCP и передаем файл в папку tmp

Остановим сервис 1С

systemctl stop srv1cv8-8.3.23.1912@default.service

Удаляем старый симлинк

rm -rf /etc/systemd/system/srv1cv8-8.3.23.1912@.service

Найдём старый пакет и удалим его

yum search 1c
yum remove 1c-enterprise-8.3.23.1912-common.x86_64

Удаляем папку от старой версии

rm -rf /opt/1cv8/x86_64/8.3.23.1912/

Распаковываем и устанавливаем новую версию по аналогии с п.13

cd /tmp
tar xvf rpm64_8_3_23_2040.tar.gz
yum -y localinstall *.rpm

Запускаем как сервис по аналогии с п.14

systemctl link /opt/1cv8/x86_64/8.3.23.2040/srv1cv8-8.3.23.2040@.service

Далее добавляем в загрузку и запускаем по аналогии с п.17 не забываем подставлять новую версию вместо старой - вместо 8.3.23.1912 ставим 8.3.23.2040. В вашем случае прописываем вашу версию.

systemctl enable srv1cv8-8.3.23.2040@.service
systemctl start srv1cv8-8.3.23.2040@default.service
systemctl status srv1cv8-8.3.23.2040@default.service

Обновляем публикацию базы. Указываем свои версии вместо 8.3.23.2040 и Hostname сервера вместо xxxxxx-cmxxxxx.twc1.net

cd /opt/1cv8/x86_64/8.3.23.2040/
./webinst -apache24 -wsdir base1c -dir /var/www/infobase/ -connStr "Srvr=xxxxxx-cmxxxxx.twc1.net;Ref=base1c;" -confPath /etc/httpd/conf.d/base.conf

Тестируем производительность тарифов Timeweb

Частота процессоров Timeweb
Из-за особенностей виртуализации частота, которую вы можете видеть при замерах, не отображает реальные характеристики процессора — система виртуализации показывает базовую частоту, без учета использования Turboboost. При этом центральный процессор платформы всегда работает в режиме Turboboost, гарантируя частоту, заявленную в тарифе.

Заходим с клиентской машины через конфигуратор и загружаем скачанную базу Гилева.

Тест Гилева
CPU –  QEMU Virtual CPU version 4.2.0 - 4 ядра - 2.6 ГГц / 3.3
RAM - 4 ГБ
СУБД - PostgresPro 13
Платформа 1C - 8.3.23.1912
ОС - CentOS 8 Stream
Диск - 50 Гб NVMe
Результат – 14.01

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

Если не установлена, то устанавливаем

yum -y install hdparm

Выводим список дисков и разделов

fdisk -l

Выбираем нужный раздел и запускаем тест (тест запускаем несколько раз, рассчитываем средний показатель)

Чтение с буферизацией

hdparm -t /dev/vda1

Чем больше объем пакета, тем больше скорость
Timing buffered disk reads: 3904 MB in 3.00 seconds = 1300.78 MB/sec
Timing buffered disk reads: 5560 MB in 3.00 seconds = 1852.69 MB/sec
Timing buffered disk reads: 6038 MB in 3.00 seconds = 2009.57 MB/sec

Чтение без буфера

hdparm -t --direct /dev/vda1

Timing O_DIRECT disk reads: 6066 MB in 3.00 seconds = 2020.72 MB/sec
Timing O_DIRECT disk reads: 6162 MB in 3.00 seconds = 2052.36 MB/sec
Timing O_DIRECT disk reads: 6636 MB in 3.00 seconds = 2210.95 MB/sec

Чтение кеша

hdparm -T /dev/vda1

Timing cached reads: 12948 MB in 1.99 seconds = 6506.33 MB/sec
Timing cached reads: 13434 MB in 1.99 seconds = 6753.11 MB/sec
Timing cached reads: 14624 MB in 1.99 seconds = 7345.67 MB/sec

hdparm выполняет последовательное чтение с диска. В реально работе скорость чтения диска будет другой.

Проверка скорости записи на диск

Проверяем стандартной утилитой linux - dd.

Создадим файл размером 1 Gb частями по 1Mb.

sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync

1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.24659 s, 861 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.41076 s, 761 MB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.38675 s, 774 MB/s

Создадим файл размером 8 Gb частями по 512Mb.

sync; dd if=/dev/zero of=tempfile bs=512M count=16; sync

8589934592 bytes (8.6 GB, 8.0 GiB) copied, 11.6891 s, 735 MB/s
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 10.5925 s, 811 MB/s
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 9.814 s, 875 MB/s

Тюнинг PostgreSQL 13 - пробуем поменять настройки postgresql.conf

nano /var/lib/pgpro/std-13/data/postgresql.conf

Расскоментируем необходимые значения и внесем изменения

max_connections = 100
Количество одновременных соединений, Максимальное число соединений. Ориентируйтесь на свои потребности

shared_buffers = 1GB (стояло 128MB)
Количество памяти, выделенной PostgreSQL для совместного кеша страниц. Эта память разделяется между всеми процессами PostgreSQL. Рекомендуемое значение - RAM/4 четверть доступного объема памяти, в нашем случае 1 ГБ.

temp_buffers = 256MB (было закомментированно)
Максимальное количество страниц для временных таблиц - верхний лимит размера временных таблиц в каждой сессии.

work_mem = 96MB (было закомментированно)
Лимит памяти для обработки одного запроса прежде, чем будут задействованы временные файлы на диске. Эта память индивидуальна для каждой сессии. Применяется для каждого соединения и каждой операции, поэтому итоговый объем используемой памяти может существенно превосходить указанное значение. Это один из тех параметров, вычисляемое значение которого калькулятором существенно отличается от рекомендаций 1С. Рекомендуемые значения - RAM/32..64 или 32MB..128MB. Для объема памяти в 4 ГБ рекомендуемыми значениями будут 64 - 128, мы выбрали 96 МБ.

maintenance_work_mem = 384MB (было закомментированно)
Лимит памяти для обслуживающих задач, например вакуум, автовакуума или создания индексов. Рекомендуемые значения - RAM/16..32 или work_mem * 4. В нашем случае 384MB.

max_files_per_process = 1000 (было закомментированно)
Максимальное количество открытых файлов на один процесс, в сборке от PostgresPro для Linux это значение по умолчанию.

bgwriter_delay = 20ms (было закомментированно)
bgwriter_lru_multiplier = 4.0 (было закомментированно)
bgwriter_lru_maxpages = 400 (было закомментированно)
Параметры процесса фоновой записи, который отвечает за синхронизацию страниц в shared_buffers с диском

effective_io_concurrency = 500 (было закомментированно)
Допустимое число одновременных операций ввода/вывода. Для жестких дисков указывается по количеству шпинделей, для массивов RAID5/6 следует исключить диски четности. Для SATA SSD это значение рекомендуется указывать равным 200, а для быстрых NVMe дисков его можно увеличить до 500-1000. При этом следует понимать, что высокие значения в сочетании с медленными дисками сделают обратный эффект, поэтому подходите к этой настройке грамотно. Рекомендуемые значения - 2 для RAID, 200 для SSD, 500..1000 для NVMe. В нашем случае среднее между 500 и 1000.

max_worker_processes = 4 (было закомментированно)
max_parallel_workers_per_gather = 2 (было закомментированно)
max_parallel_workers = 4 (было закомментированно)
max_parallel_maintenance_workers = 2 (было закомментированно)
Настройки фоновых рабочих процессов, выбираются исходя из количества процессорных ядер, берем значения из калькулятора. Выше указаны настройки для четырехъядерного СРU.

fsync = on (было закомментированно)
Сброс буферов на диск (выполнение PostgerSQL системных вызовов fsync()). Выключение параметра приводит к росту производительности, но появляется значительный риск потери всех данных при внезапном выключении питания.

wal_buffers = 16MB (было закомментированно)
Задает размер буферов журнала предзаписи (WAL, он же журнал транзакций), если оставить эту настройку без изменений, то сервер будет автоматически устанавливать это значение в 1/32 от shared_buffers, но не менее 64 КБ и не более размера одного сегмента WAL в 16 МБ.

commit_delay = 1000 (было закомментированно)
commit_siblings = 5 (было закомментированно)
Указывает задержку в мс перед записью транзакций на диск при числе открытых транзакций, указанных во второй опции. Имеет смысл при количестве транзакций более 1000 в секунду, на меньших значениях эффекта не имеет.

min_wal_size = 2GB (было 80MB)
max_wal_size = 8GB (было 1GB)
Минимальный и максимальный размер файлов журнала предзаписи. Рекомендуется установить его на достаточно высокое значение, чтобы уменьшить I/O операции записи, но не слишком высокое, чтобы избежать излишнего потребления места на диске. Рекомендуемые значения - 512MB..4G и 2..4 * min_wal_size. В нашем берем средние значения случае это 2 ГБ и 8 ГБ.

checkpoint_completion_target = 0.9
Скорость записи изменений на диск, рассчитывается как время между точками сохранения транзакций (чекпойнты) умноженное на данный показатель, позволяет растянуть процесс записи по времени и тем самым снизить одномоментную нагрузку на диски. Рекомендуемые значения - 0.5..0.9. В нашем случае использовано рекомендованное калькулятором максимальное значение 0.9.

seq_page_cost = 1 (было закомментированно)
Стоимость последовательного чтения с диска, является относительным числом, вокруг которого определяются все остальные переменные стоимости, данное значение является значением по умолчанию.

random_page_cost = 1.1 (было закомментированно)
random_page_cost = 1.5..2.0 для RAID, 1.1..1.3 для SSD
Стоимость случайного чтения с диска, чем ниже это число, тем более вероятно использование сканирования по индексу, нежели полное считывание таблицы, однако не следует указывать слишком низких, не соответствующих реальной производительности дисковой подсистемы, значений, иначе вы можете получить обратный эффект, когда производительность упрется в медленный случайный доступ.

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

Для производительных SSD можно использовать значения: seq_page_cost = 0.5 и random_page_cost = 0.5

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

effective_cache_size = 2GB (было закомментированно)
Определяет эффективный размер кеша, который может использоваться при одном запросе. Этот параметр не влияет на размер выделяемой памяти, не резервирует ее, а служит для ориентировочной оценки доступного размера кеша планировщиком запросов. Чем он выше, тем большая вероятность использования сканирования по индексу, а не последовательного сканирования. При расчете следует использовать выделенный серверу объем RAM, а не полный объем ОЗУ. 2/3 от RAM В нашем случае это 2 ГБ.

autovacuum = on (было закомментированно)
Включение автовакуума, это очень важный для производительности базы параметр. Не отключайте его!

autovacuum_max_workers = 4 (было закомментированно)
Рекомендуемые значения - NCores/4..2 но не меньше 4. Количество рабочих процессов автовакуума, рассчитывается по числу процессорных ядер, не менее 4, в нашем случае 4.

autovacuum_naptime = 20s (было закомментированно)
Время сна процессов автовакуума, большое значение будет приводить к неэффективно работе, слишком малое только повысит нагрузку без видимого эффекта.

row_security = off (было закомментированно)
Отключает политику защиты на уровне строк, данная опция не используется платформой и ее отключение дает некоторое повышение производительности.

max_locks_per_transaction = 256 (было закомментированно)
Максимальное количество блокировок в одной транзакции, рекомендация от 1C.

escape_string_warning = off (было закомментированно)
standard_conforming_strings = off (было закомментированно)
Данные опции специфичны для 1С и регулируют использование символа \ для экранирования.

Сохраним файл конфигурации и перезапустим PostgreSQL, в Linux это можно выполнить командами:

systemctl restart postgrespro-std-13

Результаты тюнинга

Результаты тестирования существенно не отличаются. В текущем варианте тестировалась «Россия SPB-1». Результаты тестов Гилева пляшет от 3 (на SPB-4) – 14 (на SPB-1). Тюнинг postgresql прироста по тесту Гилева не дал.

Тариф Timeweb High CPU - CentOS 8

Теперь поменяем конфигурацию сервера на более быстрый тариф High CPU и запустим тест снова

После перехода на тариф High CPU, тариф с конструктором станет недоступным. Можно будет только повышать тариф High CPU. Тестируем самый младший тариф, а так как мы переходим с тарифа конструктора с 50 Гб NVME, то самый младший будет указанный ниже. При создании с нуля выбираем любой тариф под свои потребности.

Тест Гилева
CPU –  QEMU Virtual CPU version 4.2.0 - 2 ядра - 3.19 ГГц/5 ГГц
RAM - 4 ГБ
СУБД - PostgresPro 13
Платформа 1C - 8.3.23.1912
ОС - CentOS 8 Stream
Диск - 50 Гб NVMe
Результат – 30.86

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

Чтение с буферизацией (скорость от старого тарифа не отличается)

hdparm -t /dev/vda1

Timing buffered disk reads: 4360 MB in 3.00 seconds = 1452.94 MB/sec
Timing buffered disk reads: 7716 MB in 3.00 seconds = 2570.20 MB/sec
Timing buffered disk reads: 9724 MB in 3.00 seconds = 3240.86 MB/sec

Чтение без буфера (скорость от старого тарифа не отличается)

hdparm -t --direct /dev/vda1

Timing O_DIRECT disk reads: 10438 MB in 3.00 seconds = 3477.93 MB/sec
Timing O_DIRECT disk reads: 10994 MB in 3.00 seconds = 3664.62 MB/sec
Timing O_DIRECT disk reads: 11476 MB in 3.00 seconds = 3823.26 MB/sec

Чтение кеша (скорость от старого тарифа не отличается)

hdparm -T /dev/vda1

Timing cached reads: 37744 MB in 1.99 seconds = 18980.44 MB/sec
Timing cached reads: 37888 MB in 1.99 seconds = 19054.66 MB/sec
Timing cached reads: 37372 MB in 1.99 seconds = 18793.58 MB/sec

hdparm выполняет последовательное чтение с диска. В реально работе скорость чтения диска будет другой.

Проверка скорости записи на диск

Проверяем стандартной утилитой linux - dd.

Создадим файл размером 1 Gb частями по 1Mb. (скорость увеличилась в 2 раза)

sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync

1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.490621 s, 2.2 GB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.712978 s, 1.5 GB/s
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.630069 s, 1.7 GB/s

Создадим файл размером 8 Gb частями по 512Mb. (скорость увеличилась в 2 раза)

sync; dd if=/dev/zero of=tempfile bs=512M count=16; sync

8589934592 bytes (8.6 GB, 8.0 GiB) copied, 5.20946 s, 1.6 GB/s
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 5.43277 s, 1.6 GB/s
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 5.12171 s, 1.7 GB/s

Результат смены тарифа

Производительность существенно выросла и находится в диапазоне от 17 до 31 по тесту Гилева в зависимости от загруженности серверов TimeWeb.

Теперь посмотрим, как работает 1C в файловом режиме на Windows Server 2022

Создадим новую виртуальную машину (CPU-4, RAM-8, NVME-35Гб), выберем ОС Windows Server 2022

Тест Гилева
CPU – QEMU Virtual CPU version 4.2.0 - 4 ядра - 2.6 ГГц/3.3
RAM - 8 ГБ
Платформа 1C - 8.3.23.1912
ОС – Win Server 2022
Диск - 35 Гб NVMe
Результат – 17.12

Ранее полученные результаты

Тест Гилева
Результат – 12.72

Тест Гилева
Результат – 10.68

Результаты тарифа

Производительность находится в диапазоне от 10 до 17 по тесту Гилева в зависимости от загруженности TimeWeb.

Тариф Timeweb High CPU - Win Server 2022

Протестируем Timeweb High CPU – поменяем тариф в настройках сервера и выберем данный

Тест Гилева
CPU – QEMU Virtual CPU version 4.2.0 - 4 ядра - 3.19 ГГц/5 ГГц
RAM - 8 ГБ
Платформа 1C - 8.3.23.1912
ОС – Win Server 2022
Диск - 80 Гб NVMe
Результат – 39.06

Получили уже высокие результаты (самый высокий результат из протестированных на данном тарифе).

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

Тест Гилева
Результат – 20

Тест Гилева
Запустив еще один тест, дисковая подсистема стала работать быстрее
Результат – 21.28

Теперь посмотрим, как работает 1с сервер с СУБД PostgresPro 13 на Windows Server 2022 на максимальном тарифе

Виртуальная машина (CPU-8, RAM-16, NVME-160Гб) ОС Windows Server 2022

Тест Гилева
CPU –  QEMU Virtual CPU version 4.2.0 - 8 ядер - 3.19 ГГц/5 ГГц
RAM - 16 ГБ
СУБД - PostgresPro 13
Платформа - 8.3.22.2239
ОС - Win Server 2022
Диск - 160 Гб NVMe
Результат – 13.77

Заключение

Во время работы сервера, скорость дисковой подсистемы меняется (так как это VDS, а не аренда сервера или локальный компьютер, где все ресурсы принадлежат нам), от этого меняются результаты тестов. Выбрав тариф High CPU получаем более быструю дисковую систему и процессор. При переходе на тариф High CPU, вернуться на конфигуратор, становится не доступным, также если увеличиваете объём диска, то уменьшить его уже не получится. А что использовать Linux или Windows, это уже вам выбирать.

Тест Гилева на локальной конфигурации

Тест Гилева
CPU – Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz   3.70 GHz
RAM - 24 ГБ
Платформа 1C - 8.3.23.1912
ОС – Win 10 Pro
Диск - Hitachi HDS721010CLA332 
Результат – 56.18

Тест Гилева
CPU – Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz   3.70 GHz
RAM - 24 ГБ
Платформа 1C - 8.3.23.1912
ОС – Win 10 Pro
Диск - SSD Smartbuy 240GB
Результат – 56.82

Тест Гилева
CPU – 11th Gen Intel(R) Core(TM) i5-11600KF@ 3.9 ГГц / 4.9 ГГц
RAM - 16 ГБ
Платформа 1C - 8.3.23.1912
ОС – Win 10 Pro
Диск - SPCC M.2 PCIe SSD (476 ГБ)
Результат – 108.7

Комментарии

Загрузка комментариев...

Назад к списку