🐧 Linux + PostgreSQL – сбор параметров и диагностика ← На главную
⚠️ Внимание: Некоторые команды требуют прав суперпользователя (sudo). Запускайте их от имени пользователя с правами sudo.
📦 Если команда iostat не найдена – установите пакет sysstat: sudo apt update && sudo apt install sysstat -y
🗂️ Тип конфигурации 1С: Влияет на расход RAM сервера приложений (БП: ~2 ГБ/польз., УТ/ЗУП: ~2.5 ГБ/польз., ERP/КА: ~3.5 ГБ/польз.)
⚡ Результат теста Гилёва (TPC-1C): (оп/с – условных операций в секунду)
ПараметрКоманда для выполненияЗначениеНорма / примечание
👥 Активных пользователей (пик) оцените по журналу 1С ключевой параметр
💾 Размер всех БД (ГБ) sudo -u postgres psql -c "SELECT round(sum(pg_database_size(datname))/1024.0/1024,1) FROM pg_database;" влияет на кэш
⚡ Интенсивность нагрузки анализ типовых операций тяжёлая +40% ресурсов
🖥️ Логических ядер CPU nproc для 1С+PG ≥4 ядер
📈 Load average (1 мин) uptime | awk -F 'load average:' '{print $2}' | cut -d, -f1 <0.7×ядер
💿 Общий RAM (ГБ) free -h | grep Mem | awk '{print $2}' ≥16 ГБ для малых БД
🧠 Свободно RAM (ГБ) free -h | grep Mem | awk '{print $7}' >10% от общего
🔄 Используемый swap (ГБ) free -h | grep Swap | awk '{print $3}' 0 – идеал, >1 – кризис
💽 Тип дискового массива lsblk -d -o NAME,ROTA | grep -v "loop" (0=SSD/NVMe, 1=HDD) Влияет на пороги латентности await\n(рекомендуем NVMe для БД)
💽 await диска (мс) iostat -x 1 3 | grep -E "sd|nvme" | tail -1 | awk '{print $10}' NVMe<2, SSD<5, HDD<20 – пороги зависят от типа диска
⏳ avgqu-sz (очередь) iostat -x 1 3 | grep -E "sd|nvme" | tail -1 | awk '{print $9}' <2.5 – норма, выше – недостаточно IOPS
🐘 PostgreSQL cache hit % sudo -u postgres psql -t -c "SELECT round(sum(blks_hit)*100.0/(sum(blks_hit)+sum(blks_read)),2) FROM pg_stat_database WHERE blks_read+blks_hit>0;" >98% – отлично, <90% – критически мало RAM/настроек
🔗 Активных соединений PG sudo -u postgres psql -t -c "SELECT count(*) FROM pg_stat_activity WHERE state='active';" При >150 обязателен pgBouncer, иначе высокое потребление RAM на процессы}\,,
🐢 Медленные запросы grep -c "duration.*ms" /var/log/postgresql/postgresql-*.log 2>/dev/null | tail -1 требуют индексов, оптимизации запросов
🌐 Сетевые ошибки ip -s link | grep -A 4 "eth\|ens" | grep errors должны быть 0
🔄 Процессы в swap top -b -n 1 | grep -E "postgres|1c" | grep " S " не должно быть – признак острой нехватки RAM
⚙️ Подбор сервера на планируемую нагрузку
💡 Расширенные рекомендации (Linux + PostgreSQL)
• pgBouncer: При 50+ пользователях обязательно используйте pgBouncer в режиме transaction pooling. PostgreSQL создаёт отдельный процесс на каждое соединение (~5–10 МБ RAM), без пулера при 200 соединениях СУБД теряет до 20% производительности на управлении процессами.
• Антивирус: Добавьте каталог данных PostgreSQL ($PGDATA) и рабочие каталоги 1С в исключения. Сканирование WAL-файлов в реальном времени убивает производительность.
• RAM-диск для временных файлов: Смонтируйте pg_stat_temp в tmpfs: mount -t tmpfs -o size=256m tmpfs /var/lib/postgresql/data/pg_stat_tmp.
• huge_pages: Включите transparent huge pages для PostgreSQL: echo always > /sys/kernel/mm/transparent_hugepage/enabled.
• NUMA (многопроцессорные системы): На серверах с двумя и более сокетами CPU используйте numactl --interleave=all для PostgreSQL и для сервера 1С, чтобы избежать межсокетных задержек. Проверьте numactl --hardware.
• Регламентные задания: VACUUM, ANALYZE, резервное копирование – только в нерабочее время.
• Дисковая подсистема сервера приложений: Для сервера 1С достаточно любого SSD (SATA SSD) объёмом от 100 ГБ. Высокая нагрузка на диск на этом узле не является узким местом (основные операции ввода-вывода приходятся на СУБД). RAID 1 – для отказоустойчивости.
• Разделение серверов: При 30+ активных пользователях разделите сервер 1С и PostgreSQL. При 80+ рассмотрите кластер серверов 1С (2+ узла).
• Кластер PostgreSQL: Для высокой доступности – Patroni + etcd (минимум 3 узла для кворума).