On Mon, May 2, 2011 at 4:30 PM, Ted Mittelstaedt <t...@mittelstaedt.us>wrote:
> that's sync within the VM. Where is the bottleneck taking place? If > the bottleneck is hypervisor to host, then the guest to vm write may write > all it's data to a memory buffer in the hypervisor that is then > slower-writing it to the filesystem. In that case killing the guest without > killing the VM manager will allow the buffer to complete emptying since the > hypervisor isn't actually being shut down. No the bottle neck is the emulated hardware inside the VM process container. This is easy to observe, just start a bound process in the VM and watch top host side. Also the hypervisor uses native host IO driver, there's no reason for it to be slow. Since it's the emulated NIC which is the bottleneck, there is nothing left to issue the write. Further empirical evidence for this can be seen by by watching gstat on VM running with an md or ZVOL backed storage. I already utilize ZVOL's for this so it was pretty easy to confirm no IO occurs when the VM is paused or shutdown. Is his app going to ever face the extremely bad scenario, though? > The point is it should be relatively easy to induce patterns you expect to see in production. If you can't, I would consider that a problem. Testing out theories(performance based or otherwise) on a production system is not a good way to keep the continued faith of your clients when the production system is a mission critical one. Maybe throwing more hardware at a problem is the first line of defense for some companies, unfortunately I don't work for them. Are they hiring? ;) I understand the logic of such an approach and have even argued for it occasionally. Unfortunately payroll is already in the budget, extra hardware is not even if it would be a net savings. -- Adam Vande More _______________________________________________ freebsd-emulation@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-emulation To unsubscribe, send any mail to "freebsd-emulation-unsubscr...@freebsd.org"
