View previous topic :: View next topic |
Author |
Message |
NathanZachary Moderator
Joined: 30 Jan 2007 Posts: 2598
|
Posted: Thu Jul 27, 2017 3:44 pm Post subject: X at 100% of 1 core when using SSH |
|
|
Hello,
I've found that when I use SSH to connect to one of my servers, and am running system updates on the server, the following process will spike to 100% of one processor core:
Code: | /usr/bin/X -nolisten tcp :0 -auth /home/$USER/.serverauth.$# |
Has anyone else seen similar behaviour?
Thanks!
Cheers,
Nathan Zachary _________________ “Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio---
Last edited by NathanZachary on Thu Jul 27, 2017 4:21 pm; edited 1 time in total |
|
Back to top |
|
|
Telemin l33t
Joined: 25 Aug 2005 Posts: 753 Location: Glasgow, UK
|
Posted: Thu Jul 27, 2017 4:20 pm Post subject: |
|
|
I have not seen that exact behaviour from X, but certainly for other applications that are spinlocked waiting for a resource. Does that X process actually work correctly or is it continually trying to acquire some resource?
-Telemin- _________________ The Geek formerly known as -Freestyling-
When you feel your problem has been solved please add [Solved] to the topic title.
Please adopt an unanswered post |
|
Back to top |
|
|
NathanZachary Moderator
Joined: 30 Jan 2007 Posts: 2598
|
Posted: Thu Jul 27, 2017 4:23 pm Post subject: |
|
|
It works properly, but makes any other task that I'm working on slow. I'm thinking that it may be related to compiling on the remote server instead of just the SSH connection, though. I don't see the problem when I'm just connected to a remote host via SSH. Interesting, and maybe related to framebuffer? _________________ “Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio--- |
|
Back to top |
|
|
Telemin l33t
Joined: 25 Aug 2005 Posts: 753 Location: Glasgow, UK
|
Posted: Thu Jul 27, 2017 4:39 pm Post subject: |
|
|
Okay, Just to be clear, is that X process running on the remote server or on the local machine? I was assuming so far that you are doing X-forwarding , there are all sorts of potential bottlenecks to be considered there. If it is your local X-server that is just plain weird.
If it is an X-forwarding setup you can try running your updater script in a screen and then detach, that may help if the software renderer is struggling to keep up with the wall of text. Otherwise can you describe exactly what it is you are doing and maybe I can reproduce.
-Telemin- _________________ The Geek formerly known as -Freestyling-
When you feel your problem has been solved please add [Solved] to the topic title.
Please adopt an unanswered post |
|
Back to top |
|
|
NathanZachary Moderator
Joined: 30 Jan 2007 Posts: 2598
|
Posted: Thu Jul 27, 2017 4:44 pm Post subject: |
|
|
Ah, now I understand your question. No, this is the X server on my local machine and I'm not X-forwarding.
Strange, eh? _________________ “Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio--- |
|
Back to top |
|
|
Telemin l33t
Joined: 25 Aug 2005 Posts: 753 Location: Glasgow, UK
|
Posted: Thu Jul 27, 2017 4:56 pm Post subject: |
|
|
Yes, that is a bit peculiar. But I tested my wall of text theory and I think it is still the issue:
Code: |
dd if=/dev/urandom of=/dev/shm/test.img bs=1M count=1000
cat /dev/shm/test.img
|
In a urxvt terminal, and X suddenly has 100% cpu usage.
If I do the same in a screen and detach or even just change to a different tab cpu usage drops back to nothing. Does this sound familiar?
Interestingly Xterm, while still heavily using cpu seems to be much more efficient/sensible and only consumes 65% at maximum.
Edit: Simply minimizing the window or hiding it behind another doesn't have the same effect as screen, I think X is simply not that clever...
-Telemin- _________________ The Geek formerly known as -Freestyling-
When you feel your problem has been solved please add [Solved] to the topic title.
Please adopt an unanswered post |
|
Back to top |
|
|
NathanZachary Moderator
Joined: 30 Jan 2007 Posts: 2598
|
Posted: Thu Jul 27, 2017 5:55 pm Post subject: |
|
|
That is indeed the problem. I tried a similar test involving a wall of text, and that's what caused the spike. When I did the same wall of text in a screen session and detatched from it, the CPU usage on my local machine dropped to normal. So, even though it's on the remote host, it seems like the X CPU spike is due to the wall of text during emerge. _________________ “Truth, like infinity, is to be forever approached but never reached.” --Jean Ayres (1972)
---avatar cropped from =AimanStudio--- |
|
Back to top |
|
|
Telemin l33t
Joined: 25 Aug 2005 Posts: 753 Location: Glasgow, UK
|
Posted: Thu Jul 27, 2017 9:31 pm Post subject: |
|
|
Well I'm glad you have a workaround. I guess it qualifies as yet another special pathology of X11 and lets hope Wayland does things in a more sensible fashion when/if it finally arrives
-Telemin- _________________ The Geek formerly known as -Freestyling-
When you feel your problem has been solved please add [Solved] to the topic title.
Please adopt an unanswered post |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Thu Jul 27, 2017 11:09 pm Post subject: |
|
|
It's not really X's fault, some programs are just awful at rendering text efficiently and X gets the blame since it's being given orders to blit a million characters one at a time. The GNOME/KDE terminals are the worst by a mile. If yours has an option to limit the redraw framerate (I know xterm and st both do) turn it on.
Or better yet, EMERGE_DEFAULT_OPTS=--quiet-build. |
|
Back to top |
|
|
Telemin l33t
Joined: 25 Aug 2005 Posts: 753 Location: Glasgow, UK
|
Posted: Fri Jul 28, 2017 10:09 am Post subject: |
|
|
Ant P. wrote: | It's not really X's fault, some programs are just awful at rendering text efficiently and X gets the blame since it's being given orders to blit a million characters one at a time. The GNOME/KDE terminals are the worst by a mile. If yours has an option to limit the redraw framerate (I know xterm and st both do) turn it on. |
Thanks that's good to know. I can't find one for urxvt but I shall ask the mailing list.
Thanks,
-Telemin- _________________ The Geek formerly known as -Freestyling-
When you feel your problem has been solved please add [Solved] to the topic title.
Please adopt an unanswered post |
|
Back to top |
|
|
|