Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
hyper-v with Solid State Drives

Answered hyper-v with Solid State Drives

  • Friday, January 04, 2013 12:38 PM
     
     
    Sign In to Vote
    0

    Hi,

    I need to build a new server that uses Hyper-V and provides very good file read/write speeds for a database application. The database is a flat file database and doesn't have any SQL component or anything like that.  It just uses a shared folder.   Currently it's running as a HyperV server on a 7.2k RAID1 hard drives and it's very slow.

    The scenarios I have in mind are:

    1. Install the OS on 7.2k RAID1 drives, then keep the database shared folder on an attached Static VHD that resides on an SSD in RAID1.

    2. Same as above, but instead of using an attached VHD, use the internal hard drive pass through feature to give the VM access to the SSDs directly.

    3. Install the OS and application server on the SSDs on a single VHD.

    Option 1 and 2 use the same hardware, but option 3 would require buying 200GB SSDs instead of 100GB SSDs.  So does anyone have a preference or perhaps another option that I haven't thought of?

     

All Replies

  • Friday, January 04, 2013 2:49 PM
     
     Answered
    Sign In to Vote
    1

    Unless the VM is doing a lot of hard page faulting (easily fixed by adding more memory to the VM), putting the OS and application on the SSD will provide speed for initial launch but very little benefit for running after the application is loaded.  Your best bet is to place the 'database' on the SSD.  Yes, you could make it a pass-through disk to the VM, but you lose a lot of flexibility for very little performance gain over simply placing the database in a VHD that is stored on the SSD.

    Without a better description of your 'database' application, it is pretty hard to tell what else might be possible.  Generally, though, flat files for databases are inherently inefficient.  Introducing indexes or keeping the file in memory are other ways to significantly improve performance, even from slow disks.

    tim

     
  • Friday, January 04, 2013 4:06 PM
    Moderator
     
     Answered
    Sign In to Vote
    0

    Tim has some wisdom there.

    I used to handle software that had flat file databases (medical practice management software that used an old DBASE format, ick).

    I had issues that were more than just disk IO.  It was how the application handled file locking.  I ended up moving to a database engine that worked with flat file databases and we had the application developer modify his code to offer that option.  It also had to run on Netware (at the time).

    My point, faster disks might not fix the issue.  Did you test to make sure that they will, before you commit?

    There might also be issues with the application itself and how it reacts to being in a VM.  Not all applications run well in VMs.  Especially single threaded applications.  They end up in a situation where they perform poorly and it is all about CPU slicing.

    I am assuming that you have already considered RAM.

    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.

     
  • Friday, January 04, 2013 5:55 PM
     
     Answered
    Sign In to Vote
    0

    just want to add this.. if you'll go for ssd, choose an enterprise level one.. not cheap/commercial.. 

    it is very important the power hold architecture of the ssd interface..

    and evaluate a battery back up on your raid controller if dont already have or at least a good UPS

    regards

    ------------------------------------------------------- I understand a little computers.

     
  • Friday, January 04, 2013 6:01 PM
     
     
    Sign In to Vote
    0

    Thank you very much for these insights, Tim and Brian.

    I am glad to hear that pass-through wouldn't help that much. I want to avoid that.

    I have not tested SSDs.

    The program is called Lacerte Tax and we're an accounting firm.  It creates a folder structure which contains the loose files. Then a client program is installed on each client which accesses the server's shared folder.

    The most used portion of the shared folder is 12MB in size and contains 1670 files.  The average file is between around 7KB.

    The performance is worse as the number of concurrent users increases.  The number of concurrent users is around 15.

    Below are the Host and Guest server specs and the the results of a network file transfer speed test.

    Server specs:
    Host Server:
    -Lenovo
    -OS: Windows Server 2008 R2. 
    -CPU: E5607 @ 2.27 GHz, 4 cores.
    -RAM: 16GB
    -HDD: 265 GB of 465 GB free

    Hyper-V Guest Server (there is only one Guest OS)
    -CPU: 4 cores assigned
    -RAM: 8 GB static RAM - has about 6GB unused.
    -Hard drive: Dynamic VHD, 443GB of 599GB free
    -Actual VHD size: 169GB
    -Applications: This server is only doing file sharing and running the Quickbooks Database Manager software.
    -The whole Lacerte folder that contains the entire database is 7GB.

    File Transfer Speed Test:
    from shared folder across network using a 500GB test file: 75 MBps
    from shared folder across network using 1670 7KB files: 2 MBps

    Alan



     
  • Friday, January 04, 2013 6:08 PM
    Moderator
     
     
    Sign In to Vote
    0

    So.  If the "Server" is essentially a file server you might want to consider if it is caching (and disk caching, not just RAM caching, within the application).  You have to fiddle around with non-default performance counters to find this stuff.

    You might also want to disable caching on the share.

    If the user perception is that it slows down as the load grows it could simply be a file locking problem, inherent to the software in this case.

    And, does it run better on bare metal instead of in a VM?  (any historic information there).

    Brian Ehlert
    http://ITProctology.blogspot.com
    Learn. Apply. Repeat.
    Disclaimer: Attempting change is of your own free will.