From: Christian Schmid <webmaster@rapidforum.com>
To: Francois Romieu <romieu@fr.zoreil.com>
Cc: netdev@oss.sgi.com
Subject: Re: argh more bugs!!!
Date: Tue, 22 Feb 2005 01:37:46 +0100 [thread overview]
Message-ID: <421A7EDA.4090205@rapidforum.com> (raw)
In-Reply-To: <20050222002315.GE26248@electric-eye.fr.zoreil.com>
OK the problem with the break is solved. I am REALLY sorry but it was not the net-code in linux. The
SQL-Server has experienced an index-key collision as I added a second multi-key to it. It seems the
sort-buffer overflowed and it suddenly raised the cpu-time very high. I will contact
mysql-developers and ask them about it. The break was due to the table-lock mysql does for every update.
The problem with the slowdown at many sockets still exists. This isnt solved yet. I hope this isnt
my fault as well. Else I feel forced to spend 1000 dollars to some open-source foundation. *grin*
Francois Romieu wrote:
> Christian Schmid <webmaster@rapidforum.com> :
>
>>It suddenly appeared again. there you go..........
>
>
> Thanks. I'll do some graphics tomorrow to be sure but the slabs do not seem
> wrong. vmstat output looks weird:
>
> procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
> r b swpd free buff cache si so bi bo in cs us sy id wa
> 2 3 0 8496 25236 7941848 0 0 37920 0 7563 2788 13 19 34 33
> 2 2 0 9268 25172 7941300 0 0 36688 0 7424 2814 15 19 40 26
> 1 0 0 19576 25264 7928356 0 0 9468 13080 8072 607 22 13 59 6
> 1 0 0 18052 25264 7928356 0 0 0 0 7975 40 18 7 75 0
> 1 0 0 17660 25264 7928356 0 0 0 0 7487 38 21 4 75 0
> 1 0 0 18560 25264 7928356 0 0 0 0 6500 44 22 3 75 0
> 1 0 0 20072 25264 7928356 0 0 0 0 5834 44 23 2 75 0
> 1 3 0 21516 25320 7928300 0 0 0 3408 6796 153 24 3 58 15
> 0 4 0 10596 25436 7942056 0 0 44084 2220 11226 4282 12 10 31 47
> 2 2 0 9324 25240 7943952 0 0 39292 0 8433 3212 9 13 39 38
> 4 1 0 11596 25300 7941580 0 0 35820 0 7945 4306 17 21 30 32
> 0 5 0 13208 25560 7939280 0 0 40684 6456 7920 4081 19 18 32 31
> 4 1 0 12620 24944 7859724 0 0 32204 272 7306 2304 12 28 27 34
> 1 3 0 64964 24852 7888240 0 0 44944 96 7314 2631 19 31 24 27
>
> ???
>
> Since you have a lot of cpu, could you "strace -f -T -o /tmp/nitz -p xyz" one
> or two of your perl processes when they hang ?
>
> If you do not have too many processes, monitoring "echo t > /proc/sysrq-trigger"
> for some time could tell what the system is waiting for.
>
> --
> Ueimor
>
>
next prev parent reply other threads:[~2005-02-22 0:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-21 20:04 ARGH MORE BUGS!!! Christian Schmid
2005-02-21 20:19 ` Matthias-Christian Ott
2005-02-21 20:25 ` Christian Schmid
2005-02-21 20:28 ` Francois Romieu
2005-02-21 20:34 ` Christian Schmid
2005-02-21 20:56 ` Francois Romieu
2005-02-21 21:17 ` Christian Schmid
2005-02-21 21:36 ` Francois Romieu
2005-02-21 22:10 ` Christian Schmid
2005-02-21 23:03 ` Christian Schmid
2005-02-22 0:23 ` argh more bugs!!! Francois Romieu
2005-02-22 0:37 ` Christian Schmid [this message]
2005-02-22 0:10 ` ARGH MORE BUGS!!! Christian Schmid
2005-02-21 21:18 ` Christian Schmid
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=421A7EDA.4090205@rapidforum.com \
--to=webmaster@rapidforum.com \
--cc=netdev@oss.sgi.com \
--cc=romieu@fr.zoreil.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.