Re: mysqlstat (WAS Re: Optimizing Ext3 for MySQL)
Jeremy Zawodny wrote: Now, I just have to remember to push out mytop 1.3 so that folks can shake out any new bugs I've introduced... Just make it one binary that recognizes its argv[0] calling (like gzip) and also supports command-line options. The two data collection methods are the same ... so you might as well have essentially `alias mysqlstat $x='mytop --vmstat=$x'` (yes, I know that's not valid bash symantics). -- Michael T. Babcock C.T.O., FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: mysqlstat (WAS Re: Optimizing Ext3 for MySQL)
Hmm. mytop 1.4 will have a feature that may help you 1.4? I'm still on 1.0. Guess I'm behind the curve. Jeremy, can you add something to protect against binary data coming across in a query and messing up the terminal window? Leave it running a while and all of a sudden it is a big mess. Yikes! It'll sorta like a vmstat the watches the output of SHOW STATUS, mostly the Com_* counters Poor man's version: watch mysqladmin extended-status Sincerely, Steven Roussey http://Network54.com/ query,sql,stuff,cool - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: mysqlstat (WAS Re: Optimizing Ext3 for MySQL)
On Wed, Jan 22, 2003 at 06:06:51PM -0800, Steven Roussey wrote: Hmm. mytop 1.4 will have a feature that may help you 1.4? I'm still on 1.0. Guess I'm behind the curve. Well, 1.3 is sitting in my CVS tree. I just need to update the docs and changelog. I already have some patches pending for 1.4... Heh. Jeremy, can you add something to protect against binary data coming across in a query and messing up the terminal window? Leave it running a while and all of a sudden it is a big mess. Yikes! Oh, good idea. I'd never run into that, but I can see how that'd be a prolbem. I'll make sure there's a binary filtering option added. It'll sorta like a vmstat the watches the output of SHOW STATUS, mostly the Com_* counters Poor man's version: watch mysqladmin extended-status One of my favorite Borg quotes is: Crude but effective. :-) Jeremy -- Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo! [EMAIL PROTECTED] | http://jeremy.zawodny.com/ MySQL 4.0.8: up 4 days, processed 123,404,209 queries (335/sec. avg) - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: mysqlstat (WAS Re: Optimizing Ext3 for MySQL)
One of my favorite Borg quotes is: Crude but effective. :-) I like that. ;) This got me thinking again about a feature I'd like to see in mysqld. I'd like to add something like SQL_STATISTICS to SELECT/UPDATE/INSERT statements. The idea would be that if this keyword was used, then mysqld would calculate additional statistics for that query (which you could get later with SHOW SQL_STATISTICS or something). The statistics would include actual numbers from the processing of the query: # of index records read # of data section records read # bytes requested from file system (read write) [this being the most important] # CPU time # Disk read, write, and wait times etc... Such information would be extremely valuable. For example, it wasn't until I put fulltext on separate server that I would discover what a disk read hog it was: Main server: 3000 q/s Disk read: 540 KB/sLoad: 1 FTS server: 2 q/s Disk read: 7600 KB/sLoad: 12 (taken from http://marc.theaimsgroup.com/?l=mysqlm=104042853614294w=2) Sadly, I will have to write my own FTS system soon. I'll be using mysql to do it, so hopefully Serg will be able to port whatever ideas I settle on back inside the mysqld engine (assuming they worth porting!!) I'll start by moving the ideas of the cosine vector search from C to SQL. Then I can try a lot of different things without constant re-compiling. I'll also get the advantage of having it work with several languages on a record basis, rather than a table basis... Now if only I had a paying job, I could focus on it and get it done quicker... Sincerely, Steven Roussey http://Network54.com/ - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail [EMAIL PROTECTED] To unsubscribe, e-mail [EMAIL PROTECTED] Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
