Diskkeeper turn off active free#
Slap the admin who doesn't thin provision.Ĭattleprod the storage admin/VMware admin who doesn't have alarms for rapid growth.Īs you have enterprise kit that can do ZPR, you might just setup powershell scripts that once a quarter, run Sdelete and zero free space, and then kick of the SAN to reclaim the Zero's. Ok, fire whoever ran disk keeper in a VM. Time for my favorite game of Fire/Slap/cattleprod! It's one thing if you lack the knowledge, quite another if you know better and still use thick. I see that as ignoring a big part of the job. I think it's lazy and wasteful, and pretty hypocritical to evangelize virtualization and all the efficiency benefits that it brings to the table, but then to purposely ignore the storage efficiency to be had with TP because you don't want to spend the time managing how VMware uses the underlying storage. Needless to say, I didn't get along real well with that VMware admin.
Diskkeeper turn off active windows#
I admit I have had similar experiences, but found ways to prevent it from happening again without using thick, and without killing/firing uninformed Windows admins. His approach was based on the fact that he had run datastores out of space and crashed some VMs when some Windows admin decided to run Diskeeper on all the VMs and write out all the blocks in the. I know a VMware admin who would not do thin, and went to great lengths to make sure nobody would thin provision any VMs. Some arrays will actually perform WORSE with thick provisioning (3PAR, is crazy worse, although its kind of annoying to enable it, and they tell you not to do it). HDS and XIV with Dynamic pools operate this way. Most modern arrays allready are virtualized at some level with a reasonable chunk size, though and so your thin really on the backed weather you select it or not (all thick does is prevent over provisioning). (EMC's VNX and VMAX block lines, cuts random reads almost in half in my benchmarking) and traditional thick provisioning on LSI Engimo gear (and Netapp-E series) is the standard for high througput stuff. I will point out that on some "Legacy" arrays, Thin performance may not be the same as "thick". That's still thin, just using a different approach to thin. As John points out, there are cases where, using VAAI, it makes sense to do thin but not to do it in the VMware interface but in the SAN interface instead.
Scott do you still stand by this statement? It just brings too many problems or lack of advantages. Unless you have a latency sensitive, IO bound application thick is rarely a good choice. What they need is reliability, ease of management, cost management, etc. SMBs have a mindset, much of the time, of "performance over everything" when, in reality, performance is about the last thing that SMBs need. The problem is, SMBs here "performs better" and stop thinking critically most of the time and jump on that even thought the performance difference is rarely measureable and they take all kinds of other, sometimes massive, penalties. I was always told that thick provisioning provides better performance for the VM, is this accurate? TBH I've done both and I'll be damned if I could actually notice a difference in performance between a Vm that was thick or thin provisioned?! Not to hijack this thread, but question for SAM :). Thin provisioning leverages the advantages of virtualization and consolidation, allows for more flexibility and requires less "clairvoyance." When in doubt, thin. always thin unless you have a very strong argument otherwise.
0 kommentar(er)
