2nd Update on: why is my Linux so damn slow?
On Sat, Feb 12, 2011 14:51:25 PM +0100, Marco Fioretti (mfiore...@nexaima.net) wrote: when I upgraded from Fedora 12 to Fedora 14, about twenty days ago, the system (which wasn't doing really well even before the upgrade) became almost unusable. Things went better, then worse, now they are much better, almost good. Short summary: firefox + flash + nvidia = nightmare, while kde/gnome quirks make things more... interesting. Details at http://freesoftware.zona-m.net/update-on-why-is-my-linux-so-damn-slow/ and in posts linked from there. Marco -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Update on: why is my Linux so damn slow?
On Sun, 2011-02-13 at 08:26 +0100, M. Fioretti wrote: On Sun, Feb 13, 2011 08:17:00 AM +0100, Marco Fioretti (mfiore...@nexaima.net) wrote: Almost surely, today I won't be able to try and report about the latest suggestions. I have to leave with family in a few minutes, for stuff planned weeks ago. So if you don't hear from me again before a couple of days, it's not because I've ran again from Linux or Fedora. sorry, I meant ran away, not ran again Actually, you meant run away (I ran away, I have run away). poc -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, 2011-02-12 at 21:56 +0100, M. Fioretti wrote: Man, it would be really ironic if after years making fun of Windows because it needs defragmenting to run faster, it turns out you have to defragment Firefox to keep Linux fast... Though, that'd be a case of bagging Firefox, not Linux. Firefox can be a pig on any computer, especially when preferences are set for long histories and large caches. Firefox has to parse it all, and it doesn't appear to be very efficient at it. Firefox and Flash are another thing for really sucking up the CPU cycles. -- [tim@localhost ~]$ uname -r 2.6.27.25-78.2.56.fc9.i686 Don't send private replies to my address, the mailbox is ignored. I read messages from the public lists. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Update on: why is my Linux so damn slow?
On 13 February 2011 07:17, M. Fioretti mfiore...@nexaima.net wrote: secondly, I have to report that a simple vacuuming of the sqlite databases of Firefox as explained here: http://www.gettingclever.com/2008/06/vacuum-your-firefox-3.html is enough to make a real difference. I tried this and the Firefox performance also improved for me. It was not a dramatic improvement but still, as it is so easy, I will probably do the vacuuming once a month or so. Nice trick, thanks! -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
why is my Linux so damn slow?
Greetings, when I upgraded from Fedora 12 to Fedora 14, about twenty days ago, the system (which wasn't doing really well even before the upgrade) became almost unusable. The problem is, very likely, upstream of Fedora, but I would like to understand where exactly is and if/how Fedora in some way amplifies it. I've posted all details here: http://freesoftware.zona-m.net/help-request-why-is-my-linux-so-damn-slow TIA, Marco -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On 02/12/2011 03:51 PM, M. Fioretti wrote: Greetings, when I upgraded from Fedora 12 to Fedora 14, about twenty days ago, the system (which wasn't doing really well even before the upgrade) became almost unusable. The problem is, very likely, upstream of IMHO, first step is a clean install ... and afterwards you can investigate whats going on because you are on a known, stable grounds. Adrian Fedora, but I would like to understand where exactly is and if/how Fedora in some way amplifies it. I've posted all details here: http://freesoftware.zona-m.net/help-request-why-is-my-linux-so-damn-slow TIA, Marco smime.p7s Description: S/MIME Cryptographic Signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
RE: why is my Linux so damn slow?
when I upgraded from Fedora 12 to Fedora 14, about twenty days ago, the system (which wasn't doing really well even before the upgrade) became almost unusable. Weird problems often have a hardware issue behind them. There are many things to check. Some are easier than others: From the desktop, open the program SystemAdministrationDisk Utility. Select each of your hard drives in the list on the left, and then click the Smart Data button. In the upper part of the window, look for a Bad Sector count, and Overall Assessment of the drive. Any problems? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 16:31:58 PM +0200, Adrian Sevcenco (adrian.sevce...@cern.ch) wrote: when I upgraded from Fedora 12 to Fedora 14, about twenty days ago, the system (which wasn't doing really well even before the upgrade) became almost unusable. The problem is, very likely, upstream of IMHO, first step is a clean install ... and afterwards you can investigate whats going on because you are on a known, stable grounds. Adrian, I understand the rationale for this suggestion. The reason why I haven't done this (yet) is that (see above and in the article) I already had ALL the same problems, just a bit smaller, with FC12, which was a clean install, with all updates applied etc etc. In other words, the situation with FC12 was just barely tolerable, with the upgrade it simply degraded more. I am trying to gather as much info as possible to understand what is the fastest, or at least more likely to succeed with the smallest number of reinstalls way forward. For sure, I can't go on like this, and I will be forced to reformat/reinstall from scratch if I don't find a solution. But at that point, I'll directly try another distro first, simply because my feeling right now is that a clean install of FC14 (or 15) wouldn't do much. One of the reasons why I took the time to make an article online about this is the hope to find somebody that says hey, I have the same hardware as you, and it runs real fast with distro XYZ Marco -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
M. Fioretti wrote: Greetings, when I upgraded from Fedora 12 to Fedora 14, about twenty days ago, the system (which wasn't doing really well even before the upgrade) became almost unusable. The problem is, very likely, upstream of Fedora, but I would like to understand where exactly is and if/how Fedora in some way amplifies it. I've posted all details here: http://freesoftware.zona-m.net/help-request-why-is-my-linux-so-damn-slow TIA, Marco Just to convince us all that it's not some subtle hardware problem, can you make a FC14 live cd and boot from that, and then see if you still get the same terrible performance? Cheers, Terry -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 15:56:31 PM +, T. Horsnell (t...@mrc-lmb.cam.ac.uk) wrote: Just to convince us all that it's not some subtle hardware problem, can you make a FC14 live cd and boot from that, and then see if you still get the same terrible performance? Not right now (can't move from home right now, no blank dvds/cds around). However, I HAD tried a live CD before install (now borrowed from a friend) and it was just as slow, if not slower. Back then I didn't bother too much for slowness, thinking once installed for real it will go faster, because I only wanted to be sure that it would recognize all the hardware. Marco -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
[Fwd: Re: why is my Linux so damn slow?]
(Sorry - forgot to include the list..) ---BeginMessage--- M. Fioretti wrote: On Sat, Feb 12, 2011 15:56:31 PM +, T. Horsnell (t...@mrc-lmb.cam.ac.uk) wrote: Just to convince us all that it's not some subtle hardware problem, can you make a FC14 live cd and boot from that, and then see if you still get the same terrible performance? Not right now (can't move from home right now, no blank dvds/cds around). However, I HAD tried a live CD before install (now borrowed from a friend) and it was just as slow, if not slower. Back then I didn't bother too much for slowness, thinking once installed for real it will go faster, because I only wanted to be sure that it would recognize all the hardware. Marco My experience with the live systems is that stuff is slower to boot and programs are slower to start up (obviously - the CD/DVD drive is much than a hard drive) but once a program is in memory, it functions just as fast as with a disk-based system. Do you have any mem/disk errors logged in /var/log/messages? Are you able to run a memory test? (eg memtest86) T. ---End Message--- -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
--- On Sat, 2/12/11, M. Fioretti mfiore...@nexaima.net wrote: npviewer is causing some type of problem :( [12032.976089] npviewer.bin[2721]: segfault at 0 ip 00f7ced1 sp ff8a60c0 error 4 in libflashplayer.so[bdd000+b2e000] [12041.569570] npviewer.bin[5297]: segfault at f74bd0e0 ip 468527c6 sp ffd76248 error 4 in libc-2.12.90.so[467d7000+18d000] [13779.830969] npviewer.bin[5331]: segfault at 0 ip 00ca9ed1 sp fff96a40 error 4 in libflashplayer.so[90a000+b2e000] [16384.558119] npviewer.bin[6218]: segfault at 418 ip 006b9c86 sp ffd63c98 error 6 in libflashplayer.so[46a000+b2e000] [16512.848263] IPv6 over IPv4 tunneling driver [16512.848942] sit0: Disabled Privacy Extensions [18164.672564] lo: Disabled Privacy Extensions -- This along with nspluginwrapper the flash player from adobe are some culprits I see causing trouble :( I guess I am lucky to not get some of your troubles. You may also want to post output of # tail -f /var/log/messages to see if something else is there. Also check how many ``services'' that are needed are running at boot time. Regards, Antonio -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 10:52:37 AM -0600, Rick Sewill (rsew...@gmail.com) wrote: http://freesoftware.zona-m.net/help-request-why-is-my-linux-so-damn-slow You have a very interesting problem. that's the same thing my wife usually tells herself when looking at me :-) May I ask, what is the purpose of this system? Is it a server? One reason it has so much memory is that it was my intention to also do some video editing with it (but I haven't gotten to that yet), and re-ordering, geotagging etc, lots of digital pictures. Another is that sometimes, I have to do lots of heavy perl- or shell processing on huge (hundreds of MBytes) amount of text in the background, so I wanted to be sure that this wouldn't slow me down while writing, etc.. Apart from that, this is an office computer. Most of the time, the usage is what I already described in the article: web browsing, openoffice, email... The only thing I forgot (sorry) to say there is that sometimes there are other family members leaving their accounts on with Firefox open. They reported the same problems, there's nothing (so far) account-specific. The firewall is the default FC14 config no service accessible from outside. output of iptables -L -v is pasted at the bottom. In runlevel 3, things go fine, but I need GUIs here. Firefox IS one big cause of the slowness. It would be interesting to know why the magnitude of the problem increased so much upgrading to FC 14. Turning networking off in runlevel 5 (service network stop) doesn't seem to make a difference, in and by itself. Oh, and when I said the system is slow even if firefox isn't running I meant that I *had* run killall firefox. I think between this and other earlier messages I have already answered all questions from Rick. If not, please be patient and remember me. Thanks again, folks! Marco [root@polaris ~]# iptables -L -v Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 111K 93M ACCEPT all -- anyany anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- anyany anywhere anywhere 5 300 ACCEPT all -- lo any anywhere anywhere 0 0 ACCEPT tcp -- anyany anywhere anywhere state NEW tcp dpt:https 0 0 ACCEPT tcp -- anyany anywhere anywhere state NEW tcp dpt:ssh 68 10917 REJECT all -- anyany anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 REJECT all -- anyany anywhere anywhere reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT 111K packets, 20M bytes) pkts bytes target prot opt in out source destination -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 11:01:49 AM -0600, Rick Sewill (rsew...@gmail.com) wrote: What devices are connected to your system? Perhaps a Linux driver, for a device is having problems. Perhaps a device is generating lots of interrupts. Can you disconnect any devices and see if the slowness goes away? besides hard drive and DVD burner there are only Logitech webcam, wheelmouse and earphone microphone, but everything is plugged in the back which is not really accessible without moving furniture. I'll do that if needed, but isn't a way to check for those interrupts from the prompt? Thanks, Marco -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Saturday, February 12, 2011 12:19:33 pm M. Fioretti wrote: besides hard drive and DVD burner there are only Logitech webcam, wheelmouse and earphone microphone, but everything is plugged in the back which is not really accessible without moving furniture. I'll do that if needed, but isn't a way to check for those interrupts from the prompt? Let's see if iowaits are you issue. Install the sysstat package (yum install sysstat) and run: iostat -x 1 (this gives extended information on the disk, and updates at one second intervals) The number to look at is 'await' times, expressed in milliseconds. If those numbers are high, it's something with your drive. Also, if you run 'top' what does it show? I saw an F13 system brought to its knees due to a WD EADS series 'green' drive triggering insane awaits of multiple thousands of milliseconds, and system load averages in excess of 20. The command that reliably triggered the behavior was a simple 'yum update' from the command line, or the automatic packagekit update process; load averages went through the roof, and the system slowed to a slow crawl. Replaced the WD EADS series drive with a Seagate of the same capacity, and the problem went away. Now, in this specific case, the EADS drive was one half of a RAID-1 mirror, where the other half was a Seagate; the EADS drives and RAID don't get along. But others have reported performance issues with these drives not in a RAID configuration, with recent kernels; older kernels seemed to work better. I'd check that even though the WD2500JS-41MVB1 drive is a 'Caviar Blue' and not a Green drive. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 12:55:16 PM -0500, Lamar Owen (lo...@pari.edu) wrote: On Saturday, February 12, 2011 12:19:33 pm M. Fioretti wrote: besides hard drive and DVD burner there are only Logitech webcam, wheelmouse and earphone microphone, but everything is plugged in the back which is not really accessible without moving furniture. I'll do that if needed, but isn't a way to check for those interrupts from the prompt? Let's see if iowaits are you issue. Install the sysstat package (yum install sysstat) and run: iostat -x 1 here it is, thanks for the tip. When it isn't zero, the await column gives anything from 27.36 to 35.78 (last line) to 5 (I have already posted top output in a comment to the web page): [root@polaris ~]# iostat -x 1 | egrep -i 'device|sda' Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.8212.441.852.04 101.53 113.1355.19 0.11 27.36 4.15 1.62 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 7.000.007.00 0.0096.0013.71 0.057.29 7.29 5.10 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 2.000.005.00 0.0040.00 8.00 0.047.00 7.00 3.50 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.0017.000.00 21.00 0.00 272.0012.95 0.136.33 5.76 12.10 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.0015.000.00 11.00 0.00 192.0017.45 0.065.82 5.27 5.80 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.00
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 19:03:56 PM +0100, Marco Fioretti (mfiore...@nexaima.net) wrote: On Sat, Feb 12, 2011 12:55:16 PM -0500, Lamar Owen (lo...@pari.edu) wrote: On Saturday, February 12, 2011 12:19:33 pm M. Fioretti wrote: besides hard drive and DVD burner there are only Logitech webcam, wheelmouse and earphone microphone, but everything is plugged in the back which is not really accessible without moving furniture. I'll do that if needed, but isn't a way to check for those interrupts from the prompt? Let's see if iowaits are you issue. Install the sysstat package (yum install sysstat) and run: iostat -x 1 here it is, thanks for the tip. When it isn't zero, the await column gives anything from 27.36 to 35.78 (last line) to 5 (I have already posted top output in a comment to the web page): [root@polaris ~]# iostat -x 1 | egrep -i 'device|sda' Sorry, of course that's only the part of the story about sda. here is one complete run of iostat: Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 5.000.005.00 0.0064.0012.80 0.036.00 6.00 3.00 dm-0 0.00 0.000.008.00 0.0064.00 8.00 0.044.38 3.75 3.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 other runs show all null values for dm-0 / dm-1, or values similar to these Marco -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Saturday, February 12, 2011 12:09:34 pm M. Fioretti wrote: On Sat, Feb 12, 2011 19:03:56 PM +0100, Marco Fioretti (mfiore...@nexaima.net) wrote: On Sat, Feb 12, 2011 12:55:16 PM -0500, Lamar Owen (lo...@pari.edu) wrote: On Saturday, February 12, 2011 12:19:33 pm M. Fioretti wrote: besides hard drive and DVD burner there are only Logitech webcam, wheelmouse and earphone microphone, but everything is plugged in the back which is not really accessible without moving furniture. I'll do that if needed, but isn't a way to check for those interrupts from the prompt? Let's see if iowaits are you issue. Install the sysstat package (yum install sysstat) and run: iostat -x 1 here it is, thanks for the tip. When it isn't zero, the await column gives anything from 27.36 to 35.78 (last line) to 5 (I have already posted top output in a comment to the web page): [root@polaris ~]# iostat -x 1 | egrep -i 'device|sda' Sorry, of course that's only the part of the story about sda. here is one complete run of iostat: Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 5.000.00 5.00 0.0064.0012.80 0.036.00 6.00 3.00 dm-0 0.00 0.000.008.00 0.0064.00 8.00 0.04 4.38 3.75 3.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 other runs show all null values for dm-0 / dm-1, or values similar to these Marco Could you show the output of iostat -x 1, not iostat -x 1 | egrep -i 'device|sda' please? On my system, when I do iostat -x 1 I get avg-cpu besides drive information. avg-cpu: %user %nice %system %iowait %steal %idle 5.050.004.040.000.00 90.91 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 It might help to see the avg-cpu. If we are lucky, either the %user or %system or ... will show high cpu usage. signature.asc Description: This is a digitally signed message part. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Saturday, February 12, 2011 12:27:55 pm Rick Sewill wrote: On Saturday, February 12, 2011 12:09:34 pm M. Fioretti wrote: On Sat, Feb 12, 2011 19:03:56 PM +0100, Marco Fioretti (mfiore...@nexaima.net) wrote: On Sat, Feb 12, 2011 12:55:16 PM -0500, Lamar Owen (lo...@pari.edu) wrote: On Saturday, February 12, 2011 12:19:33 pm M. Fioretti wrote: besides hard drive and DVD burner there are only Logitech webcam, wheelmouse and earphone microphone, but everything is plugged in the back which is not really accessible without moving furniture. I'll do that if needed, but isn't a way to check for those interrupts from the prompt? Let's see if iowaits are you issue. Install the sysstat package (yum install sysstat) and run: iostat -x 1 here it is, thanks for the tip. When it isn't zero, the await column gives anything from 27.36 to 35.78 (last line) to 5 (I have already posted top output in a comment to the web page): [root@polaris ~]# iostat -x 1 | egrep -i 'device|sda' Sorry, of course that's only the part of the story about sda. here is one complete run of iostat: Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 5.00 0.00 5.00 0.0064.0012.80 0.036.00 6.00 3.00 dm-0 0.00 0.000.008.00 0.0064.00 8.00 0.04 4.38 3.75 3.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 other runs show all null values for dm-0 / dm-1, or values similar to these Marco Could you show the output of iostat -x 1, not iostat -x 1 | egrep -i 'device|sda' please? On my system, when I do iostat -x 1 I get avg-cpu besides drive information. avg-cpu: %user %nice %system %iowait %steal %idle 5.050.004.040.000.00 90.91 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 It might help to see the avg-cpu. If we are lucky, either the %user or %system or ... will show high cpu usage. Another question please...if it's spurious interrupts, I found the device file, /proc/interrupts, which has a row for Spurious interrupts. We haven't demonstrated the problem is interrupt related. Can we try to isolate or rule out this as a problem please? Could you show us the output of twice, the second time a few seconds after the first time so we can see if any interrupt number changes fast. more /proc/interrupts ... more /proc/interrupts Can people suggest any information/files in /proc which might help us? I assume there is a periodic hardware clock interrupt for your CPU. Can we find out this clock interrupt rate somewhere? signature.asc Description: This is a digitally signed message part. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 12:27:55 PM -0600, Rick Sewill (rsew...@gmail.com) wrote: Could you show the output of iostat -x 1, not iostat -x 1 | egrep -i 'device|sda' please? Sure, sorry, here you go (this is with Firefox open, right now) Linux 2.6.35.10-74.fc14.x86_64 (polaris.localdomain)02/12/2011 _x86_64_(2 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 28.930.003.230.690.00 67.15 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.7612.231.722.0796.94 111.7654.97 0.10 26.58 4.13 1.57 dm-0 0.00 0.002.45 13.9896.65 111.7612.68 2.18 132.68 0.95 1.57 dm-1 0.00 0.000.010.00 0.09 0.00 8.00 0.005.45 3.18 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 48.760.000.500.000.00 50.75 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-0 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 16.580.001.010.000.00 82.41 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.00 19.00 0.00 152.00 8.00 0.010.79 0.11 0.20 dm-0 0.00 0.000.00 19.00 0.00 152.00 8.00 0.010.79 0.11 0.20 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 4.460.000.994.950.00 89.60 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.0027.000.009.00 0.00 272.0030.22 0.077.67 7.67 6.90 dm-0 0.00 0.000.00 34.00 0.00 272.00 8.00 0.102.82 2.03 6.90 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 4.500.001.000.000.00 94.50 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-0 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 12.870.000.990.000.00 86.14 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-0 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 39.300.000.500.000.00 60.20 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-0 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On 02/12/2011 07:53 AM, M. Fioretti wrote: On Sat, Feb 12, 2011 15:25:54 PM +, Alan Cox (a...@lxorguk.ukuu.org.uk) wrote: There are lots of other things it could be, unfortunately you've not provided any really useful information on the machine, you've not provided any dumps of stuff that would be useful I have now, in comments to the article. I certainly did not expect to get the complete answer in one step (as I wrote at the end of that page), I wrote everything I thought useful in that page. And I had put little details like which X server is being run in that page since the beginning, in the form I thought it could be enough, ie attaching the installed RPM packages. And I also _acknowledged_ right there that it couldn't be enough so please tell me what other inputs do you need, thanks. On an 8GB box with Intel onboard video even Gnome is usable so something is definitely wrong in your specific setup exactly my point :-) I am sure a big part of the problem is Firefox+Flash, but can that be the WHOLE problem? As I wrote in the article, it's not like killing Firefox (while it does improve things) solves everything. Dmesg output is pasted below. Boot, reboot or not it makes no difference. let it go ten minutes, and it starts behaving like that. Thanks again for your quick support! Just ask for more tests if needed. Marco .Snip.. I am on F13, with latest updates as of yeaterday. Even when load fact is 0.3 or 0.5, opening most gui applications takes up to 30 seconds and on some occasions, a little more. Applications like OpenOffice, ktorrent, Seamonkey, Amarok...etc. Laptop has 7200 rpm drive (ext3 fs), 2GB ram. This is the case even right after booting. I do recall that things were noticeably quicker to start on much older redhat releases, like redhat 3.0, and even on linux'es prior to redhat. But then the GUI apps at that time might not have been so incredibly bloated as they are today. For an amusing commentary in song, watch http://www.youtube.com/watch?v=d85p7JZXNy8 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 12:47:13 PM -0600, Rick Sewill (rsew...@gmail.com) wrote: Could you show us the output of twice, the second time a few seconds after the first time so we can see if any interrupt number changes fast. more /proc/interrupts here are two runs, 5/6 seconds apart: [root@polaris ~]# more /proc/interrupts CPU0 CPU1 0:136180 IO-APIC-edge timer 1: 0 2 IO-APIC-edge i8042 4: 0 2 IO-APIC-edge 7: 1 0 IO-APIC-edge parport0 8: 0 1 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 12: 0 4 IO-APIC-edge i8042 14: 0 0 IO-APIC-edge pata_amd 15: 0 0 IO-APIC-edge pata_amd 17: 0 2 IO-APIC-fasteoi firewire_ohci 20: 116972135 IO-APIC-fasteoi ohci_hcd:usb3, nvidia 21:947289 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel 22: 0 3 IO-APIC-fasteoi ehci_hcd:usb1 23: 252957 24 IO-APIC-fasteoi ohci_hcd:usb4 43: 449718 5490 PCI-MSI-edge ahci 44: 850242 23 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 12772218 13583547 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES:68964877547957 Rescheduling interrupts CAL: 8607 11701 Function call interrupts TLB: 43915 42920 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP:103103 Machine check polls ERR: 1 MIS: 0 [root@polaris ~]# [root@polaris ~]# more /proc/interrupts CPU0 CPU1 0:136180 IO-APIC-edge timer 1: 0 2 IO-APIC-edge i8042 4: 0 2 IO-APIC-edge 7: 1 0 IO-APIC-edge parport0 8: 0 1 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 12: 0 4 IO-APIC-edge i8042 14: 0 0 IO-APIC-edge pata_amd 15: 0 0 IO-APIC-edge pata_amd 17: 0 2 IO-APIC-fasteoi firewire_ohci 20: 116985135 IO-APIC-fasteoi ohci_hcd:usb3, nvidia 21:947289 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel 22: 0 3 IO-APIC-fasteoi ehci_hcd:usb1 23: 252957 24 IO-APIC-fasteoi ohci_hcd:usb4 43: 449809 5490 PCI-MSI-edge ahci 44: 850456 23 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 12774821 13585530 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES:68969747548786 Rescheduling interrupts CAL: 8608 11703 Function call interrupts TLB: 43919 42921 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP:103103 Machine check polls ERR: 1 MIS: 0 [root@polaris ~]# will try now to find out the clock interrupt rate. Thanks -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Saturday, February 12, 2011 12:43:53 pm M. Fioretti wrote: On Sat, Feb 12, 2011 12:27:55 PM -0600, Rick Sewill (rsew...@gmail.com) wrote: Could you show the output of iostat -x 1, not iostat -x 1 | egrep -i 'device|sda' please? Sure, sorry, here you go (this is with Firefox open, right now) Linux 2.6.35.10-74.fc14.x86_64 (polaris.localdomain) 02/12/2011 _x86_64_(2 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 28.930.003.230.690.00 67.15 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.7612.231.72 2.0796.94 111.7654.97 0.10 26.58 4.13 1.57 dm-0 0.00 0.002.45 13.9896.65 111.7612.68 2.18 132.68 0.95 1.57 dm-1 0.00 0.000.010.00 0.09 0.00 8.00 0.005.45 3.18 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 48.760.000.500.000.00 50.75 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.00 0.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-0 0.00 0.000.000.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 16.580.001.010.000.00 82.41 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.00 19.00 0.00 152.00 8.00 0.010.79 0.11 0.20 dm-0 0.00 0.000.00 19.00 0.00 152.00 8.00 0.01 0.79 0.11 0.20 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 4.460.000.994.950.00 89.60 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.0027.000.00 9.00 0.00 272.0030.22 0.077.67 7.67 6.90 dm-0 0.00 0.000.00 34.00 0.00 272.00 8.00 0.10 2.82 2.03 6.90 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 4.500.001.000.000.00 94.50 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.00 0.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-0 0.00 0.000.000.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 12.870.000.990.000.00 86.14 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.00 0.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-0 0.00 0.000.000.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 avg-cpu: %user %nice %system %iowait %steal %idle 39.300.000.500.000.00 60.20 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.000.00 0.00 0.00 0.00 0.00 0.000.00 0.00 0.00 dm-0 0.00 0.000.000.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.000.000.00 0.00 0.00 0.00 0.000.00 0.00 0.00 Is there any correlation between avg-cpu %user and Device sda wsec/s writes? Is there a burst of %user cpu activity followed by a burst of wsec/s writes? If the system is doing so little, I'd expect less %user cpu activity. Since the system is 2 CPU, does 48% means one cpu ran solid for a second? Someone help us...I know there is a command to show open files, lsof. Does that command include a way to find out disk activity per file or is there another command that can find out disk activity per file? I'm hoping, if we identify the file(s) with disk activity, we might identify the service/application/kernel feature that is hogging the cpu. signature.asc Description: This is a digitally signed message part. -- users mailing list
Re: why is my Linux so damn slow?
Rick Sewill rsewill at gmail.com writes: ... Someone help us...I know there is a command to show open files, lsof. Does that command include a way to find out disk activity per file or is there another command that can find out disk activity per file? I'm hoping, if we identify the file(s) with disk activity, we might identify the service/application/kernel feature that is hogging the cpu. fuser - identify processes using files or sockets JB -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Saturday, February 12, 2011 12:55:12 pm M. Fioretti wrote: On Sat, Feb 12, 2011 12:47:13 PM -0600, Rick Sewill (rsew...@gmail.com) wrote: Could you show us the output of twice, the second time a few seconds after the first time so we can see if any interrupt number changes fast. more /proc/interrupts here are two runs, 5/6 seconds apart: [root@polaris ~]# more /proc/interrupts CPU0 CPU1 0:136180 IO-APIC-edge timer 1: 0 2 IO-APIC-edge i8042 4: 0 2 IO-APIC-edge 7: 1 0 IO-APIC-edge parport0 8: 0 1 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 12: 0 4 IO-APIC-edge i8042 14: 0 0 IO-APIC-edge pata_amd 15: 0 0 IO-APIC-edge pata_amd 17: 0 2 IO-APIC-fasteoi firewire_ohci 20: 116972135 IO-APIC-fasteoi ohci_hcd:usb3, nvidia 21:947289 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel 22: 0 3 IO-APIC-fasteoi ehci_hcd:usb1 23: 252957 24 IO-APIC-fasteoi ohci_hcd:usb4 43: 449718 5490 PCI-MSI-edge ahci 44: 850242 23 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 12772218 13583547 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES:68964877547957 Rescheduling interrupts CAL: 8607 11701 Function call interrupts TLB: 43915 42920 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP:103103 Machine check polls ERR: 1 MIS: 0 [root@polaris ~]# [root@polaris ~]# more /proc/interrupts CPU0 CPU1 0:136180 IO-APIC-edge timer 1: 0 2 IO-APIC-edge i8042 4: 0 2 IO-APIC-edge 7: 1 0 IO-APIC-edge parport0 8: 0 1 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 12: 0 4 IO-APIC-edge i8042 14: 0 0 IO-APIC-edge pata_amd 15: 0 0 IO-APIC-edge pata_amd 17: 0 2 IO-APIC-fasteoi firewire_ohci 20: 116985135 IO-APIC-fasteoi ohci_hcd:usb3, nvidia 21:947289 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel 22: 0 3 IO-APIC-fasteoi ehci_hcd:usb1 23: 252957 24 IO-APIC-fasteoi ohci_hcd:usb4 43: 449809 5490 PCI-MSI-edge ahci 44: 850456 23 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 12774821 13585530 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES:68969747548786 Rescheduling interrupts CAL: 8608 11703 Function call interrupts TLB: 43919 42921 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP:103103 Machine check polls ERR: 1 MIS: 0 [root@polaris ~]# will try now to find out the clock interrupt rate. Thanks I think the clock interrupt rate is shown by the Local timer interrupts. I don't know if that number is okay or not. I think it might be okay. I am curious about the Rescheduling interrupts. I do not have a dual core system so I have no rescheduling interrupts. I do not know how many rescheduling interrupts is too many. I did google searches, Resheduling interrupts and Linux Resheduling interrupts It appears there have been problems, in this area, over the years. We should be careful to limit ourselves to any recent problems. I found some sort of explanation of rescheduling interrupts at https://help.ubuntu.com/community/ReschedulingInterrupts Also at this URL were suggestions for troubleshooting problems. One suggestion, from this URL was to use vmstat 1. I haven't used vmstat before so this is educational. Another suggestion was troubleshooting ACPI and APIC problems. This problem sounds similar to another person's problem: http://www.spinics.net/lists/kvm/msg49558.html I mention this problem because of the date and also it's Debian (not Fedora). We don't know if this person's problem is a Rescheduling interrupt problem...but it sounds similar. signature.asc Description: This
Re: why is my Linux so damn slow?
On Sat, 12 Feb 2011 14:51:25 +0100, M. Fioretti wrote: Greetings, when I upgraded from Fedora 12 to Fedora 14, about twenty days ago, the system (which wasn't doing really well even before the upgrade) became almost unusable. The problem is, very likely, upstream of Fedora, but I would like to understand where exactly is and if/how Fedora in some way amplifies it. I've posted all details here: http://freesoftware.zona-m.net/help-request-why-is-my-linux-so-damn-slow TIA, Marco I skimmed your writeup, but didn't look at all of the installed packages. My environment is much less powerful than yours, and it's pretty reasonable. Fedora 14 2.6.35.11-83.fc14.i686 2.6 GHz P4 1.5 GB memory Overclocked NVidia 7600 GS with 260.19.36 (built by hand, not rpm) Samsung Synchmaster at 1680x1050 KDE 4.5.5 I run the standard desktop effects. I've tried some of the more esoteric ones, but I find that they're distracting. I run into some slowdowns. I've commented on my OpenOffice Calc issues. Flash is slow (but it's slow in Windows as well). When I stress test Tomcat/MySQL or Tomcat/Derby applications my load average goes to 11 (literally) while running around 500 transactions per minute. This sounds like an NVidia driver issue. I suggest wandering over to www.nvnews.net and reading the Linux support forum. In particular, I have the following set: nvidia-settings -a PixmapCache=1 nvidia-settings -a InitialPixmapPlacement=2 nvidia-settings -a GlyphCache=1 I've placed these (and my overclocking commands) in a script called nvtweaks.sh. I then have the following line in my .xinitrc file: /home/mdeggers/bin/nvtweaks.sh I also have a customized xorg.conf file, and I've modified my fonts (installed MS Core fonts and customized a .fonts.conf file). This works well for me. Your mileage may vary. . . . . just my two cents. /mde/ -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
[8.984680] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 260.19.29 Wed Dec 8 12:08:56 PST 2010 So you've got the Nvidia stuff loaded - well an obvious first test would be to run with the provided Fedora Nvidia drivers and X. That would be a quick way to eliminate one possible cause. [12032.976089] npviewer.bin[2721]: segfault at 0 ip 00f7ced1 sp ff8a60c0 error 4 in libflashplayer.so[bdd000+b2e000] [12041.569570] npviewer.bin[5297]: segfault at f74bd0e0 ip 468527c6 sp ffd76248 error 4 in libc-2.12.90.so[467d7000+18d000] [13779.830969] npviewer.bin[5331]: segfault at 0 ip 00ca9ed1 sp fff96a40 error 4 in libflashplayer.so[90a000+b2e000] [16384.558119] npviewer.bin[6218]: segfault at 418 ip 006b9c86 sp ffd63c98 error 6 in libflashplayer.so[46a000+b2e000] And that doesn't look good - your flash player is crashing in weird ways. Would make me nervous given that its exposed to remote data and networks. Could just be crap code of course. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
What devices are connected to your system? Perhaps a Linux driver, for a device is having problems. Perhaps a device is generating lots of interrupts. In the case of a continual interrupt storm the kernel will detect and log it (and take some attempt at avoiding action). Can you disconnect any devices and see if the slowness goes away? Easier to look in /proc/interrupts for stuff going at crazy rates Alan -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Saturday, February 12, 2011 02:15:02 pm Rick Sewill wrote: Someone help us...I know there is a command to show open files, lsof. Does that command include a way to find out disk activity per file or is there another command that can find out disk activity per file? I'm hoping, if we identify the file(s) with disk activity, we might identify the service/application/kernel feature that is hogging the cpu. There is the 'iotop' package, which give I/O per process, but doesn't list files. Both iotop and top can be run in a batch mode with the -b switch; both can run a specified number of iterations with the -n # switch (where # is the number of iterations, infinite by default). Like many others I'm not seeing this issue; my box being a tad older, a Dell Precision M65 laptop with a 2.16GHz Core2Duo and 4GB of RAM, running the x86_64 dist. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Saturday, February 12, 2011 02:42:25 pm Rick Sewill wrote: I am curious about the Rescheduling interrupts. I do not have a dual core system so I have no rescheduling interrupts. I do; here's my /proc/interrupts and uptime: lowen@localhost:~$ cat /proc/interrupts CPU0 CPU1 0:2368837 0 IO-APIC-edge timer 1: 17017 0 IO-APIC-edge i8042 4: 3 0 IO-APIC-edge 8: 1 0 IO-APIC-edge rtc0 9: 2 0 IO-APIC-fasteoi acpi 12:144 0 IO-APIC-edge i8042 14: 218006 0 IO-APIC-edge ata_piix 15: 229960 0 IO-APIC-edge ata_piix 16: 31864 0 IO-APIC-fasteoi nvidia 17: 22394 0 IO-APIC-fasteoi eth1 19: 8 0 IO-APIC-fasteoi yenta, firewire_ohci 20: 134569 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 21: 71 0 IO-APIC-fasteoi uhci_hcd:usb3 22: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 23: 0 0 IO-APIC-fasteoi uhci_hcd:usb5 45:399 0 PCI-MSI-edge hda_intel 46: 191211 0 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC:20651792870695 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES:19574922326386 Rescheduling interrupts CAL: 9221 16385 Function call interrupts TLB: 8814 10449 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP: 58 58 Machine check polls ERR: 1 MIS: 0 lowen@localhost:~$ uptime 15:47:24 up 4:51, 7 users, load average: 0.02, 0.09, 0.12 lowen@localhost:~$ (don't let the '7 users' throw you; that's just my 7 konsole tabs open.) -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, 12 Feb 2011 13:42:25 -0600, Rick wrote: I am curious about the Rescheduling interrupts. I do not have a dual core system so I have no rescheduling interrupts. I do not know how many rescheduling interrupts is too many. A running Firefox, that displays an ordinary News website with several animated GIFs and a couple of Flash ads, here increases the resched.interrupt count by ~100 or more per second. After a few hours of uptime, that will pile up, of course. Marko has quoted the uptime with his top output in the blog post. To Marko, you can run watch -d1 cat /proc/interrupts in a terminal with and without your mostly used apps running to get a better overview about how the numbers change. I wonder whether the slowness is specific to running X or only X together with a heavily used Firefox? What other tests have been performed in an attempt to find out whether the system is sluggish in general? Perhaps give powertop a try. It reports quite some things about devices that are in use 100% and about stuff that wakes up the cpu often. In either case, it doesn't sound normal. Certainly not with an average load so low as quoted. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
M. Fioretti mfioretti at nexaima.net writes: Greetings, when I upgraded from Fedora 12 to Fedora 14, about twenty days ago, the system (which wasn't doing really well even before the upgrade) became almost unusable. The problem is, very likely, upstream of Fedora, but I would like to understand where exactly is and if/how Fedora in some way amplifies it. I've posted all details here: http://freesoftware.zona-m.net/help-request-why-is-my-linux-so-damn-slow TIA, Marco I have few things that make me want to check them. When you have some time, please check for BIOS updates on your motherboard manufacturer web site ! Now, please give us output of: $ cat /proc/cpuinfo Let me start with your dmesg output. ... [0.00] Checking aperture... [0.00] No AGP bridge found [0.00] Node 0: aperture at 2000 size 32 MB [0.00] Aperture pointing to e820 RAM. Ignoring. [0.00] Your BIOS doesn't leave a aperture memory hole [0.00] Please enable the IOMMU option in the BIOS setup Well, please do it (go to BIOS). If supported, it should be settable thru BIOS. If not settable, we can try on kernel boot line in /etc/grub.conf. It has impact on graphics performance. ... [0.112073] mtrr: your CPUs had inconsistent fixed MTRR settings [0.112075] mtrr: probably your BIOS does not setup all CPUs. [0.112077] mtrr: corrected configuration. I do not know if MTRR is settable in BIOS (it used to be in the past ...). Go to BIOS and enable it if settable. It has impact on graphics performance. ... [0.204973] ACPI: PCI Interrupt Link [LNKA] (IRQs 16 17 18 19) *0, disabled. [0.205276] ACPI: PCI Interrupt Link [LNKB] (IRQs 16 17 18 19) *0, disabled. [0.205571] ACPI: PCI Interrupt Link [LNKC] (IRQs 16 17 18 19) *0, disabled. [0.205864] ACPI: PCI Interrupt Link [LNKD] (IRQs 16 17 18 19) *0, disabled. [0.206171] ACPI: PCI Interrupt Link [LN0A] (IRQs 16 17 18 19) *10 [0.206465] ACPI: PCI Interrupt Link [LN0B] (IRQs 16 17 18 19) *0, disabled. [0.206759] ACPI: PCI Interrupt Link [LN0C] (IRQs 16 17 18 19) *0, disabled. [0.207058] ACPI: PCI Interrupt Link [LN0D] (IRQs 16 17 18 19) *0, disabled. [0.207353] ACPI: PCI Interrupt Link [LN1A] (IRQs 16 17 18 19) *0, disabled. [0.207648] ACPI: PCI Interrupt Link [LN1B] (IRQs 16 17 18 19) *0, disabled. [0.207942] ACPI: PCI Interrupt Link [LN1C] (IRQs 16 17 18 19) *0, disabled. [0.208242] ACPI: PCI Interrupt Link [LN1D] (IRQs 16 17 18 19) *0, disabled. [0.208542] ACPI: PCI Interrupt Link [LN2A] (IRQs 16 17 18 19) *11 [0.208835] ACPI: PCI Interrupt Link [LN2B] (IRQs 16 17 18 19) *0, disabled. [0.209134] ACPI: PCI Interrupt Link [LN2C] (IRQs 16 17 18 19) *0, disabled. [0.209429] ACPI: PCI Interrupt Link [LN2D] (IRQs 16 17 18 19) *0, disabled. [0.209732] ACPI: PCI Interrupt Link [LN3A] (IRQs 16 17 18 19) *15 [0.210032] ACPI: PCI Interrupt Link [LN3B] (IRQs 16 17 18 19) *0, disabled. [0.210327] ACPI: PCI Interrupt Link [LN3C] (IRQs 16 17 18 19) *0, disabled. [0.210621] ACPI: PCI Interrupt Link [LN3D] (IRQs 16 17 18 19) *0, disabled. [0.210915] ACPI: PCI Interrupt Link [LN4A] (IRQs 16 17 18 19) *0, disabled. [0.211215] ACPI: PCI Interrupt Link [LN4B] (IRQs 16 17 18 19) *0, disabled. [0.211510] ACPI: PCI Interrupt Link [LN4C] (IRQs 16 17 18 19) *0, disabled. [0.211805] ACPI: PCI Interrupt Link [LN4D] (IRQs 16 17 18 19) *0, disabled. [0.212104] ACPI: PCI Interrupt Link [LN5A] (IRQs 16 17 18 19) *0, disabled. [0.212399] ACPI: PCI Interrupt Link [LN5B] (IRQs 16 17 18 19) *0, disabled. [0.212694] ACPI: PCI Interrupt Link [LN5C] (IRQs 16 17 18 19) *0, disabled. [0.212988] ACPI: PCI Interrupt Link [LN5D] (IRQs 16 17 18 19) *0, disabled. [0.213288] ACPI: PCI Interrupt Link [LN6A] (IRQs 16 17 18 19) *0, disabled. [0.213583] ACPI: PCI Interrupt Link [LN6B] (IRQs 16 17 18 19) *0, disabled. [0.213878] ACPI: PCI Interrupt Link [LN6C] (IRQs 16 17 18 19) *0, disabled. [0.214181] ACPI: PCI Interrupt Link [LN6D] (IRQs 16 17 18 19) *0, disabled. [0.214476] ACPI: PCI Interrupt Link [LN7A] (IRQs 16 17 18 19) *0, disabled. [0.214771] ACPI: PCI Interrupt Link [LN7B] (IRQs 16 17 18 19) *0, disabled. [0.215072] ACPI: PCI Interrupt Link [LN7C] (IRQs 16 17 18 19) *0, disabled. [0.215366] ACPI: PCI Interrupt Link [LN7D] (IRQs 16 17 18 19) *0, disabled. [0.215667] ACPI: PCI Interrupt Link [LUB0] (IRQs 20 21 22 23) *10 [0.215968] ACPI: PCI Interrupt Link [LUB2] (IRQs 20 21 22 23) *10 [0.216275] ACPI: PCI Interrupt Link [LMAC] (IRQs 20 21 22 23) *10 [0.216576] ACPI: PCI Interrupt Link [LAZA] (IRQs 20 21 22 23) *10 [0.216877] ACPI: PCI Interrupt Link [SGRU] (IRQs 20 21 22 23) *10 [0.217191] ACPI: PCI Interrupt Link [LSMB] (IRQs 20 21 22 23) *15 [0.217492] ACPI: PCI Interrupt Link [LPMU] (IRQs 20 21 22 23) *11 [0.217791] ACPI: PCI Interrupt Link [LSA0] (IRQs 20 21 22 23) *5 [0.218137
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 20:57:32 PM +, JB (jb.1234a...@gmail.com) wrote: Now, please give us output of: $ cat /proc/cpuinfo Hi, JB. Here is the output of cat /proc/cpuinfo. tomorrow I'll check the bios setting. Thanks, Marco [root@polaris ~]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family: 15 model : 107 model name : AMD Athlon(tm) Dual Core Processor 4850e stepping: 2 cpu MHz : 1000.000 cache size: 512 KB physical id : 0 siblings : 2 core id: 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu: yes fpu_exception : yes cpuid level: 1 wp : yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv bogomips : 1999.88 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes: 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps processor : 1 vendor_id : AuthenticAMD cpu family: 15 model : 107 model name : AMD Athlon(tm) Dual Core Processor 4850e stepping: 2 cpu MHz : 1000.000 cache size: 512 KB physical id : 0 siblings : 2 core id: 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu: yes fpu_exception : yes cpuid level: 1 wp : yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch lbrv bogomips : 1999.88 TLB size : 1024 4K pages clflush size : 64 cache_alignment : 64 address sizes: 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On 02/12/2011 07:13 PM, M. Fioretti wrote: Oh, and when I said the system is slow even if firefox isn't running I meant that I *had* run killall firefox. I think between this and Regarding firefox ..could you go in ~/.mozilla/firefox/_your_profile_.default and do : for i in *.sqlite; do echo VACUUM; | sqlite3 $i; done assuming that you have sqlite installed HTH, Adrian smime.p7s Description: S/MIME Cryptographic Signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 22:41:31 PM +0200, Adrian Sevcenco (adrian.sevce...@cern.ch) wrote: On 02/12/2011 07:13 PM, M. Fioretti wrote: Oh, and when I said the system is slow even if firefox isn't running I meant that I *had* run killall firefox. I think between this and Regarding firefox ..could you go in ~/.mozilla/firefox/_your_profile_.default and do : for i in *.sqlite; do echo VACUUM; | sqlite3 $i; done Oh, you mean doing this trick: http://www.gettingclever.com/2008/06/vacuum-your-firefox-3.html Cool, thanks, I didn't know that. Man, it would be really ironic if after years making fun of Windows because it needs defragmenting to run faster, it turns out you have to defragment Firefox to keep Linux fast... This is the result on my account: BEFORE: -rw-r--r--. 1 marco marco 24923136 Nov 15 2008 urlclassifier2.sqlite -rw-r--r--. 1 marco marco 2048 Jan 13 19:35 permissions.sqlite -rw-r--r--. 1 marco marco 2048 Feb 9 10:55 search.sqlite -rw-r--r--. 1 marco marco 129024 Feb 11 17:43 signons.sqlite -rw-r--r--. 1 marco marco 225280 Feb 11 19:35 downloads.sqlite -rw--- 1 marco marco29696 Feb 12 17:22 ybookmarks.sqlite -rw-r--r-- 1 marco marco32768 Feb 12 17:22 urlclassifier3.sqlite -rw-r--r--. 1 marco marco91136 Feb 12 19:18 content-prefs.sqlite -rw-r--r--. 1 marco marco 1307648 Feb 12 21:03 webappsstore.sqlite -rw-r--r--. 1 marco marco 400384 Feb 12 21:28 formhistory.sqlite -rw-r--r--. 1 marco marco 17108992 Feb 12 21:42 places.sqlite -rw-r--r-- 1 marco marco 595968 Feb 12 21:42 cookies.sqlite AFTER: -rw-r--r--. 1 marco marco 92160 Feb 12 21:48 content-prefs.sqlite -rw-r--r-- 1 marco marco 421888 Feb 12 21:48 cookies.sqlite -rw-r--r--. 1 marco marco 60416 Feb 12 21:48 downloads.sqlite -rw-r--r--. 1 marco marco 172032 Feb 12 21:48 formhistory.sqlite -rw-r--r--. 1 marco marco2048 Feb 12 21:48 permissions.sqlite -rw-r--r--. 1 marco marco 6447104 Feb 12 21:48 places.sqlite -rw-r--r--. 1 marco marco2048 Feb 12 21:48 search.sqlite -rw-r--r--. 1 marco marco 126976 Feb 12 21:48 signons.sqlite -rw-r--r--. 1 marco marco 145408 Feb 12 21:48 urlclassifier2.sqlite -rw-r--r-- 1 marco marco 32768 Feb 12 21:48 urlclassifier3.sqlite -rw-r--r--. 1 marco marco 887808 Feb 12 21:48 webappsstore.sqlite -rw--- 1 marco marco 29696 Feb 12 21:48 ybookmarks.sqlite Impressive reduction in size. And, but do take this with a huge grain of salt, since I'm really tired right now, I just restarted Firefox (I had done killall firefox right before doing this trick), and I also _want_ to see some improvement... it does seem to run faster, at least for now. Later, and thanks again. Marco -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, Feb 12, 2011 21:54:40 PM +0100, Michael Schwendt (mschwe...@gmail.com) wrote: On Sat, 12 Feb 2011 13:42:25 -0600, Rick wrote: I am curious about the Rescheduling interrupts. I do not have a dual core system so I have no rescheduling interrupts. I do not know how many rescheduling interrupts is too many. A running Firefox, that displays an ordinary News website with several animated GIFs and a couple of Flash ads, here increases the resched.interrupt count by ~100 or more per second. After a few hours of uptime, that will pile up, of course. Marko has quoted the uptime with his top output in the blog post. To Marko, you can run watch -d1 cat /proc/interrupts This is with Firefox running (right after defragmenting as suggested in the other post I just answered): Every 2.0s: cat /proc/interruptsSat Feb 12 21:58:15 2011 CPU0 CPU1 0:136223 IO-APIC-edge timer 1: 0 2 IO-APIC-edge i8042 4: 0 2 IO-APIC-edge 7: 1 0 IO-APIC-edge parport0 8: 0 1 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 12: 0 4 IO-APIC-edge i8042 14: 0 0 IO-APIC-edge pata_amd 15: 0 0 IO-APIC-edge pata_amd 17: 0 2 IO-APIC-fasteoi firewire_ohci 20: 134279135 IO-APIC-fasteoi ohci_hcd:usb3, nvidia 21:947289 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel 22: 0 3 IO-APIC-fasteoi ehci_hcd:usb1 23: 315517 24 IO-APIC-fasteoi ohci_hcd:usb4 43: 549295 5490 PCI-MSI-edge ahci 44:1032726 23 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 15078180 16295422 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES:80940918916019 Rescheduling interrupts CAL: 10623 13590 Function call interrupts TLB:51819 58166 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP:128128 Machine check polls ERR: 1 MIS: 0 This is right after killall firefox: Every 2.0s: cat /proc/interruptsSat Feb 12 21:59:37 2011 CPU0 CPU1 0:136224 IO-APIC-edge timer 1: 0 2 IO-APIC-edge i8042 4: 0 2 IO-APIC-edge 7: 1 0 IO-APIC-edge parport0 8: 0 1 IO-APIC-edge rtc0 9: 0 0 IO-APIC-fasteoi acpi 12: 0 4 IO-APIC-edge i8042 14: 0 0 IO-APIC-edge pata_amd 15: 0 0 IO-APIC-edge pata_amd 17: 0 2 IO-APIC-fasteoi firewire_ohci 20: 134773135 IO-APIC-fasteoi ohci_hcd:usb3, nvidia 21:947289 IO-APIC-fasteoi ehci_hcd:usb2, hda_intel 22: 0 3 IO-APIC-fasteoi ehci_hcd:usb1 23: 316092 24 IO-APIC-fasteoi ohci_hcd:usb4 43: 550356 5490 PCI-MSI-edge ahci 44:1034870 23 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 15094971 16313120 Local timer interrupts SPU: 0 0 Spurious interrupts PMI: 0 0 Performance monitoring interrupts PND: 0 0 Performance pending work RES:81013198924946 Rescheduling interrupts CAL: 10662 13610 Function call interrupts TLB:51870 58198 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts MCE: 0 0 Machine check exceptions MCP:128128 Machine check polls ERR: 1 MIS: 0 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
RE: why is my Linux so damn slow?
7.024044] i2c i2c-0: nForce2 SMBus adapter at 0x600 AMD's Socket A. Pretty old, slow system. It's possible it doesn't implement APIC and ACPI correctly. Someone suggested a bios update - if there is one, that would be a good idea. Does the command 'smartctl -a /dev/sda' show any reallocated sectors? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
RE: why is my Linux so damn slow?
I have noi Disk Utility under System-Administration. What is its real name? Sorry, wrong OS. Use smartctl, which is part of the smartmontools. Look for reallocated sectors, which is a bad thing... Example: smartctl -a /dev/sda -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On 02/12/2011 12:56 PM, M. Fioretti wrote: Oh, you mean doing this trick: http://www.gettingclever.com/2008/06/vacuum-your-firefox-3.html Cool, thanks, I didn't know that. Man, it would be really ironic if after years making fun of Windows because it needs defragmenting to run faster, it turns out you have to defragment Firefox to keep Linux fast... Get BleachBit, and have it install the Administrator mode. Then, with Firefox closed, run BleachBit and have it do all of that stuph for you. The Administrator mode lets you do things that need root access. Personally, I run both just before every reboot on my desktop, but then, I only reboot for kernel updates and only shut down for hardware issues or power failures. Last time I rebooted was after 24 days of uptime since upgrading to Fedora 14. (My sister uses Ubuntu and currently has over 70 days of uptime.) -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
RE: why is my Linux so damn slow?
On Sat, 2011-02-12 at 07:33 -0700, compdoc wrote: when I upgraded from Fedora 12 to Fedora 14, about twenty days ago, the system (which wasn't doing really well even before the upgrade) became almost unusable. Weird problems often have a hardware issue behind them. There are many things to check. Some are easier than others: From the desktop, open the program SystemAdministrationDisk Utility. Select each of your hard drives in the list on the left, and then click the Smart Data button. In the upper part of the window, look for a Bad Sector count, and Overall Assessment of the drive. Any problems? The program is actually found in Gnome at: Applications/System Tools/Disk Utility -- === It seems to make an auto driver mad if he misses you. === Aaron Konstam telephone: (210) 656-0355 e-mail: akons...@sbcglobal.net -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Sat, 12 Feb 2011 22:00:03 +0100, M. wrote: A running Firefox, that displays an ordinary News website with several animated GIFs and a couple of Flash ads, here increases the resched.interrupt count by ~100 or more per second. After a few hours of uptime, that will pile up, of course. Marko has quoted the uptime with his top output in the blog post. To Marko, you can run watch -d1 cat /proc/interrupts This is with Firefox running (right after defragmenting as suggested in the other post I just answered): It isn't meant for posting it, but for monitoring the changes yourself. Hence the -d (the '1' is a typo), which highlights the digits that change. (watch -n1 -d cat /proc/interrupts) Every 2.0s: cat /proc/interrupts Sat Feb 12 21:58:15 2011 RES:80940918916019 Rescheduling interrupts This is right after killall firefox: Every 2.0s: cat /proc/interrupts Sat Feb 12 21:59:37 2011 RES:81013198924946 Rescheduling interrupts So, for the 2nd cpu, it incremented by 8019 in roughly more than a minute, which is between 100-200 per second. That's also what other people experience without any unusual slowness of the system. Though, when you've stopped Firefox, does the interrupt count still increase so quickly? And with Firefox not being busy anymore (and not processing Flash), are your troubles during typing words and sentences cured or not? -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Saturday, February 12, 2011 04:11:22 pm Aaron Konstam wrote: I have noi Disk Utility under System-Administration. What is its real name? palimpsest, which is provided by the gnome-disk-utility package. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On Saturday, February 12, 2011 04:48:46 pm compdoc wrote: 7.024044] i2c i2c-0: nForce2 SMBus adapter at 0x600 AMD's Socket A. Pretty old, slow system. It's possible it doesn't implement APIC and ACPI correctly. Someone suggested a bios update - if there is one, that would be a good idea. Uh, by /proc/cpuinfo it's a Socket AM2 Athlon 4850e, which isn't too awfully old. Socket A was pre-Athlon64, and definitely not capable of 8GB of RAM. The motherboard he referenced is an ASUS M3N78-EM, which is a current product at NewEgg, among other vendors. Does the command 'smartctl -a /dev/sda' show any reallocated sectors? That's a thought. Palimpsest (Disk Utility) includes a utility to run SMART tests; launch Disk Utility, select the disk, click on 'SMART Data', then select the test you'd like. It also lists the SMART information from the drive. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: why is my Linux so damn slow?
On 02/12/2011 11:23 PM, M. Fioretti wrote: On Sat, Feb 12, 2011 20:57:32 PM +, JB (jb.1234a...@gmail.com) wrote: Now, please give us output of: $ cat /proc/cpuinfo Hi, JB. Here is the output of cat /proc/cpuinfo. tomorrow I'll check the bios setting. Thanks, Marco [root@polaris ~]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family: 15 model : 107 model name: AMD Athlon(tm) Dual Core Processor 4850e stepping : 2 cpu MHz : 1000.000 Another idea would be to disable cpu scaling (set the governor on performance) and see how it goes ... its true that having an energy efficient cpu i imagine that you want to keep it at minimum a lot .. look in /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and change it to performance ... and see how it goes also i would rather recommend conservative governor as scales the freq more slowly that ondemand (less fast and big transitions in freq) btq ... with performance governor MHz should be 2500 ... HTH, Adrian smime.p7s Description: S/MIME Cryptographic Signature -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Update on: why is my Linux so damn slow?
Good morning, everybody! I just woke up and found lots of other suggestions, both here and in 20/30 comments on the web page, which I just approved so are now readable by everybody. Almost surely, today I won't be able to try and report about the latest suggestions. I have to leave with family in a few minutes, for stuff planned weeks ago. So if you don't hear from me again before a couple of days, it's not because I've ran again from Linux or Fedora. For now, just wanted to say a couple of things: first, many thanks to all who've provided lots of useful advice. As I just said, I've got so much of it that I simply haven't had the time to use all of it yet. In any case it is my intention to do as many of those other tests as I can and then report here as soon as possible, and then reformat all this advice in some how-to guide publish on the same website. secondly, I have to report that a simple vacuuming of the sqlite databases of Firefox as explained here: http://www.gettingclever.com/2008/06/vacuum-your-firefox-3.html is enough to make a real difference. After doing that yesterday evening, I have deliberately let Firefox open the whole night, with 10/12 tabs scattered over three windows. 8/9 hours later, the system is not as fast as I'd like it, but IS much faster than I have had to endure in the previous days. Many thanks to the person who suggested this, read my message from yesterday to see how much this trick reduced the size of those databases. There is still a lot to do and I'll do as much of it as I can, but it's impressive that simple tricks like this that, for the record, would have never emerged by simply trying live cds can do. I must seriously write something more about how to optimize Linux in the 2010's. Later, Marco -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Re: Update on: why is my Linux so damn slow?
On Sun, Feb 13, 2011 08:17:00 AM +0100, Marco Fioretti (mfiore...@nexaima.net) wrote: Almost surely, today I won't be able to try and report about the latest suggestions. I have to leave with family in a few minutes, for stuff planned weeks ago. So if you don't hear from me again before a couple of days, it's not because I've ran again from Linux or Fedora. sorry, I meant ran away, not ran again -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
