Entire system slow when using the disk

f4hy · 2009-02-24 05:21:40

I have found that my whole system grind and moves slowly doing anything that is super disk heavy. Tasks like running pacman -Syu and copying large files from one disk to another makes simple things like scrolling on a web page, audio play back or even moving the mouse become very choppy or unresponsive until the disk activity is done. This should not be happening since those tasks should not need the disk and should be in memory.

I have not had this issue with other distros so not sure what the cause is. Currently I am using XFS with defaults,noatime which is what I have used on the same hardware with Debian but did no have these issues. Any ideas on why this would be?

(as I type this the letters lag because I am backing up my drive...)

f4hy · 2009-02-24 05:25:29

Oh I forgot to mention, I am watching cpu and memory usage with top or htop and it remains low. CPU is <3%

sirocco · 2009-02-24 05:35:48

http://bbs.archlinux.org/viewtopic.php?id=62985

f4hy · 2009-02-24 05:45:40

Thanks, but it looks like they never solved the issue on that thread either. :-(

sirocco · 2009-02-24 07:21:03

Have you tried this?

Last edited by sirocco (2009-02-24 07:23:09)

f4hy · 2009-02-24 07:26:26

I know that is not the issue because monitoring swap use i have noticed that my swap space is never used. In fact half the time I run without an swap space at all. Tuning swappiness wont have any effect if swap space is not being used.

I gave the other thing a try, the vfs_cahce_pressure setting and it did not affect much either.

Wintervenom · 2009-02-24 08:53:05

Didn't help for me, either. Someone on the IRC channel suggested that I disable irqbalance if I was using it, and I tried that, but that also did not work.

xaiviax · 2009-02-24 17:09:08

Switching to deadline scheduler fixed this issue for me (as per the other thread)

f4hy · 2009-02-24 20:01:11

Thanks guys, but neither of those seem to be the case for me. I do not have irqbalance installed and I think I am using the deadline scheduler.

zcat /proc/config.gz | grep IOSCHED
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_IOSCHED="cfq"

I assume the DEADLINE=y means I have the deadline scheduler running. Why would this be a scheduler issue? Anyone have an article talking about this?

f4hy · 2009-02-24 20:04:16

In addition
$ cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]

Looks like deadline is there. This is frustrating. I think I will format and go back to Debian and check out what their scheduler settings are to compare.

dunc · 2009-02-24 21:01:16

f4hy wrote:

In addition
$ cat /sys/block/sdb/queue/scheduler
noop anticipatory deadline [cfq]
Looks like deadline is there. This is frustrating. I think I will format and go back to Debian and check out what their scheduler settings are to compare.

That lists the available schedulers, and the one with brackets is the one currently in use. So deadline is there, but you're using CFQ.

The excerpt from your kernel config shows the same thing: deadline has been built, but the default (and therefore the one in use if you haven't changed it manually) is CFQ.

So, to switch to deadline for /dev/sdb:

# echo deadline > /sys/block/sdb/queue/scheduler

(As root, of course.)

Edit: If you find it works for you, you can make GRUB select it at boot time by adding it to the kernel line in /boot/grub/menu.lst:

kernel /boot/vmlinuz26 {... whatever else you have here ...} elevator=deadline

Last edited by dunc (2009-02-24 21:08:36)

SLKDK · 2009-02-24 21:12:28

I still have this problem.. Tried the swap thingy (although my swap never get used anyway), tried the deadline scheduler, no effect at all.

Ranguvar · 2009-02-24 23:22:16

There's a couple other, more drastic, measures I posted in that other thread (one is a kernel patch that hacks around a little of the problem but does not completely fix it).

cerbie · 2009-02-25 02:54:17

Also, check and make sure it's not something silly, like not using DMA, or something like that, too. In case it's a FS/block device thing, if you're running a new disk (SATA w/ NCQ), see if making a big queue or making a small queue changes anything (there's an hdparm option for that).

I've not had such issues on Arch, but have on others, and yeah, it's just not fun to deal with. If you have another drive you can back up to, maybe try another FS? I don't think XFS is the problem in itself, but it could be a fix (note 'could'--there's always the risk that it's not).

Last edited by cerbie (2009-02-25 02:55:46)

f4hy · 2009-02-26 03:33:00

I have now tried the deadline scheduler and it did not change anything.
I know it is not something wrong with my physical disk since this machine does not experience the issues when booted into other distributions. I do not know if arch is configured wrong to cause the problem, or the other distributions I have, have done something smart to fix it, but I am out of ideas.

The kernel patch might be worth trying but it seems ridiculous that arch would need a patch like that but other distros don't (unless they are doing patches like that.)

If anyone has and idea on how to better monitor to problem to find the cause let me know as that is what I would really like to see rather than shooting in the dark. Any ideas on things I should be looking for in logs to see what would cause this?

