MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Andrew Dunstan Date:June 24 1999 11:34pm
Subject:Re: glibc 2.1 performance
View as plain text  
It could also be the kernel version you are running ... have you tried it 
with 2.2.10 (which i think is the latest) as opposed to RedHat 6.0's 2.2.5?



PS: if you switch kernels you might need to apply the big-FDSET patch, which 
RedHat have applied to their kernel tree but isn't in the standard 
production kernel releases yet AFAIK.

>From: Tom Cunningham <tom@stripped>
>To: mysql@stripped
>CC: monty@stripped, jason@stripped
>Subject: glibc 2.1 performance
>Date: Thu, 24 Jun 1999 18:38:26 -0400 (EDT)
>I went back through the archives and couldn't find anything about this, so
>I figured I'd pipe in. I've been having all sorts of problems the last
>couple of days benchmarking two machines. We have an old machine which
>runs Red Hat 5.2 (glibc-2.0.7-29), and a new machine which runs Red Hat
>6.0 (glibc-2.1.1-6). In every applicable benchmark I can find, the new
>machine beats the pants off of the old one - usually by double the speed.
>When we ran Apache Bench on a database CGI, the new machine started
>choking and the old machine performed pretty well - note : I'm using the
>*exact* same tables, and the *exact* same CGI. I got some advice here
>earlier that it could be Apache::DBI, but it's not.
>We started to doubt Apache Bench's results, so we came up with a little
>script that would spawn off processes and time them overall. The new
>machine (the fast one) started choking after three mysql processes).
>Using DBI, Average time of Execution
>Number of Forked
>Processes	        Old Machine             New Machine
>1                       0.0000399351            0.0000280142
>2                       0.7026379704            0.4452039599
>3                       1.3370873531            0.6005186637
>4                       1.0571669936            1.6903942525
>5                       1.2100330114            1.9079551935
>10                      1.0757207990            2.2621705055
>15                      1.2155478001            2.4058329980
>20                      1.1691342056            2.4783635020
>25                      1.1905063629            2.4859128809
>I though possible that DBI could be the problem, so I started cat'ing a
>file with some sql into /usr/local/bin/mysql. Results were similar...
>Not Using DBI, Average Time of Execution
>Number of Forked Processes      Old Machine             New Machine
>1                               0.0000480413            0.0000369549
>2                               0.8930709958            0.4044570327
>3                               1.4173783064            0.5722350279
>4                               0.9450037479            1.7844890058
>5                               1.1190732002            1.8621887922
>10                              1.0132551908            2.2462723970
>20                              1.3192131996            2.4642879009
>30                              1.1591543992            2.5852736672
>Again, the new machine chokes after a fourth mysql process.
>I'm still confused by what might be causing this, but this Usenet post
>might have something to do with it...
>Subject : performance bug in glibc2.1 linux 2.2?
>Date: 1999/05/06
>Has anyone encountered anything similar? I guess this will force us to
>retreat to glibc 2.0, but I'd like to know whether anyone found a better
>Please check "" before
>posting. To request this thread, e-mail mysql-thread5841@stripped
>To unsubscribe, send a message to the address shown in the
>List-Unsubscribe header of this message. If you cannot see it,
>e-mail mysql-unsubscribe@stripped instead.

Get Free Email and Do More On The Web. Visit
Persistent connections to db?Tom Cunningham23 Jun
  • Re: Persistent connections to db?Paul DuBois23 Jun
    • Re: Persistent connections to db?Tom Cunningham23 Jun
      • Re: Persistent connections to db?Daniel Koch23 Jun
        • DBD::mysql fails on two tests?Tom Cunningham24 Jun
          • glibc 2.1 performanceTom Cunningham25 Jun
            • Re: glibc 2.1 performance(Paul D. Smith)25 Jun
              • Re: glibc 2.1 performanceTom Cunningham25 Jun
                • Re: glibc 2.1 performanceathompso28 Jun
    • Re: Persistent connections to db?ed23 Jun
Re: glibc 2.1 performanceAndrew Dunstan25 Jun