[opensuse] 12.2 performance
When I installed openSUSE 12.1, performance on my computer took a severe dive. A kernel update improved things somewhat, but things got to the point where I was seriously considering buying a new computer to get decent performance again. I installed 12.2 a couple of days ago and find performance is much better than 12.1. However, there's still the problem with Seamonkey 2.12 where it locks up solid for 15-20 seconds. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2012-09-19 at 07:24 -0400, James Knott wrote:
What have you done to diagnose the issue? Is the issue I/O related? [is you HD like on excessively] Do you consistently have high swap levels? If you run top do you see the box in wait-state frequently? Have you verified your DMA, etc... settings with hdparm? Do you see errors in dmesg? What are you doing when Seamonkey locks up? Is it during network operations... do any other network applications 'hang-up'? When Seamonkey locks up is the desktop otherwise still responsive? Because there is no general issue with 12.1 / 12.2; this almost certainly relates specifically to your hardware or configuration.
James Knott wrote:
strace'ing seamonkey when it locks up your machine might give you a hint. I assume "locks up" doesn't mean the machine is hung, just that some process is hogging the CPU(s). -- Per Jessen, Zürich (12.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
What happens is that Seamonkey alone locks up. There is no response to inputs, though keystrokes are buffered until it responds again. I can work with other apps without problem. I just tried a strace -p and saw a continuous stream of data. How do you find something relevant in that? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Without knowing seamonkey in detail, it's a bit of guesswork, but try capturing the output (strace -o <file> -p <pid), then post it somewhere, and I'll take a look. It is clearly looping, but not just in a tight loop, so it should be possible to get an idea of what it's up to. -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
You can find the capture here: <https://docs.google.com/folder/d/0B5LapMwk8iPrZXpDSVlaN3lVekU/edit?docId=0B5LapMwk8iPrX2tXanZyejI2OUk> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
<https://docs.google.com/folder/d/0B5LapMwk8iPrZXpDSVlaN3lVekU/edit?docId=0B5LapMwk8iPrX2tXanZyejI2OUk> Hmm, doesn't say a lot - SM keeps doing a recvfrom() which keeps returning -EAGAIN. It's a socket fd=4, but I don't see a bind() or connect() anywhere. That it is using recvfrom() probably means it's UDP. I wonder if it might be name resolution. -- Per Jessen, Zürich (14.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I have no idea what it's trying to do when it locks up. As I mentioned it occurs with both email and browser. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2012-09-19 at 18:36 +0200, Per Jessen wrote:
Look in /proc/{pid}/fd/{fh#} points and that will tell who where the file handles are bound to [in this case, 4 is the fh#]
That it is using recvfrom() probably means it's UDP. I wonder if it might be name resolution.
That is a good guess, I'd put my money on that. EAGAIN means there was an attempt to read from a socket but nothing was available. I'd install the bind caching nameserver packages, start bind, and point my resolver at 127.0.0.1 - then see if the problem goes away. If it does, that it is a DNS problem or a resolver bug.
On Wed, 2012-09-19 at 08:22 -0400, James Knott wrote:
I'd expect a continuous stream if the application is in a hard loop - which your saying it maxes out a core indicates that it is. If that loop involves a file handle, such as a select/poll/read... you can cross reference that file handle to whatever that resource is by looking at where /proc/{pid}/fd/{fh#} points. This is more likely than not a Seamonkey bug.
On Wed, 2012-09-19 at 10:20 -0400, James Knott wrote:
What on earth does that mean: "This problem came in with 12.2 and happened with openSUSE 12.1 & 12.2". Are you talking about version numbers for *different* products, otherwise this is unparsable. Do you mean "2.12" of *Seamonkey* (and are placing the decimal in various locations throughout the thread)??? :) I've done that kind of thing myself. If it happens in both openSUSE 12.1 and openSUSE 12.2 it is very likely to be a bug, not in openSUSE, but in Seamonkey.
Adam Tauno Williams wrote:
Sorry, that was a typo. It should have been Seamonkey 2.12. Yes, it happened with both openSUSE 12.1 and 12.2. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* James Knott <james.knott@rogers.com> [09-19-12 08:06]:
openSUSE 12.2_Tumbleweed x86_64 i7 seamonkey-2.12-2.8.1.x86_64 no swap no difficulties w/seamonkey startup/system load/crashes -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012-09-19 07:24 (GMT-0400) James Knott composed:
This may be OT, or it may provide a clue or clues that networking is involved in various SM troubles. Last week I switched from using SM 2.7.x on OS/2 for my 200-600 emails/day to doing it on 32 bit OS11.4/KDE3/SM2.12rpm using a manually modified copy of the OS/2 profile. I had hoped to solve several problems by making the switch, including extended length stalls, but one problem definitely was not improved, and possibly was made worse: In OS/2, clicking on SM email send would often result in a stall that would last anywhere from several seconds to virtually indefinite. Usually it would ultimately complete the send process, but sometimes I'd get a pair of failure modals. Usually when the later happened, immediately doing send again would succeed, but sometimes the failure would repeat, sometimes more than once. In Linux, these failures seem to have gotten worse, both in frequency and duration. Today I started clicking abort as soon as contacting smtp.... appears in the statusbar, after which the abort would succeed and I would immediatedly click send again. More often than not the second try succeeds. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012-09-19 07:24 (GMT-0400) James Knott composed:
This may be OT, or it may provide a clue or clues that networking is involved in various SM troubles. Last week I switched from using SM 2.7.x on OS/2 for my 200-600 emails/day to doing it on 32 bit OS11.4/KDE3/SM2.12rpm using a manually modified copy of the OS/2 profile. I had hoped to solve several problems by making the switch, including extended length stalls, but one problem definitely was not improved, and possibly was made worse: In OS/2, clicking on SM email send would often result in a stall that would last anywhere from several seconds to virtually indefinite. Usually it would ultimately complete the send process, but sometimes I'd get a pair of failure modals. Usually when the later happened, immediately doing send again would succeed, but sometimes the failure would repeat, sometimes more than once. In Linux, these failures seem to have gotten worse, both in frequency and duration. Today I started clicking abort as soon as contacting smtp.... appears in the statusbar, after which the abort would succeed and I would immediatedly click send again. More often than not the second try succeeds. Sometimes it gets past "contacting smtp..." but then stalls on "delivering...". -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012-09-19 10:06 (GMT-0400) Felix Miata composed:
I forgot to mention this problem is quite old, dating back probably at least into last year. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2012-09-19 at 07:24 -0400, James Knott wrote:
What have you done to diagnose the issue? Is the issue I/O related? [is you HD like on excessively] Do you consistently have high swap levels? If you run top do you see the box in wait-state frequently? Have you verified your DMA, etc... settings with hdparm? Do you see errors in dmesg? What are you doing when Seamonkey locks up? Is it during network operations... do any other network applications 'hang-up'? When Seamonkey locks up is the desktop otherwise still responsive? Because there is no general issue with 12.1 / 12.2; this almost certainly relates specifically to your hardware or configuration.
James Knott wrote:
strace'ing seamonkey when it locks up your machine might give you a hint. I assume "locks up" doesn't mean the machine is hung, just that some process is hogging the CPU(s). -- Per Jessen, Zürich (12.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
What happens is that Seamonkey alone locks up. There is no response to inputs, though keystrokes are buffered until it responds again. I can work with other apps without problem. I just tried a strace -p and saw a continuous stream of data. How do you find something relevant in that? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
Without knowing seamonkey in detail, it's a bit of guesswork, but try capturing the output (strace -o <file> -p <pid), then post it somewhere, and I'll take a look. It is clearly looping, but not just in a tight loop, so it should be possible to get an idea of what it's up to. -- Per Jessen, Zürich (12.3°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
You can find the capture here: <https://docs.google.com/folder/d/0B5LapMwk8iPrZXpDSVlaN3lVekU/edit?docId=0B5LapMwk8iPrX2tXanZyejI2OUk> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott wrote:
<https://docs.google.com/folder/d/0B5LapMwk8iPrZXpDSVlaN3lVekU/edit?docId=0B5LapMwk8iPrX2tXanZyejI2OUk> Hmm, doesn't say a lot - SM keeps doing a recvfrom() which keeps returning -EAGAIN. It's a socket fd=4, but I don't see a bind() or connect() anywhere. That it is using recvfrom() probably means it's UDP. I wonder if it might be name resolution. -- Per Jessen, Zürich (14.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I have no idea what it's trying to do when it locks up. As I mentioned it occurs with both email and browser. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, 2012-09-19 at 18:36 +0200, Per Jessen wrote:
Look in /proc/{pid}/fd/{fh#} points and that will tell who where the file handles are bound to [in this case, 4 is the fh#]
That it is using recvfrom() probably means it's UDP. I wonder if it might be name resolution.
That is a good guess, I'd put my money on that. EAGAIN means there was an attempt to read from a socket but nothing was available. I'd install the bind caching nameserver packages, start bind, and point my resolver at 127.0.0.1 - then see if the problem goes away. If it does, that it is a DNS problem or a resolver bug.
On Wed, 2012-09-19 at 08:22 -0400, James Knott wrote:
I'd expect a continuous stream if the application is in a hard loop - which your saying it maxes out a core indicates that it is. If that loop involves a file handle, such as a select/poll/read... you can cross reference that file handle to whatever that resource is by looking at where /proc/{pid}/fd/{fh#} points. This is more likely than not a Seamonkey bug.
On Wed, 2012-09-19 at 10:20 -0400, James Knott wrote:
What on earth does that mean: "This problem came in with 12.2 and happened with openSUSE 12.1 & 12.2". Are you talking about version numbers for *different* products, otherwise this is unparsable. Do you mean "2.12" of *Seamonkey* (and are placing the decimal in various locations throughout the thread)??? :) I've done that kind of thing myself. If it happens in both openSUSE 12.1 and openSUSE 12.2 it is very likely to be a bug, not in openSUSE, but in Seamonkey.
Adam Tauno Williams wrote:
Sorry, that was a typo. It should have been Seamonkey 2.12. Yes, it happened with both openSUSE 12.1 and 12.2. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* James Knott <james.knott@rogers.com> [09-19-12 08:06]:
openSUSE 12.2_Tumbleweed x86_64 i7 seamonkey-2.12-2.8.1.x86_64 no swap no difficulties w/seamonkey startup/system load/crashes -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012-09-19 07:24 (GMT-0400) James Knott composed:
This may be OT, or it may provide a clue or clues that networking is involved in various SM troubles. Last week I switched from using SM 2.7.x on OS/2 for my 200-600 emails/day to doing it on 32 bit OS11.4/KDE3/SM2.12rpm using a manually modified copy of the OS/2 profile. I had hoped to solve several problems by making the switch, including extended length stalls, but one problem definitely was not improved, and possibly was made worse: In OS/2, clicking on SM email send would often result in a stall that would last anywhere from several seconds to virtually indefinite. Usually it would ultimately complete the send process, but sometimes I'd get a pair of failure modals. Usually when the later happened, immediately doing send again would succeed, but sometimes the failure would repeat, sometimes more than once. In Linux, these failures seem to have gotten worse, both in frequency and duration. Today I started clicking abort as soon as contacting smtp.... appears in the statusbar, after which the abort would succeed and I would immediatedly click send again. More often than not the second try succeeds. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012-09-19 07:24 (GMT-0400) James Knott composed:
This may be OT, or it may provide a clue or clues that networking is involved in various SM troubles. Last week I switched from using SM 2.7.x on OS/2 for my 200-600 emails/day to doing it on 32 bit OS11.4/KDE3/SM2.12rpm using a manually modified copy of the OS/2 profile. I had hoped to solve several problems by making the switch, including extended length stalls, but one problem definitely was not improved, and possibly was made worse: In OS/2, clicking on SM email send would often result in a stall that would last anywhere from several seconds to virtually indefinite. Usually it would ultimately complete the send process, but sometimes I'd get a pair of failure modals. Usually when the later happened, immediately doing send again would succeed, but sometimes the failure would repeat, sometimes more than once. In Linux, these failures seem to have gotten worse, both in frequency and duration. Today I started clicking abort as soon as contacting smtp.... appears in the statusbar, after which the abort would succeed and I would immediatedly click send again. More often than not the second try succeeds. Sometimes it gets past "contacting smtp..." but then stalls on "delivering...". -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012-09-19 10:06 (GMT-0400) Felix Miata composed:
I forgot to mention this problem is quite old, dating back probably at least into last year. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (5)
-
Adam Tauno Williams -
Felix Miata -
James Knott -
Patrick Shanahan -
Per Jessen