It's great to see that there is a potential progress space of performance:)
So, the advantage of letting drizzled to do context switch briefly lies on two facts:- Drizzled has more knowledge to decide when and where to switch context so as to avoid unnecessary switches. - We are able to do it at lower overhead (both CPU time and memory). We should make a user level thread to yield, when it gets blocked on locks, condition vars or I/Os. So we should use pthread_mutex_trylock on mutex, pthread_cond_timedwait on condition vars and non-block socket on I/Os. And add a yield(Session*) entry to the scheduler interface so that the session running on a user level thread could yield when failed to get a lock or read data from a socket fd. Changing the socket to non-blocking would be a big work as we have to modify the current I/O working mode. It seems the work will be concerning badly on I/Os of Drizzle which is quite new to me. Any suggestions on getting familiar with drizzle I/Os quickly? On Mon, May 11, 2009 at 12:36 PM, Stewart Smith <[email protected]>wrote: > On Sun, May 10, 2009 at 12:47:26PM -0700, Eric Day wrote: > > The drizzled process (scheduler plugin) would be the one doing the > > context switching. This would make it more efficient because drizzled > > has better context of when to switch, and you don't have the jump to > > kernel space. There are obviously some drawbacks here, and the issue > > of how portable this will be, but Stewart thinks it will be doable. > > > > Stewart, want to add anything? :) > > Sure, make me think :) > > If you look at the getcontext/setcontext man page: > > In a System V-like environment, one has the two types mcontext_t and > > ucontext_t defined in <ucontext.h> and the four functions getcontext(), > > setcontext(), makecontext(3) and swapcontext(3) that allow user-level > > context switching between multiple threads of control within a process. > > Which lets you implement co-operative threading in user space. > > The idea behind doing this is: > - with many connections (1,000+): > - the overhead of the OS context switching gets non-trivial > - the context switches happen at non-optimal points. i.e. we could > get better throughput/response time if we only switched at logical > points such as on blocking IO, mutex contention etc. > - The OS doesn't have enough knowledge to do some things (e.g. > there is likely no point in context switching during parsing... it's > just going to thrash the cache and make perf suck) > > - with huge numbers (10,000): > - ever try having another process get any CPU time with 10,000 > database threads running? It would be nice to still be able to SSH into > the box or to have the "help, i'm overloaded" monitoring process get > enough CPU time to report that. > > - there are some things we can only do with real knowledge of what's > going on > - we could work out how long it may take to get to processing an > incoming connection and return EBUSY - better handling situations where > we're severely overloaded by continuing to service all we can and > providing useful error messages back to users. > > - kind of interesting micro-optimisations > - task_struct in linux is close to 2kb. for 10,000 connections, > this means we're using 20MB of memory just for the task_struct - > ignoring all the other bits of memory hanging around in kernel (e.g. the > stack for that task). If you count the 4kb stack, we're looking at over > 60MB of memory just for kernel structures tracking 10,000 database > connections. > - we should be able to get away with a bit less > considering that struct ucontext is only: > struct ucontext { > unsigned long uc_flags; > struct ucontext *uc_link; > stack_t uc_stack; > struct sigcontext uc_mcontext; > sigset_t uc_sigmask; > }; > > - pid_t deafults to max out at 32,768.... would be nice not to > hit it. > > -- > Stewart Smith > -- Cheers. Biping MENG Natural Language Processing(NLP) Lab Dept. of Computer Science and Technology Nanjing University
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
