running a chgrp -R over a series of directories on an LVM partition and I noticed that it was taking forever. So I ran vmstat (sorry about the line wrapping) and found that it was spending roughly 99 percent to 100 percent of the time waiting for (disk??) io. any ideas why performance is less than ideal? procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 1 1 1908 1480 42428 5464 0 0 254 1462 320 189 0 1 0 99 1 1 1908 1416 42668 5464 0 0 264 885 271 160 0 1 0 99 0 1 1908 1304 42892 5464 0 0 266 1051 280 177 0 0 0 100 0 1 1908 1352 42836 5464 0 0 273 1029 282 164 0 1 0 99 0 2 1908 1640 42720 5464 0 0 258 1016 264 168 0 0 0 100 -- http://www.wired.com/wired/archive/13.03/view.html?pg=5 The result of the duopoly that currently defines "competition" is that prices and service suck. We''re the world''s leader in Internet technology - except that we''re not. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
more info. Don''t know if it means anything. Eric S. Johansson wrote:> > running a chgrp -R over a series of directories on an LVM partition and > I noticed that it was taking forever. So I ran vmstat (sorry about the > line wrapping) and found that it was spending roughly 99 percent to 100 > percent of the time waiting for (disk??) io.I changed to a chgrp -Rv and what became apparent is that searching directories seem to cause a problem. This is using the reiserfs filesystem. whenever the system was displaying the results of chgrp, the wait time would drop to under 70 percent and frequently around 50. As soon as the display of actions stopped and it was working on the disk, it would go back to 100 percent wait time. my expectation is that the system cued up requests for the network and spent more time sending data than waiting for data. Contrast that with the disk activity which is high probability all wait time (IDE on dedicated controller) -- http://www.wired.com/wired/archive/13.03/view.html?pg=5 The result of the duopoly that currently defines "competition" is that prices and service suck. We''re the world''s leader in Internet technology - except that we''re not. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Eric S. Johansson skrev:> > running a chgrp -R over a series of directories on an LVM partition > and I noticed that it was taking forever. So I ran vmstat (sorry > about the line wrapping) and found that it was spending roughly 99 > percent to 100 percent of the time waiting for (disk??) io.Why is this a bad thing? Does the CPU have anything else to spend its time on? This sound normal to me. You might also want to tell us how this is relevant to Xen. :-) -- There are only 10 different kinds of people in the world, those who understand binary, and those who don''t. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Per Andreas Buer wrote:> Eric S. Johansson skrev: > >> >> running a chgrp -R over a series of directories on an LVM partition >> and I noticed that it was taking forever. So I ran vmstat (sorry >> about the line wrapping) and found that it was spending roughly 99 >> percent to 100 percent of the time waiting for (disk??) io. > > > Why is this a bad thing? Does the CPU have anything else to spend its > time on? This sound normal to me. You might also want to tell us how > this is relevant to Xen. :-)10x slower than a non xen machine and it just crashed+rebooted my xen setup. relevent enough?? ;-) -- http://www.wired.com/wired/archive/13.03/view.html?pg=5 The result of the duopoly that currently defines "competition" is that prices and service suck. We''re the world''s leader in Internet technology - except that we''re not. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> >> running a chgrp -R over a series of directories on an LVM > partition > >> and I noticed that it was taking forever. So I ran vmstat (sorry > >> about the line wrapping) and found that it was spending > roughly 99 > >> percent to 100 percent of the time waiting for (disk??) io.The high iowait may be due to the 2.6 dom0 blkback wait queue issue that is under investigation. It would be interesting to know what happens if you use a 2.4 dom0.> 10x slower than a non xen machine and it just > crashed+rebooted my xen setup. relevent enough?? ;-)The crash is very worrying. Is this Xen 2.0.5? Is this repeatable? Can you use a debug build and get a serial line on the machine? Thanks, Ian _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users