mibuso.com

The key to using SSDs is the controller. Once you have SSDs most of the drive configuration becomes irrelevant, and you move the bottle neck from the drives to the controller. If the controller is configured incorrectly then the SSDs can be slower than normal drives, so just make sure you have someone that understands SSDs controllers and Navision.

The real advantage of SSDs is not data through put, as for the same dollars you can get more through put on physical drives. The advantages are in the simplicity, where fragmentation, spindles RAID type etc become less important and thus the system is much easier to manage.

For a small implementations like this, you could use two SSDs in RAID 1 and put everything on one drive which will make it very easy to manage. (Obviously keep the OS on a separate physical drive).

The thing with the amount of disks is that you need the place to put them. Most servers can handle 4 or 8 disks. With 16 you need extra shelves. This becomes expensive to.

So if you can have good performance with 2 SSD disks compared to 8 SAS disks you need less phisical space.

Here's some of my random thoughts/questions on SSD:

1. SSD eliminates the physical limitations of regular drives which is the driving factor behind separating different file types such as data vs. logs. This can be an advantage in smaller systems where clients balk at dedicating a pair of 146 GB SAS drives for a log file that will never see 10 GB in its life.

2. SSD is best suited for the small random I/O and to a lesser extend sequential I/O. This would likely make them a great choice for data but not so much for logs. On a small system it probably makes sense to put it all on the SSD. But does a larger system justify the SSD for logs? Would you be better to just have the log on a regular RAID 1?

3. Have you seen any issues in terms of write life with SSD? The inforamtion I've seen recommends not usign SSD on systems where >20% of I/O are writes. Most NAV systems I've seen fall under that 20% threshhold so would be valid SSD candidates.

4. MLC vs SLC vs Enterprise Class SSD. Thoughts?

5. I might lean more toward RAID 5 instead of RAID 1 for SSD. Better usable space vs. cost. Thoughts?

Hi Frank,



Are you sure that I/O on "tempdb" was caused by NAV? I often see that some BI stuff is putting such heavy load on the "tempdb" as those application create temp-tables/worktables there ... ?!



This changes if users flag the Index Rebuild with "sort in tempdb" which I do not recommend ...

All tasks related to BI are scheduled to run in the night starting at 1:00am. Customer is running the PerformTools though. So some of the traffic on TempDB could be coming from the PerformTools.

Online indexing is useful if you have a very small window for index rebuilding (you can use index defragging but it is not as good as an index rebuild, but it locks the table/index a lot less).
Online indexing is the same as offline indexing but locks the table/index a lot less (it locks at the start of a rebuild and at the end of the rebuild).


And also memory. I read a blog lately (did save the link though...) that states that you must have 2GB of memory for each 80GB of SSD space. I didn't test it out myself but I did read some other blogs that stated you SSD's use more memory than normal disks. I don't know the technical reason for it (did find any info on this).



The older SSD's had problems with it (Q:How do I know this if I have no experience with SSD's? A:I follow a lot of blogs about SQL and there is a lot of blogs about performance and SSD's). Current SSD's are a lot better.

Being on Enterprise Edition, you can also use Index Compression, which helps a lot with overall I/O. It reduces I/O because data is transferred compressed, and more data can be cached in RAM as well.

You will see more CPU utilization, but a typical NAV SQL Server usually has plenty of CPU time available.

Implementing Index Compression requires good analysis though - you have to find the proper candidate indexes (read/write ratio).

A link to more info from Stryk: http://dynamicsuser.net/blogs/stryk/archive/2011/02/15/data-compression.aspx