Server for 1C: how to choose CPU, memory and disks without overpaying

Where to start: what will the server do

Buying a server doesn’t start with the model or the number of cores, but with the roles it will perform. The same server for 1C can be a workhorse for data entry, or it can simultaneously run the database, exchanges, reports and integrations. In the latter case, storage and memory requirements are often more important than just “more CPU”.

What usually runs alongside 1C

Besides 1C itself there is almost always a DBMS (commonly MS SQL Server or PostgreSQL), background jobs, exchanges with a website or other systems, printing, mail, integrations with banks and EDI, and heavy reports. If all of this lives on one server, the load adds up and a bottleneck can appear unexpectedly.

The same number of users does not mean the same load. Twenty accountants entering documents all day create one picture. But 20 users where half constantly run year‑end reports across all warehouses, and a couple of people trigger exchanges every 5 minutes, can easily overload an otherwise powerful server.

What usually slows things down

In practice the disk subsystem is most often the limiting factor (many small operations and waits), then memory (cache eviction and active use of swap), and only then CPU. Network becomes a problem when the database and users are in different locations or when backups and exchanges run during business hours.

Before choosing hardware collect a short set of data:

• how many concurrent users and what roles they have (accounting, warehouse, sales, managers)
• current database size and growth forecast for 1–2 years
• which operations are the heaviest (reports, period closing, exchanges, bulk uploads)
• where the DBMS will run (on the same server or separately)
• availability requirements (is redundancy and fast recovery needed)

These answers will immediately show where not to skimp and where you definitely shouldn’t overpay for cores that will sit idle.

Typical load profiles for 1C, ERP and databases

A server behaves differently depending on what people do in the system. It helps to understand in advance which load profile is primary for you: “many users online”, “monthly peak”, “heavy reports” or “integrations 24/7”.

1) Daily online work

This is concurrent user activity: entering and posting documents, printing, small queries. Fast response for short operations and no lag at peak times are important. Most often the limiting factors are single‑core CPU performance and disk latency (especially with active writes).

2) Scheduled jobs and period closing

At night or month‑end recalculations, period closing, reprocessing and exchanges run. The load becomes long and heavy, sometimes parallelizable but not always. A common mistake is buying many cores “just in case” when the real limit may be a few threads or disk speed.

3) Heavy reports and ad‑hoc queries

When an accountant or analyst builds a complex report, the database reads and sorts lots of data. Usually the most important things are:

• enough RAM for cache (to read from disk less frequently)
• fast SSDs (often NVMe) for temporary operations
• clear rules on who and when runs the heaviest reports

4) Integrations, terminal access and virtualization

Integrations with ERP/CRM, EDI, APIs and file exchanges produce steady background load and constant writes. Terminal access or virtualization adds neighbors for CPU and memory.

A typical scenario: during the day 40 users press buttons, and in the evening month‑end processing starts while exchanges run. In that case it’s wiser to invest in memory and fast disks and schedule a window for heavy jobs, rather than overpay for cores that are idle during the day.

Data to collect before purchase

Before choosing a server for 1C, gather facts about the load. Without them it’s easy to buy extra cores and still hit slow disks or insufficient memory.

Start with users. It’s important not how many people are on the payroll, but how many work simultaneously in the busiest hours. One person closing the month and running heavy reports can generate load equivalent to several “quiet” users.

Then assess the database: current size, how much the database and log files take, and how fast it grows. Plan a 1–3 year horizon to avoid replacing the server too soon. If growth comes in jumps (after a website integration, scanned archive import, etc.), note that too.

Record peaks: month‑end, Monday morning, seasonal sales, bulk uploads. Separately note what exactly happens at the peak: posting documents, payroll calculation, period closing, scheduled jobs, exchanges.

Minimum information to give a supplier:

• number of concurrent users in normal and peak periods
• database size and annual growth
• the 3–5 slowest operations “by feeling” and when they occur
• which DBMS and where the database will live (locally on the server, on separate storage, in a VM)
• whether background jobs, exchanges, backups run during business hours

Example: an office has 60 employees but 18–25 work in 1C concurrently, and posting and reports slow down at month end. In such a case fast disks and sufficient RAM are often more important than the maximum number of cores.

CPU: clock speed vs core count

For 1C and SQL tasks single‑core speed is often more important than core count. Many operations run sequentially: posting documents, parts of queries, locks and application logic. If a core is slow, the system will feel sluggish even with a CPU that has many cores.

Extra cores are also needed, but for obvious reasons: many simultaneous users, multiple people running heavy reports, active background jobs, or several databases on one server.

A simple way to see if you’re overpaying for cores is to look at peak CPU usage during work hours. If in heavy moments usage rarely rises above 30–40% and users complain about speed, the cause is usually disks, memory, single‑core performance or setup. Conversely, if usage stays at 80–90% and task queues grow, you really need more cores.

