Xfce is very slow, part 2

Ralf Mardorf ralf.mardorf at alice-dsl.net
Tue Jan 14 21:12:55 CET 2014


On Tue, 2014-01-14 at 13:45 -0500, Allin Cottrell wrote:
> On Tue, 14 Jan 2014, Hartmut Haase wrote:
> 
> > 4. C) Really bad HDD performance: my HDD is the newest part of the PC
> > $>sudo smartctl -a /dev/sda
> > [sudo] password for haase:
> > smartctl 6.2 2013-04-20 r3812 [i686-linux-3.11.0-15-generic] (local build)
> > Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
> [snip]
> 
> You got some uninformed noise in response to your HDD information. See
> http://sourceforge.net/apps/trac/smartmontools/wiki/Howto_ReadSmartctlReports_ATA
> for how to read such reports. In fact there's no indication of trouble in 
> your report (though a firmware update may be a good thing).
> 
> Here are the lines that someone said were problematic:
> 
>   ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH
>     1 Raw_Read_Error_Rate     0x000f   118   099   006
>     7 Seek_Error_Rate         0x000f   077   060   030
> 
> The thing is the _small_ values are bad here (a value less than THRESH is 
> considered a failure). Your values are perfectly healthy.

"Please keep in mind that the conversion from RAW value to a quantity
with physical units is not specified by the SMART standard!
smartctl only reports the different Attribute types, values, and
thresholds as read from the device. It does not carry out the conversion
between "Raw" and "Normalized" values: this is done by the disk's
firmware."

IMO those raw values might or might not be meaningless, but seemingly
I'm mistaken and they are meaningless. I anyway still guess it's related
to the HDD, even while I agree that I misinterpreted the values.

> > $>free
> >             Gesamt Belegt Frei Gemeinsam Puffer Cached
> > Speicher:    1018104     905188     112916          0     191836     360764
> > -/+ Puffer/Cache:     352588     665516
> > Auslagerungsdatei:    1052220     175804     876416
> 
> This seems more relevant: you have about 90% of RAM in use and are well 
> into swap. With your system in that position I can see that it might take 
> a while to start up another big application. Maybe you're running 
> something that's gradually leaking memory.

Sometimes 90% usage of RAM isn't an issue, since Linux does use RAM in a
smart way, it's wanted to use much RAM. When using the swap and this
does slow down the machine that extrem, a HDD failure still can't be
excluded. Somebody asked for information about the graphics, I have no
time to search this message now. Was there RAM used for the graphics
frame buffer? Is e.g. real transparency used? When using an ATI with the
FLOSS driver and a rt patched kernel I can't use transparency. I'm using
4 GiB RAM and just a little bit for the frame buffer, however, if the OP
with 1 GiB of RAM also use a little bit for the frame buffer, then he
might have 512 MiB only (I won't read man free now to see what it
shows).

I already mentioned that running additional tests doesn't harm, disc
checks and IO monitoring.

Perhaps vmstat gives useful information?

$ man vmstat
[snip]
   Swap
       si: Amount of memory swapped in from disk (/s).
       so: Amount of memory swapped to disk (/s).

   IO
       bi: Blocks received from a block device (blocks/s).
       bo: Blocks sent to a block device (blocks/s).

   System
       in: The number of interrupts per second, including the clock.
       cs: The number of context switches per second.

   CPU
       These are percentages of total CPU time.
       us: Time spent running non-kernel code.  (user time, including nice time)
       sy: Time spent running kernel code.  (system time)
       id: Time spent idle.  Prior to Linux 2.5.41, this includes IO-wait time.
       wa: Time spent waiting for IO.  Prior to Linux 2.5.41, included in idle.
       st: Time stolen from a virtual machine.  Prior to Linux 2.6.11, unknown.
[snip]

I don't know how a bad output for vmstat looks like, but perhaps
somebody/we will realise it, if we see it.

Please post the output of
$ LANG=C vmstat

Regards,
Ralf



More information about the Xfce mailing list