FC20.
I ran yum -y update. After all the files were downloaded, the delta processing started. From there on, all the way through to the end of installation and cleanup, cpu was 99.99% taken up by the update process, and the entire desktop became unresponsive. I was unable to switch display windows, of which I had 6.
The update had downloaded a total of 161MB, for a total of about 30 updates, most of them wine related.
The machine is a dual core Intel running at 2.4GHz, with 4GB ram.
On Fri, 27 Jun 2014 17:02:20 -0600, JD wrote:
FC20.
I ran yum -y update. After all the files were downloaded, the delta processing started. From there on, all the way through to the end of installation and cleanup, cpu was 99.99% taken up by the update process, and the entire desktop became unresponsive. I was unable to switch display windows, of which I had 6.
The update had downloaded a total of 161MB, for a total of about 30 updates, most of them wine related.
The machine is a dual core Intel running at 2.4GHz, with 4GB ram.
CPU speed and 99% usage shouldn't be the problem here. Rather a bottleneck related to massive I/O and slow storage? Or an odd case of heavy memory usage that lead to swapping.
On Sat, Jun 28, 2014 at 3:18 AM, Michael Schwendt mschwendt@gmail.com wrote:
On Fri, 27 Jun 2014 17:02:20 -0600, JD wrote:
FC20.
I ran yum -y update. After all the files were downloaded, the delta processing started. From there on, all the way through to the end of installation and cleanup, cpu was 99.99% taken up by the update process, and the entire desktop became unresponsive. I was unable to switch display windows, of which I had 6.
The update had downloaded a total of 161MB, for a total of about 30 updates, most of them wine related.
The machine is a dual core Intel running at 2.4GHz, with 4GB ram.
CPU speed and 99% usage shouldn't be the problem here. Rather a bottleneck related to massive I/O and slow storage? Or an odd case of heavy memory usage that lead to swapping.
Heavy I/O should at most create an I/O bottleneck, since a process waiting either for free buffer of waiting for I/O completion does not consume cpu, as it is put to sleep until awakened by a signal that the requested buffer is available, or the I/O completed. The next time I do an update, I will also run top and iotop and take periodic screen snapshots and will upload the images to a public storage and provide the URL for all to see.
On 06/28/14 12:43, JD wrote:
On Sat, Jun 28, 2014 at 3:18 AM, Michael Schwendt mschwendt@gmail.com wrote:
On Fri, 27 Jun 2014 17:02:20 -0600, JD wrote:
<<<>>>
and the entire desktop became unresponsive. I was unable to switch display windows, of which I had 6.
<>
The next time I do an update, I will also run top and iotop and take periodic screen snapshots and will upload the images to a public storage and provide the URL for all to see.
how do you expect to do such if above from your first post is occurring?
unresponsive _is_/_may_be_ unresponsive even if just 3 windows are open, yumex - top - iotop.
just curious. :-)
On Sat, Jun 28, 2014 at 4:19 PM, g geleem@bellsouth.net wrote:
On 06/28/14 12:43, JD wrote:
On Sat, Jun 28, 2014 at 3:18 AM, Michael Schwendt mschwendt@gmail.com wrote:
On Fri, 27 Jun 2014 17:02:20 -0600, JD wrote:
<<<>>>
and the entire desktop became unresponsive. I was unable
to switch display windows, of which I had 6.
<>
The next time I do an update, I will also run top and iotop and take periodic screen snapshots and will upload the images to a public storage and provide the URL for all to see.
how do you expect to do such if above from your first post is occurring?
unresponsive _is_/_may_be_ unresponsive even if just 3 windows are open, yumex - top - iotop.
just curious. :-)
--
Very valid question. The gui desktop becomes unresponsive. But strangely enough if I have say 2 gnome terminals open in a workspace, then I am indeed able to issue commands in the gnome-terminal that is not running yum update. Thus I will set up 4 gnome terminals on a desktop workspace. 1 will run yum, 2 will run top, 3 will run iotop and in 4 I will issue the command /usr/bin/gnome-screenshot -f /tmp/screen.jpg
On 06/28/14 19:54, JD wrote: <>
Very valid question.
thank you. ;-)
The gui desktop becomes unresponsive. But strangely enough if I have say 2 gnome terminals open in a workspace, then I am indeed able to issue commands in the gnome-terminal that is not running yum update. Thus I will set up 4 gnome terminals on a desktop workspace. 1 will run yum, 2 will run top, 3 will run iotop and in 4 I will issue the command /usr/bin/gnome-screenshot -f /tmp/screen.jpg
ok.
you had me wondering. :-D
sounds more logical.
much luck.
On Sat, 2014-06-28 at 18:54 -0600, JD wrote:
Thus I will set up 4 gnome terminals on a desktop workspace. 1 will run yum, 2 will run top, 3 will run iotop and in 4 I will issue the command /usr/bin/gnome-screenshot -f /tmp/screen.jpg
Might be easier to just pipe the text output from "top" to a file, a few times, and post those text files.
On Sun, Jun 29, 2014 at 1:31 AM, Tim ignored_mailbox@yahoo.com.au wrote:
On Sat, 2014-06-28 at 18:54 -0600, JD wrote:
Thus I will set up 4 gnome terminals on a desktop workspace. 1 will run yum, 2 will run top, 3 will run iotop and in 4 I will issue the command /usr/bin/gnome-screenshot -f /tmp/screen.jpg
Might be easier to just pipe the text output from "top" to a file, a few times, and post those text files.
that would contain cursor postioning codes which would really mess up the text file. As the adage says: A picture tells a thousand words.
Tim:
Might be easier to just pipe the text output from "top" to a file, a few times, and post those text files.
JD:
that would contain cursor postioning codes which would really mess up the text file. As the adage says: A picture tells a thousand words.
Hmm, I thought top had an option for a plain text output, but I can't see anything suitable in the man file. Maybe, long ago, when I did something like that, I just did "less -R output" ("output" being the top text file).
On 14-06-30 09:19:13, Tim wrote: ...
Hmm, I thought top had an option for a plain text output, but I can't see anything suitable in the man file. ...
-b
top -bn4 >topout
On 06/30/14 10:59, Tony Nelson wrote:
On 14-06-30 09:19:13, Tim wrote: ...
Hmm, I thought top had an option for a plain text output, but I can't see anything suitable in the man file. ...
-b
top -bn4 >topout
i guess i should have run a fresh download before posting. :-)
On 06/30/14 08:19, Tim wrote: <>
Hmm, I thought top had an option for a plain text output, but I can't see anything suitable in the man file. Maybe, long ago, when I did something like that, I just did "less -R output" ("output" being the top text file).
are you thinking of:
-b : Batch mode operation Starts top in 'Batch mode', which could be useful for sending output from top to other programs or to a file. In this mode, top will not accept input and runs until the iterations limit you've set with the '-n' command-line option or until killed.
-n : Number of iterations limit as: -n number Specifies the maximum number of iterations, or frames, top should produce before ending.
Tim:
Hmm, I thought top had an option for a plain text output, but I can't see anything suitable in the man file. Maybe, long ago, when I did something like that, I just did "less -R output" ("output" being the top text file).
g:
are you thinking of:
-b : Batch mode operation Starts top in 'Batch mode', which could be useful for sending output from top to other programs or to a file. In this mode, top will not accept input and runs until the iterations limit you've set with the '-n' command-line option or until killed. -n : Number of iterations limit as: -n number Specifies the maximum number of iterations, or frames, top should produce before ending.
Yes, that's it. When I looked at the man file, a little while ago, it just didn't jump out at me as "batch" mode being a cooked output.
As far as the original poster was concerned, I was thinking that getting a text file created would be less of a problem than taking a screenshot, on a system where the CPU was being pegged. It can also be easier to post pasted text to a mailing list, than deal with uploading and linking to an image, somewhere.
hi Tim,
On 06/30/14 15:41, Tim wrote:
Tim:
<>
Yes, that's it. When I looked at the man file, a little while ago, it just didn't jump out at me as "batch" mode being a cooked output.
do not feel bad. my 'chemo brain' did not recall what i had used several years ago. i had to do a search for 'file' to find it. ;-)
As far as the original poster was concerned, I was thinking that getting a text file created would be less of a problem than taking a screenshot, on a system where the CPU was being pegged. It can also be easier to post pasted text to a mailing list, than deal with uploading and linking to an image, somewhere.
i agree, text is better than an image. tho, i believe, uploading to a site, then posting a link is better than paste in post or an attachment. especially when info is more that a few lines.
attachments can be removed, but a paste can not. and there are too many who do not know how to 'chop wood' when they reply. lol.
Tim:
As far as the original poster was concerned, I was thinking that getting a text file created would be less of a problem than taking a screenshot, on a system where the CPU was being pegged. It can also be easier to post pasted text to a mailing list, than deal with uploading and linking to an image, somewhere.
g:
i agree, text is better than an image. tho, i believe, uploading to a site, then posting a link is better than paste in post or an attachment. especially when info is more that a few lines.
If it's just the usual 80x24 lines of text, not really an issue. But this is one point where a text dump can be better, a graphic dump would only be what's shown on screen, a text dump can be a lot longer. Though I doubt the original poster's situation would be down to some application 50 items down the list.
attachments can be removed, but a paste can not. and there are too many who do not know how to 'chop wood' when they reply. lol.
Either can be deleted when the next person replies, trouble is that too many do not. It snowballs badly with long threads, wasting my bandwidth and storage space, and thousands of others, not to mention the server sending it to everyone.
I wish I could remove attachments. Evolution supposedly offers the feature, but it just delete the entire message. I've had other clients that could do it, before I started using Linux, but haven't seen one since. It can be a right pain when someone decides to email you several megabytes of attached files, and you need to keep the mail, but don't need to keep the files. It really clogs things up. You have to resort to kludges like forwarding the message, minus the extra bits.
-
g -
JD -
Michael Schwendt -
Tim -
Tony Nelson