Thank You for Your time and answer, Henrique: >Well, *any* issue with the disk subsystem will cause such problems to >get several orders of magnitude worse, so yes, one must *first* make >sure the disks are operating at the expected speed.
How I can be sure the HDD is "operating at the expected speed"? >After you are sure the hardware is operating at its proper speed, you >can start tunning the kernel and IO tasks. There is indeed such a >thing as an IO priority per process, but due to CFQ/writeback issues, >tuning that might not be enough. You also have to tune the kernel to >not leave too many outstanding pages. And some filesystems are better >than others for certain workloads. Let me make it clearer a bit *my* situation. For now I'm speaking about simple desktop environment - nothing special w/ the HDD/FS - just SATA disk w/ EXT4 on it. I experience freezes on any applications while, say, I copy a a big file - say just a DVD.iso - I do not think it is normal absolutely. And as You pointed out that the discs can work not at their optimal speed (hardware issue) then I would like to find out that. - I have read that the devices do tune themselves pretty well for the optimal performance, though. So, how I check that? >ionice from util-linux can set the process IO priority. There are >other utilites that can also do that. Is it "nice" :) if I put the following ionice -c 2 -n 7 mc to /etc/rc.local ? Or should put it in some other place - the idea is to run all the mc processes w/ lower IO priorities. >I couldn't readly find any up-to-date (well, up-to-2.6.32) guide on how >to tune the VM subsystem (which controls the writeback) to refer you >to, please look for documentation on how to mess with >the /proc/sys/vm/* tunables. OK. >And there is always the possibility that you have to actually tune the >applications. Even if the filesystem, VM and IO scheduler were perfect >(and they're so far from being perfect it is not funny) you'd still >have only so much IO bandwidth. Also, data access patterns can matter >a lot (even on SSDs, when there are write operations). In other words we do not have much to do, right? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e99a4d1.0c18cd0a.3548.fffff...@mx.google.com
