Quantcast
Channel: File Services and Storage forum
Viewing all articles
Browse latest Browse all 13565

Copying to one storage pool affects services on another

$
0
0

Hello everyone,

I have a Windows Server 2012R2 that is used as a file server as well as an application server. When I am copying data to the fileserver shares (StoratgePool A) it heavily impacts my application what is located on a different storage pool (B) (up to 15 seconds of write-latency).

My setup:

StoragePool A with 3 HDDs
- 2 disks with parity enabled
- 1 volume / disk using ReFS
- my file shares are on one of these volumes
StoragePool B with 1 SSD
- 1 Disk
- 1 Volume using ReFS

I do not see any limits on CPU or RAM (i3-4370 - 3.8GHz | 16GB DDR3 RAM), neither of these are heavily utilized. In perfmon I can see pretty bad sec/transfer values for my file share (10-20s) but not for my application disk (3ms at max). Also I noticed the copy process goes really fast for some seconds and then stops abruptly for a while. At the same time RAM is being used up. I assume this is FS caching? I don't know if this could be a problem here, but is there a way to change this behaviour for ony volume only? Overall my transfer rate is at 20-30 MB/s for my file shares what is pretty low for my standards as I ran a different setup before with the same disks and got about 50-60MB/s transfer rates using ZFS on freeBSD.

Where do I have to look to find the bottleneck here? Why does one storage pool affect another? Is there a way I can tweak the performance of my HDD pool?

I would be grateful for every hint!

Edit\ Some additional information:

I just ran a disk benchmark for both the share storage pool as well as the storage pool my affected application is sitting on. As expected the app-SP was as fast as an SSD is but for the share-SP I just have to post the following (since I am not allowed to embed images in my posts I can just give you a link):
http://imgur.com/YE7nWNL
0.5/0.1 random read/write? That's really slow. Also I found out that during the testing process disk latency was much more normal than what it was when copying the large amount of files (this time I only had about 40ms peaks instead of 15s!). Additionally I noticed that no RAM was comsumed during the benchmark so I guess no filesystem caching this time. So it probably has something to do with FS caching. I hope this helps finding a possible solution.





Viewing all articles
Browse latest Browse all 13565

Trending Articles