March 2026. A 64-slice CT scanner went live at a secondary A-level hospital in Shaoguan, Guangdong. The equipment department was pleased with the purchase. Radiology was not. The scanner could handle more than 200 exams a day, but when a radiologist opened an older study, the images took seven or eight seconds to appear; with five readers working at once, some studies took more than fifteen seconds. The radiology director's summary was direct: "Before, we looked at the images and then wrote the report. Now we can only write the report first and wait for the images to arrive."
The scanner was not the problem. The PACS server bought in 2018 was, and it was still carrying 2026 imaging volumes on mechanical disks.
On site: three numbers
| Measure | Before | Note |
|---|---|---|
| Daily exams | 90 to 210 | CT about 60 percent, 120-180 MB per exam |
| Opening one older study | 1.8 s to 8.4 s | Over 15 s with five workstations reading at once |
| New image volume | About 5.5 TB a year | Based on 300 working days, about 19 GB a day |
The IT team had already tried. It replaced the switch with a 10 GbE model and added more RAM to the server. Neither moved the numbers much. That pointed away from bandwidth and toward disk queues.
Diagnosis: three problems stacked
We tested the server, the storage and the network separately. The results agreed:
- Random reads outran the disks. Eight 4 TB 7.2K SATA drives in RAID 5, each capable of roughly 75 random IOPS, gave the array about 500-700 read IOPS. PACS retrieval is random read by nature. Once the queue gets deep, latency climbs.
- RAID 5 write penalty. Every write reads the old data, computes parity and writes it back, so write amplification is real. With images written during the day and archived at night, the array rarely sat idle.
- Application, database and image files on one machine. SQL Server and the PACS service competed for the same disks, and whichever was busy slowed the other down. With 64 GB of RAM against 5.5 TB of hot data, the cache hit rate was low.
A common misreading: slow retrieval does not mean a slow network. Gigabit Ethernet moves about 110 MB/s, so a 150 MB CT series should cross the wire in about 1.5 seconds. If the disk needs eight seconds to produce the data, a faster link changes nothing.
Options: three routes, and why we took the middle one
| Option | Approach | Budget | Problem |
|---|---|---|---|
| A. All-flash SAN | Centralized all-flash array with dual controllers | From 280,000 RMB | More performance than the workload needed; the budget would not clear |
| B. Two servers, SSD hot tier, 10 GbE | Split application and database; hot images on SSD RAID 10; cold images stay on the old server | About 150,000 RMB | Requires data tiering; a little more complex to implement |
| C. More RAM and 10 GbE only | Keep the old server | 10,000-20,000 RMB | Treats the symptom; the queue returns within six months |
We chose B. The principle is to separate online, near-line and offline data: the most recent 12 months of images sit on flash so retrieval stays fast, older studies stay on the old server's mechanical disks as a near-line archive, and backups live on a NAS that does not compete with production for disks.
Configuration
| Equipment | Specification | Qty | Role |
|---|---|---|---|
| PACS application server | 2x Xeon Silver 4314 (16C/32T), 128 GB DDR4 ECC, 2x480 GB SSD RAID 1, dual 10 GbE, 800 W redundant | 1 | PACS service, image retrieval |
| Database server | Same platform plus 4x3.84 TB enterprise SSD in RAID 10 (about 7.6 TB usable) | 1 | SQL Server, indexes, hot data |
| Near-line archive | Existing R730, 8x4 TB RAID 5 retained | 1 | Images older than 12 months |
| Backup | 24 TB NAS, RAID 6, separate from the production network | 1 | Daily incremental, weekly full |
| Network | Two 10 GbE modules in the core switch, Cat6A patch leads in radiology | 2 modules | 10 GbE from servers to core; workstations stay at 1 GbE |
Rollout: one weekend and two nights
A hospital cannot close for a storage swap. We split the work into four windows:
- Friday, 20:00-23:00. Back up the PACS database and configuration, and record the rollback point on the old server.
- Saturday, 08:00-18:00. Rack the new servers, install the operating system and PACS, and commission the 10 GbE links. In the afternoon, migrate 5.2 TB of hot data at 400 MB/s, about 3.6 hours.
- Sunday. Concurrency test with 30 simulated clients, RAID degradation test, backup restore drill.
- Monday, 07:30. Cut over before the outpatient clinic opens, and keep the old server for 30 days without wiping it.
Results
Retrieval fell from 8.4 seconds to 2.1. Five concurrent readers went from more than 15 seconds to 3.1 seconds. The less visible change matters as much: radiology no longer writes reports ahead of the images, and the outpatient peak no longer backs up behind a retrieval queue.
The bill: where 153,000 RMB went
| Item | Amount |
|---|---|
| Two 2U servers (128 GB RAM, dual 10 GbE) | 92,000 RMB |
| Four 3.84 TB enterprise SSDs | 26,000 RMB |
| 24 TB backup NAS | 14,000 RMB |
| 10 GbE modules and cabling | 9,000 RMB |
| Implementation, migration, load testing | 12,000 RMB |
| Total | 153,000 RMB |
Five lessons
- Tier the data before buying hardware. Putting every image on the most expensive storage is the most common waste in projects like this.
- RAID 5 is wrong for hot data. Read performance is ordinary and the write penalty is real. Use RAID 10 for hot data and trade capacity for IOPS.
- Two servers are not a backup. Clustering covers a failed machine; backup covers corrupted data. They are separate jobs and need separate budgets.
- 10 GbE to the department, not to every desk. Retrieval bottlenecks usually sit in storage, not in the desktop network port.
- Rehearse the rollback before migrating. Thirty days of untouched old server is worth more than any promise.
Note: At the client's request, the organization name, departments and some dates in this article have been blurred; configurations and prices reflect the market in October 2026, and actual projects depend on a site survey.