1C:ERP & Postgres Pro Tuning for 300+ Concurrent Enterprise Users

When a production 1C:ERP database surpasses 500 GB and concurrent user sessions exceed three hundred, default configurations of PostgreSQL and application server clusters inevitably hit lock contention bottlenecks. Document posting stalls for minutes, scheduled background jobs exhaust I/O channels, and application logs fill with transaction timeouts (TTIMEOUT) and deadlocks (TDEADLOCK).

The standard reflex in such scenarios is requesting expensive capital expenditures for beefier servers. In this case study, the Noxet team details how structured technological log analysis, Linux memory subsystem tuning, and granular Postgres Pro Enterprise configuration accelerated document posting by 15x on the client’s existing hardware.

Baseline Environment & Infrastructure Profile

• ERP Workload: 1C:Enterprise ERP (customized accounting and inventory allocation schemas).
• Database: 560 GB on Postgres Pro 14 Standard running on enterprise Linux (RED OS 7.3).
• Workforce: 320 concurrent users (thick and thin client sessions via a centralized RDS farm).
• Critical Issues: Order processing delays peaking at 120–180 seconds during operational rush hours (11:00–14:00), accompanied by recurring “Lock request timeout exceeded” errors.

1. Root Cause Identification via 1C Technological Log (TJ)

Rather than guessing at parameter values, we isolated systemic bottlenecks using targeted 1C technological log filters (logcfg.xml):

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="/var/log/1c/techlog/locks" history="72">
    <event>
      <eq property="name" value="TLOCKS"/>
      <ge property="duration" value="3000000"/> <!-- >= 3 seconds -->
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
  <log location="/var/log/1c/techlog/db" history="24">
    <event>
      <eq property="name" value="DBPOSTGRS"/>
      <ge property="duration" value="5000000"/> <!-- Queries exceeding 5 seconds -->
    </event>
    <property name="all"/>
  </log>
</config>

Telemetry Findings:

1. CPU Was Not the Bottleneck: Server CPU utilization remained below 45%.
2. Disk I/O Wait Spikes: Sudden await surges up to 40 ms occurred whenever Linux flushed accumulated dirty memory buffers (dirty pages) via background kernel flusher threads.
3. Lock Escalation on Inventory Registers: Over 80% of transaction timeouts clustered on the inventory accumulation register due to unindexed balance recalculations within broad transaction scopes.

2. Linux Kernel & Memory Subsystem Tuning

Default Linux virtual memory management heuristics are ill-suited for high-load relational databases paired with 1C application tiers:

# /etc/sysctl.d/99-postgresql.conf

# Prevent swapping out active PostgreSQL cache pages when physical RAM is available
vm.swappiness = 1

# Prevent accumulation of massive dirty memory write queues
# Background disk flushing triggers at 5% dirty ratio and becomes synchronous at 10%
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

# Safe memory overcommit strategy
vm.overcommit_memory = 2
vm.overcommit_ratio = 80

# Disable Transparent HugePages (THP) to avoid memory defragmentation latency
# echo never > /sys/kernel/mm/transparent_hugepage/enabled

3. Postgres Pro Tuning for 1C:Enterprise Specifics

1C workloads generate millions of transient transactions, nested sub-queries, and temporary table allocations. We reconfigured postgresql.conf for the node (128 GB RAM, 32 CPU cores, Enterprise NVMe array):

# postgresql.conf

# Memory Allocation
shared_buffers = 32GB                  # 25% of total physical RAM
effective_cache_size = 96GB            # 75% total RAM
work_mem = 64MB                        # Dedicated ceiling for sorting and hash joins
maintenance_work_mem = 4GB             # Accelerate vacuuming and B-tree index rebuilds
temp_buffers = 32MB                    # 1C temp table workspace

# Planner & NVMe Storage Alignment
random_page_cost = 1.1                 # Reflects high random NVMe read performance
effective_io_concurrency = 200
seq_page_cost = 1.0

# 1C:Enterprise Protocol Parameters
max_locks_per_transaction = 256        # 1C holds massive transaction lock sets
standard_conforming_strings = off
escape_string_warning = off
row_security = off

# Aggressive Autovacuum Mechanics
autovacuum = on
autovacuum_max_workers = 6
autovacuum_naptime = 15s               # High-frequency table change audits
autovacuum_vacuum_scale_factor = 0.05  # Trigger vacuum at 5% row churn
autovacuum_analyze_scale_factor = 0.02 # Refresh statistics at 2% table variance
autovacuum_vacuum_cost_limit = 2000    # Unshackle vacuum I/O throughput

# 1C Query Optimizers (Postgres Pro Enterprise)
plantuner.fix_empty_table = on         # Fix query plans on empty temp tables
online_analyze.enable = on
online_analyze.table_type = 'all'

4. 1C Server Cluster Re-Architecture

To prevent resource starvation between interactive users and asynchronous background processing, we re-architected the 1C server cluster roles:

1. Background Job Segregation: A dedicated worker instance was provisioned within the 1C administration cluster exclusively flagged for Scheduled & Background Tasks. Heavy monthly closing calculations were completely isolated from the front-office interactive user pool.
2. Worker Process (rphost) Quotas:
   • InfoBase per process: restricted to 1.
   • Maximum connections per rphost: set to 25.
   • Process memory threshold: 4096 MB (guards against memory leaks from rogue client-side report generation).
   • Scheduled rolling restart: 86400 s (daily off-hours restart cycle to eliminate memory fragmentation).

5. Measured Optimization Results

Bottom Line Impact:

The client avoided over $45,000 in scheduled hardware procurement expenditures while securing two years of headroom for projected transaction growth.

Experiencing locking issues, slow reports, or planning a migration from MS SQL to PostgreSQL? Schedule an infrastructure audit with Noxet.