Decide in advance where roles will run. Running 1C application, the database server and a terminal server together is best avoided unless necessary: each role consumes CPU differently and can interfere with others.

To avoid mistakes with CPU headroom:

• leave about 20–30% free capacity in a typical peak
• account for seasonal loads (month‑end, quarter‑end)
• include headroom if new databases, integrations or reports are planned
• check disks and memory before buying more cores

Memory: how much and what matters besides size

RAM shortage often looks like “slow disks.” The system begins to swap, and 1C and the DBMS experience read/write delays. You might buy fast SSDs and see no improvement because memory is the bottleneck.

Rule of thumb: the more data fits in RAM, the less the server needs to access disk. For 1C and ERP memory is used by 1C worker processes, DBMS cache, background jobs (exchanges, scheduled tasks), plus the OS and antivirus.

Practical size guidelines:

• 64 GB is often enough for a small office: up to a few dozen users and a moderate database without heavy full‑period reports.
• 128 GB is usually needed if there are many users, a fast‑growing DB, and near‑continuous scheduled tasks and exchanges.
• 256 GB and above is justified when the database is large, a big DB cache is important, there are multiple information bases, or analytics and integrations run in parallel.

It’s not only “how much” but “how” it’s installed. Modern platforms benefit from multi‑channel memory, so install identical modules and populate channels symmetrically. Mixed sizes and frequencies can reduce speed for no obvious reason.

Plan for growth. A good rule for 1C is to keep 20–30% of RAM free during a normal workday.

Example: with 40 users and a 150–200 GB database, 64 GB may be tight. As the DB grows and reports get heavier, swapping begins. Moving to 128 GB often gives more benefit than upgrading disks to a higher tier.

Disks and storage: avoid hitting IOPS limits

For 1C, ERP and databases the bottleneck is often the storage subsystem. Look not at “up to 7000 MB/s” on the spec sheet but at latency and stable IOPS under mixed load. If latency spikes, users will see long postings, frozen forms and slow reports even if CPU is mostly idle.

A minimal working scheme is to separate storage roles so operations don’t interfere with each other. Often it looks like this:

• OS and system files on a separate volume
• database files on a fast volume
• logs on a separate fast volume
• backups on a separate disk or array where capacity matters more than IOPS

Choosing between SATA SSD and NVMe is simple in principle: SATA SSDs are suitable for moderate load and when cost per gigabyte matters; NVMe is needed when many concurrent operations and minimal latency are critical. It’s common to mix: keep DB and logs on NVMe, and OS and backups on SATA SSDs or HDDs (if backup windows allow).

RAID matters not only for resilience but also for predictable performance. RAID 1 covers basic disk failure risk. RAID 10 is often chosen when you need both reliability and high write performance, especially for active databases and logs.

Don’t forget the controller: cache and proper configuration help maintain steady performance, and cache protection reduces the risk of data loss on power failure.

Network, redundancy and scaling without rework

If the 1C server and database are in a datacenter and users connect over the network, latency often becomes the bottleneck. For 1C short and stable latency is important: even small spikes are experienced as lag.

10GbE isn’t always necessary. It’s justified when the database is large, many users are concurrent, there is active exchange with other systems, backups go over the network, or network storage is used. If server and disks are local and the office has up to 30–40 users without heavy integrations, 1GbE is often sufficient, but plan ports and upgrade options.

Start redundancy planning by answering how much downtime you can tolerate and how fast you must recover. Backup is not only “make a copy” but also having several recovery points and regularly testing restore procedures.

Check in advance:

• where copies are written (separate disk, separate server, network repository)
• retention policy and scheme
• how long full and incremental backups take
• how often you test recovery on a separate instance

Sometimes two nodes are better than one big one: separate servers for SQL and 1C (or for terminals) are easier to scale and update sequentially.

Plan growth from the start: free memory slots, spare disk capacity and ability to add a second NIC.

Architecture options: one server or split roles

The first decision is to put all roles on one server or separate them. For a small office one server is often enough: application, database and files together. It’s simpler to manage and cheaper initially.

But as users and DB grow, role co‑location starts to cause conflict: disks and memory compete, and any reboot affects all services. If 1C and DB are critical, separation usually wins: one server for the DBMS and another for terminals/application. That way you can give the database fast disks and enough RAM, and give the application high CPU clock speed. Updates and reboots can be done in sequence.

One server with virtualization or multiple physical machines

Virtualization is convenient when you need multiple roles but don’t want separate physical machines. Pros: flexibility — resources can be reallocated, and snapshots and migrations are easier. Cons: you need spare resources and careful tuning, otherwise noisy neighbors will slow others down.

Minimum rules:

• keep 20–30% spare CPU and memory
• give the DB priority for disks (prefer separate pool or volume)
• decide in advance how backups are done and where they’re stored
• check 1C, Windows and DBMS license limits for virtual environments

