On 5/19/06, Lyle Tagawa <[EMAIL PROTECTED]> wrote:
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.
That's because ignoring cpu and query complexity isn't generally done. Sure, you can run a zillion queries per second if all you're doing is "SELECT num from table;". But really threads are limited by memory usage, of which the total might be up to: innodb_buffer_pool_size + key_buffer_size + max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size) + max_connections*2MB (1 cxn = 1 thread. Remember that a replication master uses 1 thread per slave, and a replication slave uses 2 threads). The more memory a query uses, the fewer threads you can have. If your application is a reporting one, you want fewer threads with more memory allocated. If your application is a high-volume one, you want to keep your queries as light as possible. CPU speed and disk speed (I/O / seeking) definitely factor into things, because the faster they are, the faster queries will finish, and you'll have fewer concurrent threads. Also making sure that your logs and data use different seeks (ie, are on different disks) will help. Ignoring query complexity means that any number you come up with is pretty useless -- it doesn't usually matter what the performance is if you're not using representative queries. Unless this is theoretical research for a thesis. You really wouldn't want to tell your boss that "ignoring complexity, if we buy this machine we can have this performance!" -- your boss will forget the first part and then get upset that the machine doesn't have the performance you promised. -Sheeri -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
