I am new to Linux and our client decided to use SQL Server on Linux. As soon as we started testing, we ran into performance issues.
The server in question is a physical machine configured with a SSD local disk and a "natively" attached Storage. I don't know what a quoted "natively" actually mean here. Linux guy's exact words below
the storage is "natively" attached to the server
The storage area network is also built on top of SSD and I copied a 4.7 GB backup file from there over to local SSD within a second.
cp \gsfs\sql\backups\testdb01.bak \tmp\backups\testdb01.bak
But when I try to restore from
RESTORE DATABASE successfully processed 612466 pages in 369.425 seconds (12.952 MB/sec).
- Local Disk
RESTORE DATABASE successfully processed 612466 pages in 26.248 seconds (182.295 MB/sec).
The database files are also stored on the SAN and while SAN to physical machine has no connectivity issues, I am certain, the way MS SQL reads the files on the SAN has something to do with the slowness.
The database size is not big enough and the database is usually idle based on wait statistics
I want to understand why SQL Server is restoring from SAN slower than local file system. I would understand if the difference was little, but currently, the difference is dramatic. Since our data files and log files are also on SAN, we need to ensure disk is read/written on as fast as possible.
- Most of settings are set as default
- network packet size is 4096
- No antivirus installed