You are not logged in.
I updated my system after 3 weeks break, and the update included the whole filesystem change.
Since I did that, the system became less responsive, ie. quite often it just freezes for (fractions of) seconds when I can't even move mouse cursor.
It was never happening before.
Last edited by Lockheed (2013-06-28 07:36:48)
Offline
That's not much to go on. How often is "quite often"? how long has it been since your big update? Has this problem persisted through reboots, or has it only been within a single session?
If it happens often enough to be expected "soon", then start up a process monitor like htop to see what is using system resources (CPU/mem).
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
It always happens after first boot, for about 1-2 minutes till system settles.
Then occasionally, when there is some workload, but not really CPU related. I would sooner relate it with diskread, but I have a very quick SSD, and the HDD led doesn't light up.
Last edited by Lockheed (2013-06-16 14:19:32)
Offline
Lot of things (after an upgrade) can affect the system. The first that comes in my mind is the kernel update and/or graphics card driver update.
Take a look in some logs and see if any useful messages are located there.
/var/log/Xorg.0.log
~/.xsession-errors
dmesgKISS my Arch
Offline
"some workload" doesn't help. The point of the process monitor suggestion was to narrow down what program/package might be the problem as what was updated wouldn't help as it was probably every package on your system.
(edit: typo)
Last edited by Trilby (2013-06-18 14:19:32)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I run some tests with and without htop, and it does not seem to be associated with any particular package.
It seems to happen when there is a sudden disk read operation, for example, when I am running a geany text editor to edit a simple file, or click on a link in an external program that opens a new subwindow in an already running Opera instance.
Strangely enough, it does not seem to be associated with the size of the file being read - it is much less persistent (if at all) when I open a 2GB mkv video file than in the instances given above
(but it might be because all large files are stored on sda, which is a HDD, and the system is on sdb, which is a SSD).
Offline
I have seen such behaviour when my system is swapping. Can you see any spike in swap usage?
Offline
Yeah, it sounds like it, and I had such behaviour but only when system dumps like 1GB to the swap.
In this case, swap usage stays intact.
Offline
Well maybe you should see if there is updated firmware for your SSD.
Offline
Thanks, but I already have the newest firmware, besides it was working fine 5 days ago before the system update.
Offline
I can add that even after setting swappiness to 0, the freezes are severe, especially just after boot when new programs are loaded from SDD to RAM and later on when I start large programs.
This is not related to SSD hardware.
Offline
See what happens with a new fresh user perhaps?
Although it sounds like hardware ![]()
bitcoin: 1G62YGRFkMDwhGr5T5YGovfsxLx44eZo7U
Offline
What about things like I/O scheduler? Could it be related?
Offline
What about things like I/O scheduler? Could it be related?
Instead of asking others if this might help with problems you are having, why don't you just try it and see? You really haven't said a whole lot about the problem in general, so you are asking people to just guess. The way I see it, this amounts to help vampirism.
Offline
I would gladly say more if I knew what else can I say.
As for trying out schedulers, I already did with noop and cfq. I'm trying to get BFQ kernel now to try it, too.
Offline
You can even try different distros to see if the problem persists.
Offline
I have a 2-month old image of my Arch installation on another partition, and running it from there produces no such problems.
In any case, I am in the process of testing BFQ io governor and although not yet conclusive, things seem to work better.
Offline
I think I found the culprit - it's cairo-dock. Almost every time this happened, conky shows CPU usage of cairo-dock process to 350% on both cores.
What could be making cairo-dock doing that?
Offline
This post may end up deleted, but it's just unbearable: If you would have taken the advice I gave in the very first response in this thread, you would have spotted that problem instantly. Instead you wasted everyone's time and effort. Now you want more help? Good luck with that.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
And I have taken your advice and reported my finding in the post directly under yours. It DID NOT produce any usable observations. htop did not show what conky is showing.
Offline
I believe I finally found the cause of this behaviour.
In parallel to this system update, I also moved from Compiz to OpenBox. OpenBox takes cue of its autostart programs from three different sources (while compiz only from one of them).
It turned out, that cairo-dock had automatically installed an autostart cue in one of the sources compiz ignored. However, once I run OpenBox, it resulted in running two cairo-dock instances one on top of another.
This was visually undetectable, but cause the above problem.
Removing one of those instances seems to have solved.
Offline