Server for an Electronic Document Management System: RAM and Disk Headroom

Where EDMS performance problems start

The first complaints about an EDMS are nearly always the same: records open slowly, search “thinks”, attachments download with delay, and reports or exports sometimes time out. It’s easy to blame “bad internet” or an “unlucky version”, but the real cause is often simpler: the server can no longer handle the actual load.

Why does everything usually work fine at first and then the system starts to “drag”? Initially there are few documents, small indexes, and working data fits well in cache. Over time the archive grows, the number of records and links increases, access rules and approval workflows become more complex. The server begins to hit specific bottlenecks: disk latency, lack of RAM for cache, indexing queues.

Look not at nice numbers in a price list but at metrics that show where time is actually lost. The most useful are:

• p95 or p99 response times (the average often hides the issue)
• disk latency and read/write queue length
• RAM usage and presence of swap
• IOPS and storage throughput during peak hours
• background tasks (indexing, backups, scheduled reports) and when they run

It's important to separate user-generated load from the system’s “invisible” load. Users create peaks: mass approvals in the morning, searches before meetings, uploading attachments at day end. Indexing and recomputing service data produce a steadier but heavy background load. It can occupy disks and memory at night and, as the archive grows, start to affect working hours.

In practice it often looks like this: CPU still appears “free”, but disks can’t keep up with simultaneous searches, opening records and writing new documents. As a result the EDMS slows in bursts.

What input data to collect before sizing

Accurate sizing starts not with choosing a server, but with numbers. If you base things on “we have about 500 users”, you almost always get it wrong: CPU and RAM with headroom, but insufficient disks; or plenty of space but slow search.

First clarify the difference between total accounts and real concurrent load. For EDMS the key is not “how many people in the company” but how many work concurrently during peak hours (for example, mornings and before deadlines). Also understand the share of “heavy” roles: secretariat, archive, accounting, legal. They usually perform more operations and handle more attachments.

Next, collect document data. Important are not only files but attachments: scans, PDFs, spreadsheets, correspondence. Determine how many documents are created and uploaded per year and the average attachment size. If average size is unknown, sample the last 200–500 documents by type and calculate the mean and 90th percentile. The heavy tail often determines disk growth.

Minimum items to record:

• peak concurrent sessions and typical user actions
• annual growth of documents and attachments, including size distribution
• retention periods and rules: what is deleted, archived, stored for 5–10 years
• which operations must be fast: search, approvals, bulk uploads/exports
• availability requirements: is maintenance downtime acceptable and what is the maximum allowed outage

Agree separately on archiving. If documents are kept 10 years, plan disks for the full cycle considering annual growth. Also decide whether the archive needs full-text indexing or only fast document retrieval without indexing old content.

Finally, agree on availability. If downtime is unacceptable (government body, bank, large clinic), sizing changes: you need redundancy, space for backups and a clear failover plan. This affects the final choice when selecting a server for an EDMS, not just “a more powerful machine”.

Memory: how to estimate RAM needs and where to include headroom

RAM in EDMS is used not only by the application itself. Several layers consume memory: the OS, the database, the application (user sessions, task queues, cache), and search/indexing (index caches, service processes). That is why “everything is fast while users are few” quickly turns into slowdowns as the database and index grow.

When RAM is insufficient, performance drops beyond just speed. The system hits disks more often, latency increases, background tasks accumulate in queues. Timeouts, application errors and long service restarts appear during peaks. In EDMS this is especially noticeable during bulk uploads, approval waves and morning logins.

A practical approach to estimate RAM for EDMS is to break down consumption by roles and include growth:

• OS and system services: typically 4–8 GB (often more on Windows Server)
• DBMS: the main consumer (data cache and query plan cache)
• EDMS application: sessions, cache, background processors, file conversions
• search and indexer: memory for indexes and caches, which grows with documents and indexed fields

RAM headroom is needed not “just in case” but so caches work stably and aren’t flushed every few minutes. For production it’s useful to keep a noticeable portion of free memory (often 20–30%) and review sizing before average RAM usage nears 80–90%.

Example: today 200 users and 2 million documents; in a year you plan 400 users and 4–5 million documents. Even if concurrent users remain moderate, the database and index will nearly double. So DB and search memory needs will grow too. Count document growth separately from user growth.

Vertical scaling (adding RAM and CPU) makes sense when you have a single server and need to relieve DB or search cache pressure quickly. Split roles when load becomes mixed: the DB consumes most memory, the indexer needs its share, and the application lacks stability. Then separate nodes for DB and search give more predictable behavior.

Disks: what grows in EDMS besides the documents themselves

When selecting a server for an EDMS, people often count only the files folder. But several other data layers grow and unexpectedly consume free space.

