How are you measuring them to say that one is faster than the other? Of course the SAN is faster, it is lower in the chain. So the SAN, by definition, must be "faster" in a raw sense. But there is no way to directly compare the performance of a SAN and a file server. So we'd need clarify as to how you are handling this.
If you are looking for throughput, that is going to heavily limit what the SAN can send. IOPS won't be too affected, but throughput definitely. BarryH wrote: 1 VM does a file transfer 3 time faster than the other. Sounds likely that you have resource contention or other choke point.
What OS are you using for the file servers? Can you get some metrics? Things that might be happening are: out of memory or lacking enough free overhead , lack of cache, CPU exhaustion, driver issues, open file handles, etc. It is very likely that we simply need to correct tune the file server s to handle the load, that they are a bottleneck is not unlikely, that they need to be a bottleneck probably is.
The amount of users that can be handled by a single file server is pretty extreme. BarryH wrote: So is it safe to assume yes i know what assume means that I can speed things up by creating more file servers?
Yes, that is likely true BUT it creates other issues It is an inefficient use of the file server resources. Exactly as it sounds. The operating system should never have an iSCSI initiator or talk to storage - doing so bypasses the intended architecture and defeats part of the purpose of hardware abstraction virtualization. Can you do it? Is it useful in a lab, sure. But in production, never. If you don't have faith in Vmware, you should move to a different hypervisor, not try to work around your vendor's architecture.
VMware will present storage as appropriate from there. So are you saying the you should just make the server image large enough for the hosted data?
Is there another way of connecting storage to a server that is a VM in vSphere? Verify your account to enable IT peers to see that you are a professional. Accessing programs on the server is slower resulting in long loading times, slower report generation, etc. I am wondering what options or tools I have, if there are any at all, to find out exactly where these hang ups might be coming from.
Perfmon counters and a tool called PAL Performance Analysis of Logs which includes a set of thresholds for various counters. It also generates a report which points out which counters exceeded the thresholds. Along with what EightBitTony has pointed out, you can "net out" the network aspects by hard coding the NIC line settings vs.
The multiple timing of the same transfers will help determine any speed fluctuations. Running a tracert between your computer and the server, would be useful for discovering if a network node between your computer and the server is the source of network slowdowns.
Also, I would recommend establishing a baseline configuration of the new server for monitoring the server's performance. Plus, in this instance, I'd add Disk View.
Process Monitor : Actually watch what the machine is doing. One of the default filters is to drop anything from the "System" process. Turn this filter off when diagnosing a file server issue. However, do turn on "drop filtered events". Being a file server, I'm guessing you have Anti-Virus on-access scanning enabled? Plus, you may have volume shadow copy snapshots running?
Could you confirm whether this is the case? Generally, with x64 file servers, I'd recommend setting the page file to "system managed" and keep it on a separate volume. Plus I'd keep a close eye on the "peak commit charge". Having monitored this for a while, you should be able to judge whether more memory is required. I've seen issues with XP clients running against WinR2. When I remember the specifics, and more importantly, the solution, I'll update this post I would give Microsoft Server Performance Advisor a try.
It claims to actually provide recommendations to help fixing performance issues. You will also discover that performance monitor has numerous features to make collecting data easier and more profitable.
Once you have scientifically collected the data, the art comes in interpreting the logs. I have identified three skills which all good performance analysts possess:. Learn the secrets of which counters to monitor. Master performance monitor logging, develop your skills with structured exercises and examples.
Print out a copy to read, while you design logs and alerts to detect network bottlenecks. Identifying server performance problems. Planning the capacity of your servers and subnets.
Setting alerts so that you can nip trouble in the bud. Creating baselines when activity is low. Understanding the effect of your workload on resources.
0コメント