On Tue, Jul 06, 2004 at 08:05:43PM -0400, Charles Sprickman wrote: > On Tue, 6 Jul 2004, Jeremy Zawodny wrote: > > > > procs memory page disks faults cpu > > > r b w avm fre flt re pi po fr sr da0 md0 in sy cs us sy > > > > > > 0 13 0 782108 61388 748 0 0 0 863 0 13 0 399 3756 276 23 95 > > > 2 13 0 788184 59172 2350 0 0 0 1394 0 73 0 424 7918 1142 29 90 > > > > Wow. > > > > If I've reassembled your vmstat output correctly, you're burning A LOT > > of system time. :-( > > You read it right. Lots. > > > Well, I've seen machines witth cs numbers at lest 20 times that high > > and they were still getting some work done. (It was part of a MyQSL > > benchmark I ran, in fact.) > > Interesting. I'm not really more than about 70% sure of what a "context > switch" is, my best read of it is that it's bad when those numbers go up > because the scheduler is inefficiently juggling process around in the run > queue...
A context switch is anytime the CPU switches processes or goes from user space back to kernel space. So a lot of syscalls would certainly do this. > > Yeah, you're not doing much I/O at all. Hmm. > > Yep, hmmm indeed. :) > > > Well, they're really apples and oranges. But I think you problem is > > *not* MySQL. It sounds as though you still have trouble with > > LinuxThreads, so I'd look at qmail. I'd try tracing (via truss) some > > of qmail's procs to see what they heck they're doing. Maybe they're > > needlessly making A LOT of syscalls? > > I've worked with some much larger qmail installs, and the brick wall we > hit in scaling it up is very similar; the box just seems to drown in > syscalls. I think this is a "feature" of qmail; even if you're not very > familiar with it, the basic gist is that a message goes from process to > process rather than having a monolithic process like sendmail. At some > point, I'm thinking this just doesn't scale well (we had trouble doing > more than 2000 or so concurrent remote deliveries on a dual xeon box). Yikes. And to think that I always stayed away for philosophical reasons alone. :-) > > No, the memory is almost all shared, so memory overhead isn't an > > issue. > > Excellent, that's very good to know. > > > > -Most queries are simple selects to grab user info (check password, check > > > "homedir"). > > > > Using the query cache at all? > > Not sure... I'm using the values for caches and whatnot from the > my-large.cnf in the distribution. The my-large.cnf I'm looking at has a 16M query cache, but doesn't explicitly turn it on. See what "show variables like 'query_ca%" says: mysql> show variables like 'query_ca%'; +-------------------+----------+ | Variable_name | Value | +-------------------+----------+ | query_cache_limit | 1048576 | | query_cache_size | 33554432 | | query_cache_type | DEMAND | +-------------------+----------+ 3 rows in set (0.01 sec) You see "demand" there because we set query_cache_type = 2. But if you had "= 1" you should see either "ON" or "ENABLED", I don't remember which. If not, it's probably OFF or DISABLED. > > > Also, out of curiousity, the db servers that you've mentioned Yahoo is > > > running are all likely dedicated mysql boxes, right?No dual-purpose > > > stuff, correct? > > > > That's accurate for the majority of servers, yes. But not because > > apache and MySQL don't co-habitate well. It's because the raito of > > "apache machines" to "mysql machines" needed is rarely 1:1. > > Yeah, I was just hoping to find someone with a similar setup to see how > their box is behaving. Well, we've run MySQL on the same box as various things (Bugzilla, RT, etc) and never had problems like that. From what you've described about qmail, I can understand why. > > You'd think, yeah. I don't know squat about qmail, having moved from > > Sendmail to Exim a few years back. Maybe it really hammers systems? > > Apparently. I've started playing with Postfix a bit more and I find it to > be much nicer than qmail. But for the foreseeable future I'm stuck with > qmail. If I feel real brave I'll raise the syscall issue on the qmail > list. Good luck with that. :-) Jeremy -- Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo! <[EMAIL PROTECTED]> | http://jeremy.zawodny.com/ [book] High Performance MySQL -- http://highperformancemysql.com/ -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