First and most obvious: documents and attachments. Important are not only counts but average sizes. If staff switch from lightweight PDFs to high-quality scans or begin attaching photos and videos, average size can rise 2–3× even if document counts stay similar.

Second layer: the database. It stores records, workflows, permissions, statuses, metadata, plus logs and temp files. Logs and temp can spike: bulk uploads, period closings, reports, updates.

Third layer: search indexes. If OCR is enabled and full text is indexed, the index can be comparable in size to the documents, especially with many scans.

Fourth layer: backups. You need space not “sometime” but continuously: full backups, a chain of incremental copies, sometimes a test restore. If backups sit on the same storage, plan for even more headroom.

To avoid write errors and slowdowns, size volumes so working partitions don’t exceed 70–80% fill. Check that you accounted for:

• document and attachment growth using realistic averages and heavy-tail sizes
• separate space for DB: data files, logs, temp files
• disk headroom for archives and indexes, including reindexing
• backup storage according to your retention policy
• a constant free buffer (usually 20–30%)

If you separate these zones across different disks or arrays, it’s easier to control growth and avoid the situation “there is free space, but a critical partition is full”.

Drive types and RAID: how not to make a mistake

Even a server sized perfectly by capacity can be slow if the disk subsystem is chosen purely by terabytes. For EDMS small I/O matters more: how many IOPS the disks handle and what their latency is. That directly affects opening records, saving attachments and fast search.

SSD and HDD should be assigned by task. Put SSD where there are many random reads/writes: database, logs, temp files, search indexes. HDDs work well where load is more sequential and cost per terabyte matters: long-term archive, rarely opened attachments, cold copies.

Practical layout:

• OS and system roles — a separate small SSD array
• EDMS database — SSDs prioritizing low latency
• search indexes — a separate SSD or SSD array so indexing doesn’t impact the DB
• attachments and archive — HDD array (or SSD if old documents are frequently accessed)
• backups — separate storage, not on the same array as working data

RAID is needed not only for reliability but for predictable behavior on drive failure:

• RAID 1 — mirroring, simple for small volumes
• RAID 10 — often the best choice for DB and indexes, but requires more disks
• RAID 5/6 — more space-efficient, suitable for files and archives, but worse under heavy writes

Pay attention to indexing scenarios. During bulk uploads or index rebuilds disk load spikes. If indexes share an array with the DB or attachments, the whole stack will suffer.

Indexing and search: size and load need a separate calculation

Indexing makes search fast: the system builds an index over document text, metadata and attachments. The problem is indexing often runs in bursts and creates load peaks even when users are quiet.

Peaks usually occur in two cases: bulk uploads (scan archives, migrations, email imports) and index rebuilds after updates. At those times the server can appear “overloaded” while normal operation had no complaints.

Scheduled indexing (nightly or weekends) is convenient but requires headroom specifically for that window. Background indexing spreads load over time but continuously consumes disk, RAM and CPU and can make search less stable during business hours.

To estimate index growth, look beyond file counts to content:

• average document size and share of “heavy” formats (scans, complex PDFs)
• percent of documents with OCR
• how many fields are indexed and whether full-text search is enabled
• number of versions and attachments per document
• documents added per day and how many are edited (which triggers reindexing)

Practical rule: keep index space separate from document archive and reserve room for reindexing after updates and migrations.

Indexing usually hits: disk (many small reads/writes), RAM (caches and buffers), CPU (parsing, OCR, text processing). If disk is slow, indexing stretches and interferes with everything. If RAM is low, swapping begins and search slows drastically. If CPU is weak, indexing becomes slower, noticeable on large volumes and with OCR.

Step-by-step calculation of memory and disk headroom

To avoid the server hitting resource limits in six months, account for current load and growth.

1. Determine active users. Take the average daily EDMS users and forecast 2–3 years (for example +10–20% per year or growth due to branch openings). For headroom calculate two scenarios: baseline and a “peak month” (quarter close, mass approvals).

2. Calculate document and attachment growth. Consider documents per month × average attachment size × hot archive retention (e.g., 12–18 months on fast disks).

3. Split storage into categories. Typically space is used by: database, document files, search indexes, backups. Example: 200 GB DB, 2 TB files, 300 GB indexes, plus 2–3 full backups (per your retention).

4. Choose drive types and RAID for each part. DB and indexes need low-latency SSD and fast RAID. File storage can be on higher-capacity drives if preview and search don’t rely on it directly.

Then add headroom. In practice people often add 30–50% on disks for growth and reindexing, and separate RAM headroom for caches and background tasks (usually 20–40% of the calculated value).

Set triggers for upgrades:

