Hello, This question is for those with experience sizing their MySQL back-end.
I have one box running 3000 mysqld threads and serving 6000 qps, and is operating fine. The run queue is generally empty, but we observe ~20K context-switches/s. At some point, as usage increases, the run queue leaps from 0-1 to 10-20+ (box has 2 cpus, single-core and HT disabled) and the overhead from paging and/or context-switching becomes unbearable. These numbers are obviously specific for my os, hardware (rhel3/x86), and workload, but I am curious if there is a theoretical model that I can use to plan future installations. Given a nptl/linux box (or pthreads/freeBSD) for example, can you tell what is the theoretical max running thread count (in the context of paging/process scheduling and not in the context of memory sizing), assuming that there's no configuration-level cap on open files, etc. (i'd imagine we'd want to ignore cpu (and hence query complexity) and assume query caching is disabled, etc, for any theoretical model) I haven't come across this kind of tuning or capacity planning guide yet. Any pointers would be very helpful. Any anecdotes (your os, thread library, hardware, mysql thread counts and qps) would be appreciated as well. Thanks, Lyle -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
