> 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
I agree with many of your points. We tuned our per-thread buffers appropriately and our physical RAM is usually 30-40% full. But, I can make some assumptions. I can ignore query complexity and cpu/disk speeds for example, if i simply change the pool of db readers without increasing or otherwise changing the number of queries (for example, adding more application servers to serve the same users). But, increasing the pool by itself forces the db to have to schedule more threads. Because, the hardware hasn't changed, I can disregard cpu/disk and can disregard memory as long as we have enough physical RAM. Thanks. Your response helps put my question into perspective. But, I think it would still be interesting to understand how far I can push this hardware without thrashing. Do other users see a similar problem, where load avg hovers at a reasonable value, then just skyrockets when a "magic" thread count is exceeded? And what thread library and/or process scheduling algo did you use to overcome this limitation? -lyle > 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]
