Mint 13 Xfce seems excessively sensitive to disk activity

[Neolander]

Hello everyone !

I am passing by because I recently gave Mint 13 Xfce a try on my laptop, and it is overall a very pleasant ride except for one thing: I experience major responsiveness issues, including temporary application freezes that can last several seconds, as soon as something is stressing the hard drive a bit in the background. Copying large files with Thunar or cp, as an example, will trigger the phenomenon after a few seconds. It feels very much like a case of extreme swapping in practice, except that the RAM is far from full (typically 800MB/4GB used).

I was previously using Fedora 16 Xfce (current kernel, Xfce 4.8.3), which had no such issues, so the problem sounds Mint-specific on first look. Does anyone have an idea of where it might be coming from and, perhaps most important, how I can solve it?

Many thanks in advance!

[xenopeek]

Without you providing any information about your hardware, no idea Please share the output of:

Code: Select all

inxi -F

That will give us some general idea of your hardware.

[Neolander]

Sorry, there you go:

Code: Select all

System:    Host: minty-graloufotron Kernel: 3.2.0-23-generic x86_64 (64 bit) Desktop: Xfce 4.10.0 Distro: Linux Mint 13 Maya
Machine:   System: ASUSTeK (portable) product: N61Jv version: 1.0
           Mobo: ASUSTeK model: N61Jv version: 1.0 Bios: American Megatrends version: 224 date: 01/26/2011
CPU:       Dual core Intel Core i5 CPU M 430 (-HT-MCP-) cache: 3072 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) 
           Clock Speeds: 1: 1199.00 MHz 2: 1199.00 MHz 3: 1199.00 MHz 4: 1199.00 MHz
Graphics:  Card-1: Intel Core Processor Integrated Graphics Controller 
           Card-2: NVIDIA GT216 [GeForce GT 325M] 
           X.Org: 1.11.3 drivers: intel (unloaded: vesa,fbdev) Resolution: 1366x768@60.0hz 
           GLX Renderer: Mesa DRI Intel Ironlake Mobile GLX Version: 2.1 Mesa 8.0.4
Audio:     Card: Intel 5 Series/3400 Series Chipset High Definition Audio driver: snd_hda_intel Sound: ALSA ver: 1.0.24
Network:   Card-1: Atheros AR8131 Gigabit Ethernet driver: atl1c 
           IF: eth0 state: down mac: 48:5b:39:50:68:ad
           Card-2: Atheros AR9285 Wireless Network Adapter (PCI-Express) driver: ath9k 
           IF: wlan0 state: up mac: 1c:4b:d6:aa:17:79
Drives:    HDD Total Size: 640.1GB (25.2% used) 1: /dev/sda TOSHIBA_MK6465GS 640.1GB 
Partition: ID: / size: 48G used: 7.2G (16%) fs: ext4 ID: /home size: 163G used: 71G (46%) fs: ext4 
           ID: swap-1 size: 9.66GB used: 0.00GB (0%) fs: swap 
Sensors:   System Temperatures: cpu: 55.0C mobo: N/A gpu: 51.0 
           Fan Speeds (in rpm): cpu: N/A 
Info:      Processes: 171 Uptime: 2:27 Memory: 579.6/3746.3MB Client: Shell inxi: 1.7.33 

[xenopeek]

Right. Good to see it's not overheating, though you won't be cold with this on your lap I think.

The laptop has two graphics cards, the one from Intel (which you are using) and one from Nvidia. Did you perhaps install Nvidia software?

The processor should be able to handle copying and doing something else (it has 2 cores, with hyperthreading). The hard disk is not very fast though, with only 5400 rpm. But as you mention you didn't have such problems on Fedora, we can't blame the hard disk. I suggest the next time you can make it freeze, then after it unfreezes to open the file /var/log/syslog in a text editor (Gedit, or run from the terminal "less /var/log/syslog") and at the end of the file--where the timestamps match when it froze--check for any errors.

[Neolander]

Right. Good to see it's not overheating, though you won't be cold with this on your lap I think.

Considering how quiet this machine can get when the fan has been freshly cleaned, I wouldn't be surprised the tiniest bit if the mobo was set up in firmware to keep the fan spinning very slowly until the CPU temperature gets pretty high.

The laptop has two graphics cards, the one from Intel (which you are using) and one from Nvidia. Did you perhaps install Nvidia software?

Nope, I have had so many issues with the NVidia driver in the past that I tend to stick with nouveau on every machine where it works well enough.

The processor should be able to handle copying and doing something else (it has 2 cores, with hyperthreading). The hard disk is not very fast though, with only 5400 rpm. But as you mention you didn't have such problems on Fedora, we can't blame the hard disk. I suggest the next time you can make it freeze, then after it unfreezes to open the file /var/log/syslog in a text editor (Gedit, or run from the terminal "less /var/log/syslog") and at the end of the file--where the timestamps match when it froze--check for any errors.

I tried it, but no error has appeared in /var/log/syslog. I also checked CPU usage while I was at it, and it was at about 10% when things get really nasty, so that doesn't seem to be a problem either.

I also checked out iotop's output while I was at it, with the following typical result...

Code: Select all

Total DISK READ:      26.30 M/s | Total DISK WRITE:      22.89 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
  744 be/3 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [jbd2/sda9-8]
 1351 be/4 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [flush-8:0]
 4402 be/4 gralouf    26.30 M/s   26.17 M/s  0.00 % 95.29 % cp -r Téléchargements/ Téléchargements2
   35 be/4 root        0.00 B/s    0.00 B/s  0.00 % 86.71 % [kswapd0]

...but as usual with system monitoring tools like iotop, I end up taking a puzzled look at the name of kernel components and wondering if they are working as expected or not. So I did the same thing on Fedora, with the result that jbd2 was still highly sollicitated (as could be expected, since writes imply journaling paperwork), but flush-8 and kswapd0 were much less active, only running occasionally from time to time. Perhaps that comparatively high disk cache flushing and swapping activity on Mint is what causes my performance problem, though what causes said activity itself remains to be understood.