• less than ~20% free on the DB or index volume
• indexes growing faster than documents (a sign of reindexing or new file types)
• constant high memory usage and frequent swapping
• search and record opening times steadily rising week over week

Common mistakes when choosing a server for EDMS

The main problem is adding an unspecified “buffer” without knowing where it’s needed. The result: a new server but users still complain about slow search and record opening.

A frequent mistake is sizing by total company headcount. The important number is concurrent EDMS users during peaks. If you size by total staff you may overpay; if you size by daily average you can underestimate peaks and get queues and hangs.

Disk and storage mistakes

Many plan only for document file space and forget nearby growth: search indexes, document versions, service logs, temp files and backup space. Another typical error is keeping DB, indexes and file storage on one slow array. Then everything competes for the same disks and any heavy operation stalls the rest.

Filling disks almost to capacity is dangerous. After 80–85% filled there’s little room for indexing, updates and DB maintenance. Performance drops and risk of errors rises.

Invisible “speed eaters”

Antivirus and file scanning often check every opened or uploaded document. On paper the server is adequate, but in practice delays come from scanning. Test this in advance and configure exclusions with security teams.

Quick self-check before procurement:

• calculate peak concurrent load, not total staff
• allow space for indexes, versions, logs and backups
• separate “hot” data (DB and indexes) from file storage
• keep disk fill below 80–85% planned
• measure antivirus impact on typical operations beforehand

Quick checklist before purchase and before go-live

Before buying, verify not only “are resources enough now” but also whether there is clear headroom for user growth, indexing and peak server load.

What to record in procurement and launch plans:

• RAM: no persistent swapping in business hours and memory headroom remains even at peaks
• Disks: storage fill stays below threshold (usually 70–80%) to avoid speed drops and longer backup windows
• Backups: copies fit the chosen storage scheme and restoring at least one typical copy is tested and timed
• Indexing and search: indexing fits into the allocated window and does not consume so many resources that users wait for search and opening records
• Monitoring: choose 3–5 metrics and assign an owner. Usually enough metrics are: disk usage, free RAM, swap presence, disk latency, EDMS response time or indexing queue length

Before go-live run a short test: simulate a typical day (user logins, document uploads, search, approvals), run indexing in parallel and check metrics don’t degrade.

Example calculation for a real scenario (simple numbers)

Typical scenario: a government body or bank. Now 600 active EDMS users; in 3 years they plan 900. Document flow grows with headcount, so add headroom.

Input: 80,000 documents/month, average attachment size 1.5 MB. Keep “hot” data available for 36 months.

Storage calc: 80,000 × 1.5 MB = 120,000 MB ≈ 117 GB/month. For 36 months: 117 × 36 ≈ 4.2 TB for attachments alone.

But EDMS stores more than files. Add:

• metadata, versions, logs: +30%
• search indexes: often 10–20% of text and metadata, take +15%
• headroom for growth and peaks: at least +30%

So: 4.2 TB × (1 + 0.30 + 0.15) ≈ 6.1 TB. With an additional +30% buffer you get roughly 8 TB usable capacity. Then account for RAID overhead (for example RAID6 requires more raw disks).

Where to use SSD: EDMS DB, transaction logs and search index are usually better on SSD for stable response and fewer “hangs” during bulk operations. Attachments and archives can be on higher-capacity HDDs if old documents are rarely accessed.

Memory: if the system currently runs fine on 64 GB, plan for 128 GB with 20–30% headroom for user growth, cache and indexing. This is usually cheaper than an unexpected upgrade and downtime.

Next steps: lock the numbers and move to deployment

When RAM and disk numbers are calculated, formalize them so no one questions them later. Put inputs into a simple template: active users now and in 12–24 months, documents added per day, average attachment size, archive retention, maintenance windows. Separately agree the growth horizon with the EDMS owner and security.

Then check high-availability requirements. If downtime is unacceptable, one machine is usually not enough. Decide early whether roles will be split (application, DB, search) or clustered, and define actions for disk, node or site failure.

Keep the action plan short and verifiable:

• approve the input template and growth target
• define architecture for failover and maintenance
• plan a load test and a control reindex on a data copy
• prepare an expansion plan: add disks, increase RAM, move roles to separate servers
• assign who monitors space, memory, indexing queue and search time

A load test is most useful when it matches reality: e.g., 200 concurrent users, bulk scan uploads in the morning and reindexing in the evening. This reveals bottlenecks (memory, disks, search) before go-live.

If you need a vendor that can not only sell hardware but design configurations for real peaks and EDMS growth in Kazakhstan, local provider GSE.kz (GSE) is often considered; they offer S200 Series servers and 24/7 support.