Ranguvar · 2009-02-26 03:55:00

@f4hy: I don't believe any other distro is using that patch. If you're _sure_ the problem doesn't happen with other distros, it's definitely a configuration problem somewhere. The only thing I can say is do normal troubleshooting steps. Does a fresh Arch install have the problem? Does it only happen when X is running? Are you using the same partition setup (check fstab in both distros)? Setting relatime or even noatime in your fstab might be a good idea.

Etc...

f4hy · 2009-02-26 04:00:34

Ya, noatime is set in all distros tried. It does NOT only happen when X is running as simple thing like opening a text editor emacs/nano/vi take many many seconds to a minute longer than normal when doing something disk heavy on one of the other virtual consoles, but start up instantly otherwise.
I guess I will try it on a completely fresh install of arch to see if it was something I did but only when I have time to do a full backup and wipe the partition. It seems from the other thread and one post here that I am not alone in this issue though.

broch · 2009-02-26 05:25:42

check
hdparm -i /dev/partition

see if highest UDMA set, not PIO

f4hy · 2009-02-26 05:27:21

Thanks. But udma6 is set, which is the highest displayed.

Rehto · 2009-02-26 12:31:40

I noticed this slowness when ktorrent was preallocating the whole torrent to disk... system becomes really laggy and slow to response. I'm thinking of doing a fresh install with the 2009.02 ISO and check if anything has changed for the better...

signor_rossi · 2009-02-26 12:36:32

Rehto wrote:

I noticed this slowness when ktorrent was preallocating the whole torrent to disk... system becomes really laggy and slow to response. I'm thinking of doing a fresh install with the 2009.02 ISO and check if anything has changed for the better...

Maybe you should disable preallocation in ktorrent or better use qbittorrent, which works very well.

I am also not happy with the performance of my system during harddisk I/O, I am trying out relatime in fstab now (have to reboot).
EDIT: Seems slightly better with relatime.

Last edited by signor_rossi (2009-02-26 13:20:56)

Rehto · 2009-04-05 10:43:40

I'm trying out the deadline scheduler if it helps with this problem.
The problem usually raises its ugly head when moving large files
between partitions. I also enabled noatime in /etc/fstab so let's see...

Last edited by Rehto (2009-04-05 11:20:08)

Rehto · 2009-04-05 12:51:13

OK things are much better now I guess deadline + noatime did it

Rehto · 2009-04-09 07:08:05

OK I was clearly wrong when I said that the problem disappeared,
it's still there but now my system is not so laggy as before I can
actually use it now...

schuay · 2009-04-09 07:25:24

I can't add anything constructive here, but I can confirm this issue.. The system slows down when copying large files - same issue on several installs, all arch (haven't tested any others).

Arch Linux

#1 2009-02-24 05:21:40

Entire system slow when using the disk

#2 2009-02-24 05:25:29

Re: Entire system slow when using the disk

#3 2009-02-24 05:35:48

Re: Entire system slow when using the disk

#4 2009-02-24 05:45:40

Re: Entire system slow when using the disk

#5 2009-02-24 07:21:03

Re: Entire system slow when using the disk

#6 2009-02-24 07:26:26

Re: Entire system slow when using the disk

#7 2009-02-24 08:53:05

Re: Entire system slow when using the disk

#8 2009-02-24 17:09:08

Re: Entire system slow when using the disk

#9 2009-02-24 20:01:11

Re: Entire system slow when using the disk

#10 2009-02-24 20:04:16

Re: Entire system slow when using the disk

#11 2009-02-24 21:01:16

Re: Entire system slow when using the disk

#12 2009-02-24 21:12:28

Re: Entire system slow when using the disk

#13 2009-02-24 23:22:16

Re: Entire system slow when using the disk

#14 2009-02-25 02:54:17

Re: Entire system slow when using the disk

#15 2009-02-26 03:33:00

Re: Entire system slow when using the disk

#16 2009-02-26 03:55:00

Re: Entire system slow when using the disk

#17 2009-02-26 04:00:34

Re: Entire system slow when using the disk

#18 2009-02-26 05:25:42

Re: Entire system slow when using the disk

#19 2009-02-26 05:27:21

Re: Entire system slow when using the disk

#20 2009-02-26 12:31:40

Re: Entire system slow when using the disk

#21 2009-02-26 12:36:32

Re: Entire system slow when using the disk

#22 2009-04-05 10:43:40

Re: Entire system slow when using the disk

#23 2009-04-05 12:51:13

Re: Entire system slow when using the disk

#24 2009-04-09 07:08:05

Re: Entire system slow when using the disk

#25 2009-04-09 07:25:24

Re: Entire system slow when using the disk

Board footer