mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* MYSQL,Linux & large threads number
@ 2002-03-15 13:30 Peter Zaitsev
  2002-03-15 14:01 ` Sinisa Milivojevic
  2002-03-18 19:35 ` Bill Davidsen
  0 siblings, 2 replies; 3+ messages in thread
From: Peter Zaitsev @ 2002-03-15 13:30 UTC (permalink / raw)
  To: mysql; +Cc: linux-kernel

Hello mysql,

  Some time ago I wrote about slow down of mysql with large number of
  threads, which is quite common in Linux-Apache-Mysql-PHP enviroment.

  The test was simulating the worst case of concurrency - all the
  threads are modified global variable in a loop 5000000 times in
  total, using standard mutex for synchronization. The yeild is used
  in a loop to force even more fair distribution of lock usage by
  threads and increase context switches, therefore it did not change
  much with large number of threads. I.e with 64 threads time without
  yeild is 1:33.5

  Test was run on PIII-500 1G RAM Kernel 2.4.18. 3 runs were made for
  each number of threads and best results were taken:

 Num threads.       Time      Peak cs rate.
    2               53.4          179518
    4               53.8          144828
    16              1:06.3         85172
    64              1:48.1         48394
    256             8:10.6         10235
    1000           36:46.2          2602


The surprising thing is the time grows in less then linear way for up
to 64 threads but later it stars to go linear way or even worse. May
be this is because some other process are sleeping in the system which
also is used in scheduling.


For Next test I'll try to use Ingo's scheduler to see if it helps to
solve the problem, also I'll try to test real mysql server to see
which slowdown it will have.




CODE: (Dumb one just for test)

  
#include <stdio.h>
#include <pthread.h>
#include <time.h>
#define NUM_TH 1000

#define TOTAL_VALUE 5000000

#define LOOP (TOTAL_VALUE/NUM_TH)

pthread_t th[NUM_TH];
int thread_data[NUM_TH];

int rc,rc2;

int global=0;

pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t start = PTHREAD_MUTEX_INITIALIZER;


void f(int *thn)
 {
 int i;  
 pthread_mutex_lock(&start);
 pthread_mutex_unlock(&start);
 for (i=0;i<LOOP;i++)
  { 
   pthread_mutex_lock(&mut);
   global++;
   pthread_yield();
   pthread_mutex_unlock(&mut);
  }
 } 



main()
 { 
  int i;
  pthread_mutex_lock(&start);                                                                                                 
  for (i=0;i<NUM_TH;i++)
  {
   thread_data[i]=i;
   rc=pthread_create(&th[i],NULL,f,&thread_data[i]);
   if (rc!=0)
    {
      printf("Failed to create thread #%d errorcode:%d\n",i,rc);
    } 
  }
  pthread_mutex_unlock(&start); 

 for (i=0;i<NUM_TH;i++)
  {
   rc2=pthread_join(th[i],NULL);    
  }
 printf("Global Value: %d\n",global); 

 }   

-- 
Best regards,
 Peter                          mailto:pz@spylog.ru


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: MYSQL,Linux & large threads number
  2002-03-15 13:30 MYSQL,Linux & large threads number Peter Zaitsev
@ 2002-03-15 14:01 ` Sinisa Milivojevic
  2002-03-18 19:35 ` Bill Davidsen
  1 sibling, 0 replies; 3+ messages in thread
From: Sinisa Milivojevic @ 2002-03-15 14:01 UTC (permalink / raw)
  To: pz; +Cc: mysql, linux-kernel

Peter Zaitsev writes:
> Hello mysql,
> 
>   Some time ago I wrote about slow down of mysql with large number of
>   threads, which is quite common in Linux-Apache-Mysql-PHP enviroment.
> 
>   The test was simulating the worst case of concurrency - all the
>   threads are modified global variable in a loop 5000000 times in
>   total, using standard mutex for synchronization. The yeild is used
>   in a loop to force even more fair distribution of lock usage by
>   threads and increase context switches, therefore it did not change
>   much with large number of threads. I.e with 64 threads time without
>   yeild is 1:33.5
> 
>   Test was run on PIII-500 1G RAM Kernel 2.4.18. 3 runs were made for
>   each number of threads and best results were taken:
> 
>  Num threads.       Time      Peak cs rate.
>     2               53.4          179518
>     4               53.8          144828
>     16              1:06.3         85172
>     64              1:48.1         48394
>     256             8:10.6         10235
>     1000           36:46.2          2602
> 

I hope you are using latest glibc 2.2 with our patches applied.

Also please try adaptive mutex. How to set it, take a look at
mysys/my_thr_init.c.

-- 
Regards,
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /    Mr. Sinisa Milivojevic <sinisa@mysql.com>
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB, Fulltime Developer
/_/  /_/\_, /___/\___\_\___/   Larnaca, Cyprus
       <___/   www.mysql.com


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: MYSQL,Linux & large threads number
  2002-03-15 13:30 MYSQL,Linux & large threads number Peter Zaitsev
  2002-03-15 14:01 ` Sinisa Milivojevic
@ 2002-03-18 19:35 ` Bill Davidsen
  1 sibling, 0 replies; 3+ messages in thread
From: Bill Davidsen @ 2002-03-18 19:35 UTC (permalink / raw)
  To: Peter Zaitsev; +Cc: mysql, linux-kernel

On Fri, 15 Mar 2002, Peter Zaitsev wrote:

> Hello mysql,
> 
>   Some time ago I wrote about slow down of mysql with large number of
>   threads, which is quite common in Linux-Apache-Mysql-PHP enviroment.
> 
>   The test was simulating the worst case of concurrency - all the
>   threads are modified global variable in a loop 5000000 times in
>   total, using standard mutex for synchronization. The yeild is used
>   in a loop to force even more fair distribution of lock usage by
>   threads and increase context switches, therefore it did not change
>   much with large number of threads. I.e with 64 threads time without
>   yeild is 1:33.5


> For Next test I'll try to use Ingo's scheduler to see if it helps to
> solve the problem, also I'll try to test real mysql server to see
> which slowdown it will have.

I think it would be instructive to try using NGPT and either a patched
kernel or 2.4.19-pre3 which has the extra system calls included. I make no
predictions, but large improvements have been noted with a large number of
threads.

> 
> 
> 
> 
> CODE: (Dumb one just for test)
> 
>   
> #include <stdio.h>
> #include <pthread.h>
> #include <time.h>
> #define NUM_TH 1000

You might want to read this from the command line as an option and malloc
the vecors. Just a thought, I'm bad at guessing how lare a test I may want
to run.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-03-18 19:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-15 13:30 MYSQL,Linux & large threads number Peter Zaitsev
2002-03-15 14:01 ` Sinisa Milivojevic
2002-03-18 19:35 ` Bill Davidsen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®