Am Sonntag, 16. Oktober 2011 schrieb Sthu Deus:
> Thank You for Your time and answer, Martin:
> >Thats a typical workload where certain kernels have lots of problems
> >with interactivity. I think its best to use at least kernel 2.6.37. At
> >some kernel version CFQ gained a low_latency mode which is enabled by
> >default. Best would probably be to update to the most recent backport
> >kernel. But as thats just a wild guess its better to first find out
>
> >what the actual problem is:
> I use the 2.6.40 from testing. Oh, well I mean 3.0.0. :)
>
> >Please do you what you do when you experience slow operation, run
> >vmstat 1 and post the output of at least 15 lines here. Also describe
> >what exactly you do, what stuff is running - for example which desktop
> >environment with/or without desktop search for example - and if
> >commands are involved post examples.
>
> procs -----------memory---------- ---swap-- -----io---- -system--
> ----cpu----
> r b swpd free buff cache si so bi bo in cs us sy
> id wa
[…]
> 1 3 0 70128 18560 789672 0 0
> 4629 6287 1607 1468 41 13 10 35
>
> 1 4 0 73600 18660 785676
> 0 0 4962 10240 1862 1920 43 14 4 40
>
> 4 2 0 74584 18632
> 784204 0 0 9336 4096 1852 1706 45 17 7 32
>
> 1 2 0 71400
> 18720 787452 0 0 8132 6144 1506 1376 34 12 7 47
>
> 1 2 0
> 66204 18756 792440 0 0 8738 4329 1273 1093 10 10 13 67
>
> 1
> 1 0 74884 18756 782976 0 0 4994 0 1182 910 10 6 16
> 67
When I understand the poorly formatted lines correctly thats a quite high
I/O wait for ...
> I was coping a 6GB file between dir.s within the same partition of the
> HDD having at the time of copy process start 17GB of free space.
... copying a 6GB file - last value on each line ("wa"). Thats percentage
of CPU time the kernel could have used letting processes run if they didn
´t wait for syscalls (like I/O operations). Also the throughput seems
pretty low - even for copying on the same drive.
How do you copy the file? Maybe the method you use for copying uses small
buffers and thus needlessly generated disk seeks. You might try using dd
with bs=1M ;).
> I ran OpenArena that freezed from time to time, say I had 15 secs of
> playing then 3 secs of freeze, then game farther continues.
It might have just be waiting for something on disk? The CPU does not seem
to be fully loaded.
> I use LXDE - now file searching/indexing AFAIK. I had two sessions at
> the time through KDM or whatever it organizes.
Looks reasonable.
> >Then also include at least the following:
> >
> >- hdparm -I /dev/sda | egrep -i "(model|transport:|likely used|DMA:)"
> >(replace sda by whatever your drive is)
>
> Model Number: Hitachi HTS547575A9E384
>
> Transport: Serial, ATA8-AST, SATA 1.0a, SATA II
> Extensions, SATA Rev 2.5, SATA Rev 2.6; Revision: ATA8-AST T13
> Project D1697 Revision 0b
I guess thats an 3.5 inch drive? (Don´t want to bother with looking up the
model...). For a laptop drive above numbers could make some sense. Is it a
7200 or 5400 rpm drive? This could have an influence, since seeks could
have been involved.
> Capabilities:
> LBA, IORDY(can be disabled)
> Queue depth: 32
> Standby timer values: spec'd by Standard, no device specific
> minimum R/W multiple sector transfer: Max = 16 Current = 16
> Advanced power management level: 128
> DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5
> *udma6 Cycle time: min=120ns
> recommended=120ns PIO: pio0 pio1 pio2 pio3
> pio4 Cycle time: no flow control=120ns IORDY flow
> control=120ns
Thats nice, the kernel is using DMA for accessing the drive.
> >- lspci -nn | egrep -i "(ide|sata)"
>
> SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5
> SATA [1002:4380]
>
> IDE interface [0101]: ATI Technologies Inc
> SB600 IDE [1002:438c]
Now there might be an issue. I don´t know how good this SATA controller
works.
> >- grep -i "model name" /proc/cpuinfo
>
> AMD Turion(tm) 64 X2 Mobile Technology TL-52
Or do you happen to do this on a laptop drive?
Then this might explain this issue as well... laptop drives aren´t the
fastest.
> >- uname -a
>
> 3.0.0-1-amd64 #1 SMP Sat Aug 27 16:21:11 UTC 2011 x86_64 GNU/Linux
Okay, although there is a 3.0.0-2-amd64 available thats pretty recent.
So my suggestions:
- try to reduce the trigger on when the kernel starts to writeback data
- try to use ionice with the IDLE priority for the copy process
- or use block i/o controller to limit the bandwith
That might help at least a bit. But in the end you seem to face hardware
limitations by either the controller or in case you actually use a laptop
harddisk most likely the laptop harddisk.
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
--
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/201110171645.08200.mar...@lichtvoll.de