Form factor, reliability and hidden constraints

Choose form factor for practical reasons. A rackmount is convenient in a server room and for scaling. A tower is fine when there’s no rack and noise matters. Compact servers save space but are more demanding on cooling.

Build reliability from the start: dual power supplies, hot‑swap disks, clear fan schemes. Don’t forget practical constraints: available power, room cooling capacity, and whether the server noise will disturb people.

Common mistakes when choosing a server for 1C and DB

The most expensive mistake is buying the “most powerful” CPU and later discovering the system is slow because of disks. For 1C and many ERPs IO latency matters more than extra cores. If the DB is on slow storage, increasing CPU frequency won’t help.

The second typical problem is skimping on memory. When RAM is insufficient the server swaps. This sharply degrades responsiveness and creates the illusion that “the CPU can’t cope,” while the real cause is memory.

Another frequent mistake is putting everything on one array: OS, database, logs, temp files and backups. As a result operations compete for the same IOPS and everything slows at peak times. Spreading roles across disks or at least separate volumes often gives more benefit than a CPU upgrade.

And a painful one — backups “for the record.” A backup that isn’t tested for recovery won’t save you, especially if copies are written to the same array as the working database.

Quick self‑check before purchase:

• measured disk load (IOPS and latencies), not just CPU usage
• calculated RAM headroom for DB and users to avoid swap
• separated database, logs and backups so they don’t interfere
• performed a test restore and recorded actual downtime
• planned growth for 6–12 months (what will be added and how)

Short checklist before ordering hardware

Before ordering a server, document requirements. This helps avoid overpaying for unused resources and hitting a bottleneck in a few months.

Check the specification across five points:

• CPU and real load. For 1C and many ERPs high clock speed and fast cores matter more than sheer core count. Leave headroom for peaks, not a large safety margin “just in case.”
• Memory and growth for 1–3 years. Estimate current data volume and how much RAM DB and cache already use. Include reserve for DB growth, new reports and integrations.
• Disks and volume layout. Separate DB data and logs across different volumes, pick RAID for your load and verify storage provides stable IOPS and low latency.
• Network and latency. Clarify where users and terminal servers are and what latency exists between them and the server. Sometimes network tuning yields improvements faster than a CPU upgrade.
• Reliability and recovery. Dual power supplies, monitoring, clear backup plan and regular restore verification.

Example: configuration for a medium office

Scenario: 60 users work in 1C and ERP in a single database. Days are steady but month‑end brings peaks from period closing, reports and reprocessing. The goal is to handle peaks without overspending on resources that sit idle most of the time.

Collect metrics for at least a week (including a busy day). Look at peaks, not only averages:

• CPU load per core and frequency (important to see if you’re limited by 1–2 threads)
• RAM usage and whether swapping occurs
• disk queue and read/write latencies
• execution time for typical 1C operations
• DB size, growth rate, log and temp file volumes

A balanced configuration often looks like: a CPU with emphasis on high clock and moderate core count (often 8–12 fast cores are more useful than 24 slower ones), 128 GB RAM and fast disks. Allocate NVMe SSD for the database and put logs on a separate volume so writes don’t block reads. Use a separate array or cheaper disks for backups and archives.

How to know the configuration isn’t excessive: CPU does not stay pegged at the ceiling in peaks, there’s no persistent disk queue, and RAM isn’t exhausted or swapping. If CPU is low but the system is slow, disks, DB locks or role co‑location are usually to blame.

Upgrade order when load grows: first fix storage, then add RAM, and only then consider CPU. When users grow significantly, splitting roles (DB separate, terminals separate) almost always simplifies life.

Next steps: agreeing configuration and budget

Purchasing often breaks down on expectations, not hardware. First document requirements in a short brief: which roles will run (1C, SQL, terminals, file services), expected user and DB growth over 1–2 years, when backups can run and how critical downtime is.

Agree early on constraints. For example: “no more than 2 hours downtime per year” and “3‑hour nightly backup window.” These two statements directly affect storage, redundancy and support.

Then request 2–3 configurations with clear explanations of what you pay for. Compare not only purchase price but total cost of ownership: growth headroom, power consumption, maintenance and support.

To keep the discussion productive:

• confirm the bottleneck (CPU, memory or disks) and what you’re improving
• choose a base option and a “plus/minus” option with clear tradeoffs
• decide how monitoring and support will be organized
• check lead times, service and spare parts availability in your region
• document a growth plan: what to add in a year (RAM, disks, second server) and how to do it without downtime

If you’re in Kazakhstan and local supply and service matter, discuss configuration with a manufacturer and integrator that handles both hardware and implementation. For example, GSE.kz manufactures servers and provides system integration, so you can assemble a solution for your load profile and plan support and expansion in advance.