“Posting a document takes a minute, a quarterly report takes half an hour, and by evening everything freezes.” That’s the most common request we get from accounting departments. The good news: nine times out of ten, the cause isn’t 1C itself, and it can be fixed without replacing the software. Let’s go through the causes in order — from the most common to the rare ones.
1. A file-mode database instead of SQL
The file-mode version of 1C stores the entire database in a single file on a shared folder. With two or three users and a database under 2–3 GB, that works. Beyond that, locking begins: “file is in use by another user,” waiting, errors. Every user pulls whole chunks of the database across the network.
Solution: move to the client-server version with MS SQL Server or PostgreSQL. This delivers the biggest gain of all — typically 3–5x. It requires a 1C server and a database server (they can run on the same machine) plus a 1C server license.
2. A hard drive instead of an SSD
1C, and especially the database engine, make thousands of small disk requests per second. A conventional hard drive handles 100–200 such operations; an SSD handles tens of thousands. If the database sits on an HDD (or an HDD RAID array), no processor will help.
Solution: move the database and temporary files to an SSD, preferably NVMe. The cost starts at a few hundred thousand UZS; the effect is 2–3x.
3. Not enough memory on the server
The database engine keeps frequently used data in RAM. If there isn’t enough, data is read from disk every time. The telltale sign: all memory on the server is in use and the disk is constantly busy.
Solution: a 10 GB database needs at least 16 GB of RAM on the server; a 50 GB database needs 32–64 GB. Plus proper configuration: by default, SQL Server grabs all available memory and starves the 1C server itself.
4. The 1C server and database left at “out-of-the-box” settings
Default settings are designed for an “average” workload. 1C needs separate disks for data and the transaction log, a properly sized temp database, a cap on SQL memory, and regular statistics updates and index rebuilds.
Solution: scheduled database maintenance jobs (overnight) and settings tuned to the database size. A one-time task of 2–4 hours; the effect lasts as long as the jobs keep running.
5. The network
A 100-megabit switch, Wi-Fi instead of cable, a low-end router between the server and users. Client-server 1C tolerates the network better than file mode, but a thin client over Wi-Fi through an overloaded access point will always be slow.
Solution: gigabit networking to every workstation that uses 1C, with the server on a dedicated port. Or a terminal server, so only the screen image travels over the network.
6. Antivirus scanning the database
Antivirus on the server scans every access to the database files — and there are thousands per second. A classic mistake after “tightening security.”
Solution: exclude the database data folders, 1C temporary files and 1C server processes from scanning. Security doesn’t suffer — these files aren’t executable.
7. Configuration and data
A report written “however it turned out” that loops through every document for the past three years; thousands of objects marked for deletion; totals that haven’t been recalculated in years. Here, the infrastructure isn’t to blame.
Solution: this is work for a 1C developer: analyzing slow queries through the technology log, optimizing reports, collapsing the database. We give them the data from the server — exactly what is slow and when.
Where to start
Not by buying a new server. Start by measuring: a performance assessment (APDEX), disk, memory and CPU load on the server during business hours, and analysis of database wait times. One hour of diagnostics usually reveals two or three causes from the list above and the order in which to fix them. We run these diagnostics as part of our 1C server and database management service — with a written report of what was found and why.