Re: am I alone? (scale)
hey.. thanks for the info... This is the my.cnf file that i'm using - [mysqld] skip-locking set-variable= key_buffer=640M set-variable= max_allowed_packet=10M set-variable= table_cache=640 set-variable= sort_buffer=6M set-variable= record_buffer=6M set-variable= thread_cache=16 set-variable= thread_concurrency=16 set-variable= myisam_sort_buffer_size=64M log-bin server-id = 1 set-variable= max_connections=2000 set-variable= max_connect_errors=1 set-variable= back_log=2900 set-variable= connect_timeout=15 set-variable= wait_timeout=57600 set-variable= interactive_timeout=57600 Now the problem that i've managed to track down is - When the CPU hits 100%, mysql crashes. This behaviour has been consistent across many many runs. I would definitely not like the database server to crash. A loss in performance is expected but a crash is most definitely not. As u can see, the limits are set pretty high on the system. Memory usage is not even 150MB. What's the reason? and the partial backtrace that i'm getting is the same after every crash. Any ideas? Tx. Vinod. Do You Yahoo!? Get your free @yahoo.co.in address at http://mail.yahoo.co.in - 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: am I alone? (scale)
We've had fairly bad luck with Linux 2.2.X and SMP for any kind of high-end system. The DAC 960 SCSI controllers proved to be fairly problematic in this environment. Sometimes updating the drivers helps. We have a couple of systems that run much better when we do not use one of the CPUs. Just to offer another data point, we've had great luck with SMP Linux 2.2.x and the DAC 960 controller (a Mylex AcceleRAID 352). Debian Potato Linux 2.2.17 SMP, up 134 days. MySQL 3.23.32 up 39 days, Queries/second avg: 753. It's a dual 933 PIII w/2gb ram. No table corruption. We don't even use precompiled binaries ;) Obviously one person's good experience doesn't mean there's not a problem somewhere, but we sure haven't had any trouble, and it's not for lack of hammering on it. -- Pete Harlan [EMAIL PROTECTED] - 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: am I alone? (scale)
Justin writes:
Thank you Sinisa,
I actually did try the upgade, but rapidly reverted due to errors
such as these:
mysqld got signal 11;
stack range sanity check, ok, backtrace follows
0x812cfea
0x809f541
0x809da87
:
:
etc
AND...
read_const: Got error 127 when reading table ./
read_next_with_key: Got error 134 when reading table ./
read_cost: Got error 134 when reading table ./...
(sometimes dozens and dozens repeated.. re-optimizing the
table may cure them for a short while. Again this was only
on the largest/busiest few tables).
So I went back to the previous last snap of the 3.22
On the threads / glibc issue: I'm using the *statically linked*
version of mysqld from your download page, in both 3.23 (that gave
erros above), and 3.22 (that gives corrupt indexes), therefore my
understanding was that glibc / linux threads issues would not
be an issue? is that understanding incorrect?
What else in a 2.2.14 SMP kernel can cause a problem for
statically linked 3.22 or 3.23 ? I would need some clearer
explanation before making a new kernel.
By the way, we bought the $1000 support license last week,
but so far have not got into your supportwizard site.. I've
emailed support@ about this. Just so you don't think we're
not willing to pay for some attention.
thanks
-Justin
Hi!
Regarding SMP, there have been some reports on the kernel list.
But you should upgrade !!
Before that , please check and repair all corrupted tables, because,
as so many users on this list know, corrupted table(s) may crash
MySQL.
Regards,
Sinisa
__ _ _ ___ == MySQL AB
/*/\*\/\*\ /*/ \*\ /*/ \*\ |*| Sinisa Milivojevic
/*/ /*/ /*/ \*\_ |*| |*||*| mailto:[EMAIL PROTECTED]
/*/ /*/ /*/\*\/*/ \*\|*| |*||*| Larnaca, Cyprus
/*/ /*/ /*/\*\_/*/ \*\_/*/ |*|
/*/^^^\*\^^^
/*/ \*\Developers Team
-
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: am I alone? (scale)
On Saturday 10 March 2001 22:16, Justin wrote: Well thats good to know.. although this is sustained 24x7x365 linux 2.2.14-5.0smp, uptime 170 days but e2fsk ok's the the database partition, which is a mirror. in an attempt to get stability, I've been running on the official 3.22.32 mysql binary for a month now .. it hasn't helped. Typically indexes get corrupted and cause selects to malfunction, OR, cause mysqld to crash, OR cause count(*) or distinct(*) queries to run in infinite loops, but not necessarily on the corrupt table. it seems to me index corruption can poison the server beyond the afflicted table. We've had fairly bad luck with Linux 2.2.X and SMP for any kind of high-end system. The DAC 960 SCSI controllers proved to be fairly problematic in this environment. Sometimes updating the drivers helps. We have a couple of systems that run much better when we do not use one of the CPUs. If e2fsck says the partition is fine, then it might not be this problem. Best, Kyle -- Kyle Hayes Quicknet Technologies t: +1 415 864 5225 520 Townsend St. Suite D f: +1 415 864 8388 San Francisco, CA 94103 w: http://www.quicknet.net USA - 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: am I alone? (scale)
Justin writes:
What is your key buffer size? In my case, key buffer size is set
to 384mb .. and mysqld starts out small, perhaps 18mb and grows
within a day to 100mb, and within a few days to pretty much 300+mb
..so it is doing what one would expect it to.
The other mem parameters combine in ways explained in the memory
usage document.. so depending on those, I expect 300 threads could
eat a lot of memory, which is not returned to the OS.
-Justin
HI!
First of all, please listen to the advice on upgrading to the latest
3.23 binary and converting your tables to MyISAM format with a script
provided.
Second, there have been some problems with Linux SMP under high load
which seem to be solved with 2.4.* kernel and 2.2.* glibc.
Regards,
Sinisa
__ _ _ ___ == MySQL AB
/*/\*\/\*\ /*/ \*\ /*/ \*\ |*| Sinisa Milivojevic
/*/ /*/ /*/ \*\_ |*| |*||*| mailto:[EMAIL PROTECTED]
/*/ /*/ /*/\*\/*/ \*\|*| |*||*| Larnaca, Cyprus
/*/ /*/ /*/\*\_/*/ \*\_/*/ |*|
/*/^^^\*\^^^
/*/ \*\Developers Team
-
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: am I alone? (scale)
Justin wrote: What is your key buffer size? mysql show variables; ERROR 2006: MySQL server has gone away No connection. Trying to reconnect... Connection id:47881 Current database: *** NO ONE *** | | key_buffer_size | 16773120 In my case, key buffer size is set to 384mb .. and mysqld starts out small, perhaps 18mb and grows within a day to 100mb, and within a few days to pretty much 300+mb ..so it is doing what one would expect it to. Lets see: Key Buffer (16M) + (Threads (300) * (Stack (64K) + Net Buffer( 16K))) + Max Allow Packet (1M) + other stuff 16M * (300 * 81920) + 1M = 16M + 24M + 1M = 41M So it isn't the thread specific storage. I'm having trouble quantifying the maximum values for other uses of memory. Note, that typical memory allocation when the system is busy is 41M. I'm not sure what causes the jump to 150M+. Note, I'm not saying this is a bug. But it is an impediment to performance of a long running server. Also noted, this machine has 1GB of RAM and is dedicated to MySQL. I'm not quite sure why the performance drops off so much when the footprint gets over 150M. The other mem parameters combine in ways explained in the memory usage document.. so depending on those, I expect 300 threads could eat a lot of memory, which is not returned to the OS. -Justin On Sat, Mar 10, 2001 at 11:35:20PM -0800, Mike Wexler wrote: I have a server that averages 256 queries/sec. It maxes out at 1187 queries/sec. It averages about 100 threads and maxes out at about 300. I've never experienced the problems below with corrupted tables, but I have been experiencing an interesting problem lately. Normally the server uses about 20-40MB of memory as reported by top. After running for a week or so, the memory usage will spike to 150-250 MB. Of course this causes additional paging, which slows the server down, which causes the CGI scripts that talk to the server to take longer to complete, which creates more instances of the CGI scripts, which creates more threads, which creates more memory usage in the server. Any idea, what might be causing the memory usage to spike in the first place? Any ideas how to prevent it? "Jeremy D. Zawodny" wrote: On Sun, Mar 11, 2001 at 01:16:20AM -0500, Justin wrote: Well thats good to know.. although this is sustained 24x7x365 My average rate over the last 67 days is about 52/second. In reality we have some periods of much higher load (several hundred per second) and some of much lower load. It is just about to hit the 300,000,000 query mark since it was last shut down (for the upgrade 67 days ago). I'd like to hit a billion queries before the next downtime, but who knows... I'm currently running 3.23.29-gamma using the staticly linked version from mysql.com. in an attempt to get stability, I've been running on the official 3.22.32 mysql binary for a month now .. it hasn't helped. I'd highly recommend upgrading to 3.23.xx. You should see better performance with MyISAM tables. I'd also highly recommend using a static binary from the mysql web site. Typically indexes get corrupted and cause selects to malfunction, OR, cause mysqld to crash, OR cause count(*) or distinct(*) queries to run in infinite loops, but not necessarily on the corrupt table. it seems to me index corruption can poison the server beyond the afflicted table. Certainly can. If a thread starts to suck cpu time, the whole system will suffer and start to spiral down into places you'd rather not look. Jeremy -- Jeremy D. Zawodny, [EMAIL PROTECTED] Technical Yahoo - Yahoo Finance Desk: (408) 328-7878Fax: (408) 530-5454 Cell: (408) 439-9951 - 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 -- Justin Beech http://www.dslreports.com Phone:212-269-7052 x252 FAX inbox: 212-937-3800 mailto:[EMAIL PROTECTED] --- http://dslreports.com/contacts - 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: am I alone? (scale)
Thank you Sinisa,
I actually did try the upgade, but rapidly reverted due to errors
such as these:
mysqld got signal 11;
stack range sanity check, ok, backtrace follows
0x812cfea
0x809f541
0x809da87
:
:
etc
AND...
read_const: Got error 127 when reading table ./
read_next_with_key: Got error 134 when reading table ./
read_cost: Got error 134 when reading table ./...
(sometimes dozens and dozens repeated.. re-optimizing the
table may cure them for a short while. Again this was only
on the largest/busiest few tables).
So I went back to the previous last snap of the 3.22
On the threads / glibc issue: I'm using the *statically linked*
version of mysqld from your download page, in both 3.23 (that gave
erros above), and 3.22 (that gives corrupt indexes), therefore my
understanding was that glibc / linux threads issues would not
be an issue? is that understanding incorrect?
What else in a 2.2.14 SMP kernel can cause a problem for
statically linked 3.22 or 3.23 ? I would need some clearer
explanation before making a new kernel.
By the way, we bought the $1000 support license last week,
but so far have not got into your supportwizard site.. I've
emailed support@ about this. Just so you don't think we're
not willing to pay for some attention.
thanks
-Justin
On Sun, Mar 11, 2001 at 02:21:55PM +0200, Sinisa Milivojevic wrote:
Justin writes:
What is your key buffer size? In my case, key buffer size is set
to 384mb .. and mysqld starts out small, perhaps 18mb and grows
within a day to 100mb, and within a few days to pretty much 300+mb
..so it is doing what one would expect it to.
The other mem parameters combine in ways explained in the memory
usage document.. so depending on those, I expect 300 threads could
eat a lot of memory, which is not returned to the OS.
-Justin
HI!
First of all, please listen to the advice on upgrading to the latest
3.23 binary and converting your tables to MyISAM format with a script
provided.
Second, there have been some problems with Linux SMP under high load
which seem to be solved with 2.4.* kernel and 2.2.* glibc.
Regards,
Sinisa
__ _ _ ___ == MySQL AB
/*/\*\/\*\ /*/ \*\ /*/ \*\ |*| Sinisa Milivojevic
/*/ /*/ /*/ \*\_ |*| |*||*| mailto:[EMAIL PROTECTED]
/*/ /*/ /*/\*\/*/ \*\|*| |*||*| Larnaca, Cyprus
/*/ /*/ /*/\*\_/*/ \*\_/*/ |*|
/*/^^^\*\^^^
/*/ \*\Developers Team
--
Justin Beech http://www.dslreports.com
Phone:212-269-7052 x252 FAX inbox: 212-937-3800
mailto:[EMAIL PROTECTED] --- http://dslreports.com/contacts
-
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
am I alone? (scale)
Today I was having more index corruption problems.. the fact that it typically happens on the *biggest* and *busiest* tables leads me to believe that the request rate on my database might be right off the scale compared to other users, who are not reporting corruptions nearly as often. My corruption issues on any given table seem to have risen as a function of average request ratio times table size. Please, if you can do a mysqladmin extended-status and report to me or the list what your questions/uptime is if it is = where I am, and whether or not you need to to use isamchk frequently, or if you have no issues. Today the ratio is currently 304 (3.7million questions and 12000 seconds of uptime), but weekdays it is over 500 / sec .. thanks -justin - 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: am I alone? (scale)
On Sat, Mar 10, 2001 at 06:41:20PM -0500, Justin wrote: Today I was having more index corruption problems.. the fact that it typically happens on the *biggest* and *busiest* tables leads me to believe that the request rate on my database might be right off the scale compared to other users, who are not reporting corruptions nearly as often. My corruption issues on any given table seem to have risen as a function of average request ratio times table size. Please, if you can do a mysqladmin extended-status and report to me or the list what your questions/uptime is if it is = where I am, and whether or not you need to to use isamchk frequently, or if you have no issues. Today the ratio is currently 304 (3.7million questions and 12000 seconds of uptime), but weekdays it is over 500 / sec .. Hm... I've had numbers higher than that for several hours at a time without trouble. What OS are you on? Did you compile your own mysql, or are you using one of the provided binaraies? Jeremy -- Jeremy D. Zawodny, [EMAIL PROTECTED] Technical Yahoo - Yahoo Finance Desk: (408) 328-7878Fax: (408) 530-5454 Cell: (408) 439-9951 - 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: am I alone? (scale)
Well thats good to know.. although this is sustained 24x7x365 linux 2.2.14-5.0smp, uptime 170 days but e2fsk ok's the the database partition, which is a mirror. in an attempt to get stability, I've been running on the official 3.22.32 mysql binary for a month now .. it hasn't helped. Typically indexes get corrupted and cause selects to malfunction, OR, cause mysqld to crash, OR cause count(*) or distinct(*) queries to run in infinite loops, but not necessarily on the corrupt table. it seems to me index corruption can poison the server beyond the afflicted table. -Justin On Sat, Mar 10, 2001 at 05:13:30PM -0800, Jeremy D. Zawodny wrote: Today the ratio is currently 304 (3.7million questions and 12000 seconds of uptime), but weekdays it is over 500 / sec .. Hm... I've had numbers higher than that for several hours at a time without trouble. What OS are you on? Did you compile your own mysql, or are you using one of the provided binaraies? Jeremy -- Jeremy D. Zawodny, [EMAIL PROTECTED] Technical Yahoo - Yahoo Finance Desk: (408) 328-7878Fax: (408) 530-5454 Cell: (408) 439-9951 - 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: am I alone? (scale)
On Sun, Mar 11, 2001 at 01:16:20AM -0500, Justin wrote: Well thats good to know.. although this is sustained 24x7x365 My average rate over the last 67 days is about 52/second. In reality we have some periods of much higher load (several hundred per second) and some of much lower load. It is just about to hit the 300,000,000 query mark since it was last shut down (for the upgrade 67 days ago). I'd like to hit a billion queries before the next downtime, but who knows... I'm currently running 3.23.29-gamma using the staticly linked version from mysql.com. in an attempt to get stability, I've been running on the official 3.22.32 mysql binary for a month now .. it hasn't helped. I'd highly recommend upgrading to 3.23.xx. You should see better performance with MyISAM tables. I'd also highly recommend using a static binary from the mysql web site. Typically indexes get corrupted and cause selects to malfunction, OR, cause mysqld to crash, OR cause count(*) or distinct(*) queries to run in infinite loops, but not necessarily on the corrupt table. it seems to me index corruption can poison the server beyond the afflicted table. Certainly can. If a thread starts to suck cpu time, the whole system will suffer and start to spiral down into places you'd rather not look. Jeremy -- Jeremy D. Zawodny, [EMAIL PROTECTED] Technical Yahoo - Yahoo Finance Desk: (408) 328-7878Fax: (408) 530-5454 Cell: (408) 439-9951 - 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: am I alone? (scale)
I have a server that averages 256 queries/sec. It maxes out at 1187 queries/sec. It averages about 100 threads and maxes out at about 300. I've never experienced the problems below with corrupted tables, but I have been experiencing an interesting problem lately. Normally the server uses about 20-40MB of memory as reported by top. After running for a week or so, the memory usage will spike to 150-250 MB. Of course this causes additional paging, which slows the server down, which causes the CGI scripts that talk to the server to take longer to complete, which creates more instances of the CGI scripts, which creates more threads, which creates more memory usage in the server. Any idea, what might be causing the memory usage to spike in the first place? Any ideas how to prevent it? "Jeremy D. Zawodny" wrote: On Sun, Mar 11, 2001 at 01:16:20AM -0500, Justin wrote: Well thats good to know.. although this is sustained 24x7x365 My average rate over the last 67 days is about 52/second. In reality we have some periods of much higher load (several hundred per second) and some of much lower load. It is just about to hit the 300,000,000 query mark since it was last shut down (for the upgrade 67 days ago). I'd like to hit a billion queries before the next downtime, but who knows... I'm currently running 3.23.29-gamma using the staticly linked version from mysql.com. in an attempt to get stability, I've been running on the official 3.22.32 mysql binary for a month now .. it hasn't helped. I'd highly recommend upgrading to 3.23.xx. You should see better performance with MyISAM tables. I'd also highly recommend using a static binary from the mysql web site. Typically indexes get corrupted and cause selects to malfunction, OR, cause mysqld to crash, OR cause count(*) or distinct(*) queries to run in infinite loops, but not necessarily on the corrupt table. it seems to me index corruption can poison the server beyond the afflicted table. Certainly can. If a thread starts to suck cpu time, the whole system will suffer and start to spiral down into places you'd rather not look. Jeremy -- Jeremy D. Zawodny, [EMAIL PROTECTED] Technical Yahoo - Yahoo Finance Desk: (408) 328-7878Fax: (408) 530-5454 Cell: (408) 439-9951 - 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 - 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: am I alone? (scale)
What is your key buffer size? In my case, key buffer size is set to 384mb .. and mysqld starts out small, perhaps 18mb and grows within a day to 100mb, and within a few days to pretty much 300+mb ..so it is doing what one would expect it to. The other mem parameters combine in ways explained in the memory usage document.. so depending on those, I expect 300 threads could eat a lot of memory, which is not returned to the OS. -Justin On Sat, Mar 10, 2001 at 11:35:20PM -0800, Mike Wexler wrote: I have a server that averages 256 queries/sec. It maxes out at 1187 queries/sec. It averages about 100 threads and maxes out at about 300. I've never experienced the problems below with corrupted tables, but I have been experiencing an interesting problem lately. Normally the server uses about 20-40MB of memory as reported by top. After running for a week or so, the memory usage will spike to 150-250 MB. Of course this causes additional paging, which slows the server down, which causes the CGI scripts that talk to the server to take longer to complete, which creates more instances of the CGI scripts, which creates more threads, which creates more memory usage in the server. Any idea, what might be causing the memory usage to spike in the first place? Any ideas how to prevent it? "Jeremy D. Zawodny" wrote: On Sun, Mar 11, 2001 at 01:16:20AM -0500, Justin wrote: Well thats good to know.. although this is sustained 24x7x365 My average rate over the last 67 days is about 52/second. In reality we have some periods of much higher load (several hundred per second) and some of much lower load. It is just about to hit the 300,000,000 query mark since it was last shut down (for the upgrade 67 days ago). I'd like to hit a billion queries before the next downtime, but who knows... I'm currently running 3.23.29-gamma using the staticly linked version from mysql.com. in an attempt to get stability, I've been running on the official 3.22.32 mysql binary for a month now .. it hasn't helped. I'd highly recommend upgrading to 3.23.xx. You should see better performance with MyISAM tables. I'd also highly recommend using a static binary from the mysql web site. Typically indexes get corrupted and cause selects to malfunction, OR, cause mysqld to crash, OR cause count(*) or distinct(*) queries to run in infinite loops, but not necessarily on the corrupt table. it seems to me index corruption can poison the server beyond the afflicted table. Certainly can. If a thread starts to suck cpu time, the whole system will suffer and start to spiral down into places you'd rather not look. Jeremy -- Jeremy D. Zawodny, [EMAIL PROTECTED] Technical Yahoo - Yahoo Finance Desk: (408) 328-7878Fax: (408) 530-5454 Cell: (408) 439-9951 - 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 -- Justin Beech http://www.dslreports.com Phone:212-269-7052 x252 FAX inbox: 212-937-3800 mailto:[EMAIL PROTECTED] --- http://dslreports.com/contacts - 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
