Re: 3.23.51 bug ? ( was RE: Load problems with 3.23.51 )

2002-07-16 Thread Victoria Reznichenko

David,
Tuesday, July 16, 2002, 3:55:46 PM, you wrote:

DB> Same thing here, mysql 3.23.51 works well during about 2 hours then
DB> suddently load average grow up to 200 and more ...
DB> Load average is less than 4 with 3.23.49.

DB> We're using binary tar.gz non max versions from Mysql.com

DB> OS : Linux Red hat 7.2
DB> kernel : 2.4.10
DB> 1 Go RAM
DB> 2 * Intel 1 Ghz

We know about that bug and we are investigating it.


-- 
For technical support contracts, goto https://order.mysql.com/?ref=ensita
This email is sponsored by Ensita.net http://www.ensita.net/
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /Victoria Reznichenko
 / /|_/ / // /\ \/ /_/ / /__   [EMAIL PROTECTED]
/_/  /_/\_, /___/\___\_\___/   MySQL AB / Ensita.net
   <___/   www.mysql.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




3.23.51 bug ? ( was RE: Load problems with 3.23.51 )

2002-07-16 Thread David BORDAS

Hi list,

Same thing here, mysql 3.23.51 works well during about 2 hours then
suddently load average grow up to 200 and more ...
Load average is less than 4 with 3.23.49.

We're using binary tar.gz non max versions from Mysql.com

OS : Linux Red hat 7.2
kernel : 2.4.10
1 Go RAM
2 * Intel 1 Ghz

During the load pic i've run a ps -eo pid,tt,user,fname,tmout,f,wchan and
that's an extract of the output :
[...]
29309 ?mysqlmysqld   - 040 rt_sigsuspend
29347 ?mysqlmysqld   - 040 rt_sigsuspend
29390 ?mysqlmysqld   - 040 rt_sigsuspend
29391 ?mysqlmysqld   - 040 -
29417 ?mysqlmysqld   - 040 rt_sigsuspend
29418 ?mysqlmysqld   - 040 rt_sigsuspend
29420 ?mysqlmysqld   - 040 rt_sigsuspend
29423 ?mysqlmysqld   - 040 rt_sigsuspend
29424 ?mysqlmysqld   - 040 rt_sigsuspend
29425 ?mysqlmysqld   - 040 rt_sigsuspend
29428 ?mysqlmysqld   - 040 rt_sigsuspend
29432 ?mysqlmysqld   - 040 -
29433 ?mysqlmysqld   - 040 rt_sigsuspend
29434 ?mysqlmysqld   - 040 rt_sigsuspend
29436 ?mysqlmysqld   - 040 rt_sigsuspend
29439 ?mysqlmysqld   - 040 rt_sigsuspend
29442 ?mysqlmysqld   - 040 rt_sigsuspend
29443 ?mysqlmysqld   - 040 rt_sigsuspend
29445 ?mysqlmysqld   - 040 rt_sigsuspend
29448 ?mysqlmysqld   - 040 rt_sigsuspend
29450 ?mysqlmysqld   - 040 rt_sigsuspend
29451 ?mysqlmysqld   - 040 rt_sigsuspend
29453 ?mysqlmysqld   - 040 rt_sigsuspend
29454 ?mysqlmysqld   - 040 rt_sigsuspend
29455 ?mysqlmysqld   - 040 rt_sigsuspend
29458 ?mysqlmysqld   - 040 rt_sigsuspend
29462 ?mysqlmysqld   - 040 rt_sigsuspend
29463 ?mysqlmysqld   - 040 rt_sigsuspend
29464 ?mysqlmysqld   - 040 rt_sigsuspend
29465 ?mysqlmysqld   - 040 rt_sigsuspend
29468 ?mysqlmysqld   - 040 rt_sigsuspend
[...]

So we come back to 3.23.49 wich have a glibc bug and memory eating bug but
we can't upgrade to 3.23.51 :(

Thanks again.
David

NB : this is the my.cnf :
[mysqld]
port= 3306
socket = /tmp/mysql.sock
skip-locking
skip-name-resolve
set-variable= key_buffer=128M
set-variable= back_log=100
set-variable= record_buffer=1M
set-variable= sort_buffer=1M
set-variable= max_allowed_packet=1M
set-variable= thread_stack=128K
set-variable= max_connections=700
set-variable= max_connect_errors=100
set-variable= table_cache=256
set-variable= net_read_timeout=180
set-variable= net_write_timeout=180
set-variable= wait_timeout=3600
# Start logging
# log
[...]
- Original Message -
From: "Steven Roussey" <[EMAIL PROTECTED]>
To: "'Mysql'" < [EMAIL PROTECTED]   >
Sent: Friday, July 12, 2002 6:17 PM
Subject: RE: Load problems with 3.23.51


> Just a note: I tried MySQL 4.0.2 and it works fine. Seems to be only
> 3.23.51 built by MySQL itself that has the issue. Releases before, and
> now a release after (albeit a 4.0.x version) work fine.
>
> Sincerely,
> Steven Roussey
> http://Network54.com/?pp=e
>
> >
> > I have MySQL 3.23.47 running on our sever. I skipped 48 through 50 and
> > tried 51. No dice. It does not handle load, CPU and the load average
> go
> > through the roof. I'm using Red Hat Linux 7.2 and the official mysql
> > binaries. It appears to be slow to connect, causing 0.5 to 1.0 second
> > delay on connection. Using persistent connections from PHP does not
> make
> > much of a difference. I thought it might be the hostname lookup
> changes so
> > I chose skip-grant-tables. This doesn't actually skip the hostname
> lookup
> > though and had no effect.
> >
> > Most queries are shorter than 1 second so this problem causes
> catastrophic
> > problems by making queries last a multiple times longer, which make
> the
> > number of concurrent queries jump exponentially. This is a bad thing.
> And
> > sadly makes 3.23.51 unusable.
>





-
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: Load problems with 3.23.51 ( same here )

2002-07-16 Thread David BORDAS

Hi list,

Same thing here, mysql 3.23.51 works well during about 2 hours then
suddently load average grow up to 200 and more ...
Load average is less than 4 with 3.23.49.

We're using binary tar.gz non max versions from Mysql.com

OS : Linux Red hat 7.2
kernel : 2.4.10
1 Go RAM
2 * Intel 1 Ghz

During the load pic i've run a ps -eo pid,tt,user,fname,tmout,f,wchan and
that's an extract of the output :
[...]
29309 ?mysqlmysqld   - 040 rt_sigsuspend
29347 ?mysqlmysqld   - 040 rt_sigsuspend
29390 ?mysqlmysqld   - 040 rt_sigsuspend
29391 ?mysqlmysqld   - 040 -
29417 ?mysqlmysqld   - 040 rt_sigsuspend
29418 ?mysqlmysqld   - 040 rt_sigsuspend
29420 ?mysqlmysqld   - 040 rt_sigsuspend
29423 ?mysqlmysqld   - 040 rt_sigsuspend
29424 ?mysqlmysqld   - 040 rt_sigsuspend
29425 ?mysqlmysqld   - 040 rt_sigsuspend
29428 ?mysqlmysqld   - 040 rt_sigsuspend
29432 ?mysqlmysqld   - 040 -
29433 ?mysqlmysqld   - 040 rt_sigsuspend
29434 ?mysqlmysqld   - 040 rt_sigsuspend
29436 ?mysqlmysqld   - 040 rt_sigsuspend
29439 ?mysqlmysqld   - 040 rt_sigsuspend
29442 ?mysqlmysqld   - 040 rt_sigsuspend
29443 ?mysqlmysqld   - 040 rt_sigsuspend
29445 ?mysqlmysqld   - 040 rt_sigsuspend
29448 ?mysqlmysqld   - 040 rt_sigsuspend
29450 ?mysqlmysqld   - 040 rt_sigsuspend
29451 ?mysqlmysqld   - 040 rt_sigsuspend
29453 ?mysqlmysqld   - 040 rt_sigsuspend
29454 ?mysqlmysqld   - 040 rt_sigsuspend
29455 ?mysqlmysqld   - 040 rt_sigsuspend
29458 ?mysqlmysqld   - 040 rt_sigsuspend
29462 ?mysqlmysqld   - 040 rt_sigsuspend
29463 ?mysqlmysqld   - 040 rt_sigsuspend
29464 ?mysqlmysqld   - 040 rt_sigsuspend
29465 ?mysqlmysqld   - 040 rt_sigsuspend
29468 ?mysqlmysqld   - 040 rt_sigsuspend
[...]

So we come back to 3.23.49 wich have a glibc bug and memory eating bug but
we can't upgrade to 3.23.51 :(

Thanks again.
David

NB : this is the my.cnf :
[mysqld]
port= 3306
socket = /tmp/mysql.sock
skip-locking
skip-name-resolve
set-variable= key_buffer=128M
set-variable= back_log=100
set-variable= record_buffer=1M
set-variable= sort_buffer=1M
set-variable= max_allowed_packet=1M
set-variable= thread_stack=128K
set-variable= max_connections=700
set-variable= max_connect_errors=100
set-variable= table_cache=256
set-variable= net_read_timeout=180
set-variable= net_write_timeout=180
set-variable= wait_timeout=3600
# Start logging
# log
[...]
- Original Message -
From: "Steven Roussey" <[EMAIL PROTECTED]>
To: "'Mysql'" < [EMAIL PROTECTED]   >
Sent: Friday, July 12, 2002 6:17 PM
Subject: RE: Load problems with 3.23.51


> Just a note: I tried MySQL 4.0.2 and it works fine. Seems to be only
> 3.23.51 built by MySQL itself that has the issue. Releases before, and
> now a release after (albeit a 4.0.x version) work fine.
>
> Sincerely,
> Steven Roussey
> http://Network54.com/?pp=e
>
> >
> > I have MySQL 3.23.47 running on our sever. I skipped 48 through 50 and
> > tried 51. No dice. It does not handle load, CPU and the load average
> go
> > through the roof. I'm using Red Hat Linux 7.2 and the official mysql
> > binaries. It appears to be slow to connect, causing 0.5 to 1.0 second
> > delay on connection. Using persistent connections from PHP does not
> make
> > much of a difference. I thought it might be the hostname lookup
> changes so
> > I chose skip-grant-tables. This doesn't actually skip the hostname
> lookup
> > though and had no effect.
> >
> > Most queries are shorter than 1 second so this problem causes
> catastrophic
> > problems by making queries last a multiple times longer, which make
> the
> > number of concurrent queries jump exponentially. This is a bad thing.
> And
> > sadly makes 3.23.51 unusable.
>



-
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: Load problems with 3.23.51

2002-07-12 Thread Steven Roussey

Just a note: I tried MySQL 4.0.2 and it works fine. Seems to be only
3.23.51 built by MySQL itself that has the issue. Releases before, and
now a release after (albeit a 4.0.x version) work fine.

Sincerely,
Steven Roussey
http://Network54.com/?pp=e

> 
> I have MySQL 3.23.47 running on our sever. I skipped 48 through 50 and
> tried 51. No dice. It does not handle load, CPU and the load average
go
> through the roof. I'm using Red Hat Linux 7.2 and the official mysql
> binaries. It appears to be slow to connect, causing 0.5 to 1.0 second
> delay on connection. Using persistent connections from PHP does not
make
> much of a difference. I thought it might be the hostname lookup
changes so
> I chose skip-grant-tables. This doesn't actually skip the hostname
lookup
> though and had no effect.
> 
> Most queries are shorter than 1 second so this problem causes
catastrophic
> problems by making queries last a multiple times longer, which make
the
> number of concurrent queries jump exponentially. This is a bad thing.
And
> sadly makes 3.23.51 unusable.



-
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: Load problems with 3.23.51

2002-07-02 Thread Steven Roussey

Just an update: I installed a new fresh version of RedHat 7.3 (smp
Athlon) and a new copy of MySQL 3.23.51, but the problem remains. 

Sincerely,
Steven Roussey
http://Network54.com/?pp=e



-
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: Load problems with 3.23.51

2002-06-30 Thread Steven Roussey
elect
  994 ?root crond- 040 nanosleep
 1044 ?xfs  xfs  - 140 do_select
 1080 ?daemon   atd  - 040 nanosleep
 1112 ?root miniserv - 040 do_select
 1117 tty2 root mingetty - 100 read_chan
 1118 tty3 root mingetty - 100 read_chan
 1119 tty4 root mingetty - 100 read_chan
 1120 tty5 root mingetty - 100 read_chan
 1121 tty6 root mingetty - 100 read_chan
 1285 tty1 root mingetty - 100 read_chan
14125 ?root sshd - 140 do_select
  409 ?root php  - 000 nanosleep
 9097 ?root sshd - 140 do_select
 9099 pts/0root bash - 100 wait4
 9369 pts/0root safe_mys - 100 wait4
 9397 pts/0mysqlmysqld   - 100 do_select
 9399 pts/0mysqlmysqld   - 040 do_poll
 9400 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9401 pts/0mysqlmysqld   - 040 tcp_data_wait
 9402 pts/0mysqlmysqld   - 040 tcp_data_wait
 9403 pts/0mysqlmysqld   - 040 tcp_data_wait
9404 pts/0mysqlmysqld   - 040 tcp_data_wait
 9405 pts/0mysqlmysqld   - 040 tcp_data_wait
 9406 pts/0mysqlmysqld   - 040 tcp_data_wait
 9407 pts/0mysqlmysqld   - 040 tcp_data_wait
 9408 pts/0mysqlmysqld   - 040 tcp_data_wait
 9409 pts/0mysqlmysqld   - 040 tcp_data_wait
 9410 pts/0mysqlmysqld   - 040 tcp_data_wait
 9411 pts/0mysqlmysqld   - 040 tcp_data_wait
 9412 pts/0mysqlmysqld   - 040 tcp_data_wait
 9413 pts/0mysqlmysqld   - 040 tcp_data_wait
 9414 pts/0mysqlmysqld   - 040 tcp_data_wait
 9415 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9416 pts/0mysqlmysqld   - 040 tcp_data_wait
 9417 pts/0mysqlmysqld   - 040 tcp_data_wait
 9418 pts/0mysqlmysqld   - 040 tcp_data_wait
 9419 pts/0mysqlmysqld   - 040 tcp_data_wait
 9420 pts/0mysqlmysqld   - 040 tcp_data_wait
 9421 pts/0mysqlmysqld   - 040 tcp_data_wait

 9854 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9855 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9856 pts/0mysqlmysqld   - 040 tcp_data_wait
 9857 pts/0mysqlmysqld   - 040 tcp_data_wait
 9858 pts/0mysqlmysqld   - 040 tcp_data_wait
 9859 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9860 pts/0mysqlmysqld   - 040 tcp_data_wait
 9861 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9862 pts/0mysqlmysqld   - 040 tcp_data_wait
 9865 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9866 pts/0mysqlmysqld   - 040 tcp_data_wait
 9870 pts/0mysqlmysqld   - 040 tcp_data_wait
 9873 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9874 pts/0mysqlmysqld   - 040 tcp_data_wait
 9875 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9876 pts/0mysqlmysqld   - 040 tcp_data_wait
 9878 pts/0mysqlmysqld   - 040 rt_sigsuspend
 9885 pts/0root ps   - 100 -
 9886 pts/0root more - 000 read_chan

This is obviously different. 3.23.47 is in tcp_data_wait. 3.23.51 is
usually doing nothing (!) or in suspend. Odd.

Sincerely,
Steven Roussey
http://Network54.com/?pp=e

> -Original Message-
> From: Michael Bacarella [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, June 29, 2002 11:20 pm
> To: Steven Roussey
> Subject: Re: Load problems with 3.23.51
> 
> Can you humor me and try running the command:
> 
> ps -eo pid,tt,user,fname,tmout,f,wchan
> 
> on that system a few times? Mine was far too hosed for this command
> to ever get off the ground. I think that'd help determine
> if there's some syscall that's sucking up all that cpu.
> 
> -M




-
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: Load problems with 3.23.51

2002-06-30 Thread Jeremy Zawodny

On Sat, Jun 29, 2002 at 10:47:47PM -0700, Steven Roussey wrote:
> 
> Tomorrow I'll try doing my own compile with gcc3.1. Note the other
> guy that had the same problem that went away after he compiled it
> himself:

Even gcc 2.95.3 or .4 will work well based on what I've seen.  We can
still sustain > 1,000 qps during busy times with my custom-built
binary.

Jeremy
-- 
Jeremy D. Zawodny, <[EMAIL PROTECTED]>
Technical Yahoo - Yahoo Finance
Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936

MySQL 3.23.51: up 31 days, processed 675,953,685 queries (249/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: Load problems with 3.23.51

2002-06-29 Thread Steven Roussey

> Another option is to run the 3.23.51 server for a while and when you
> get a load problem do 'mysqladmin proc ext'.  This command should show
> us if MySQL is using more table scans than usual.

The load problem shows up immediately.

+--++
| Variable_name| Value  |
+--++
| Aborted_clients  | 172|
| Aborted_connects | 87 |
| Bytes_received   | 92732  |
| Bytes_sent   | 631789 |
| Com_admin_commands   | 0  |
| Com_alter_table  | 0  |
| Com_analyze  | 0  |
| Com_backup_table | 0  |
| Com_begin| 0  |
| Com_change_db| 990|
| Com_change_master| 0  |
| Com_check| 0  |
| Com_commit   | 0  |
| Com_create_db| 0  |
| Com_create_function  | 0  |
| Com_create_index | 0  |
| Com_create_table | 1  |
| Com_delete   | 8  |
| Com_drop_db  | 0  |
| Com_drop_function| 0  |
| Com_drop_index   | 0  |
| Com_drop_table   | 0  |
| Com_flush| 0  |
| Com_grant| 0  |
| Com_insert   | 49 |
| Com_insert_select| 0  |
| Com_kill | 0  |
| Com_load | 0  |
| Com_load_master_table| 0  |
| Com_lock_tables  | 0  |
| Com_optimize | 0  |
| Com_purge| 0  |
| Com_rename_table | 0  |
| Com_repair   | 0  |
| Com_replace  | 11 |
| Com_replace_select   | 0  |
| Com_reset| 0  |
| Com_restore_table| 0  |
| Com_revoke   | 0  |
| Com_rollback | 0  |
| Com_select   | 402|
| Com_set_option   | 0  |
| Com_show_binlogs | 0  |
| Com_show_create  | 0  |
| Com_show_databases   | 0  |
| Com_show_fields  | 0  |
| Com_show_grants  | 0  |
| Com_show_keys| 0  |
| Com_show_logs| 0  |
| Com_show_master_status   | 0  |
| Com_show_open_tables | 0  |
| Com_show_processlist | 2  |
| Com_show_slave_status| 0  |
| Com_show_status  | 46 |
| Com_show_tables  | 0  |
| Com_show_variables   | 0  |
| Com_slave_start  | 0  |
| Com_slave_stop   | 0  |
| Com_truncate | 0  |
| Com_unlock_tables| 0  |
| Com_update   | 183|
| Connections  | 316|
| Created_tmp_disk_tables  | 1  |
| Created_tmp_tables   | 5  |
| Created_tmp_files| 0  |
| Delayed_insert_threads   | 0  |
| Delayed_writes   | 0  |
| Delayed_errors   | 0  |
| Flush_commands   | 1  |
| Handler_delete   | 430|
| Handler_read_first   | 5  |
| Handler_read_key | 564|
| Handler_read_next| 5441   |
| Handler_read_prev| 0  |
| Handler_read_rnd | 62 |
| Handler_read_rnd_next| 3406   |
| Handler_update   | 172|
| Handler_write| 123|
| Key_blocks_used  | 773|
| Key_read_requests| 5199   |
| Key_reads| 770|
| Key_write_requests   | 1067   |
| Key_writes   | 133|
| Max_used_connections | 121|
| Not_flushed_key_blocks   | 0  |
| Not_flushed_delayed_rows | 0  |
| Open_tables  | 147|
| Open_files   | 193|
| Open_streams | 0  |
| Opened_tables| 155|
| Questions| 1662   |
| Select_full_join | 0  |
| Select_full_range_join   | 0  |
| Select_range | 16 |
| Select_range_check   | 0  |
| Select_scan  | 75 |
| Slave_running| OFF|
| Slave_open_temp_tables   | 0  |
| Slow_launch_threads  | 29 |
| Slow_queries | 54 |
| Sort_merge_passes| 0  |
| Sort_range   | 19 |
| Sort_rows| 52 |
| Sort_scan| 5  |
| Table_locks_immediate| 499|
| Table_locks_waited   | 188|
| Threads_cached   | 64 |
| Threads_created  | 122|
| Threads_connected| 58 |
| Threads_running  | 11 |
| Uptime   | 81 |
+--++

  8:15pm  up 1 day, 23:48,  1 user,  load average: 49.13, 15.49, 3.84

+-+--++-++--
+--+--+
| Id  | User | Host   | db  | Command| Time
| State| Info
|
+-+--++-++--
+--+--+
| 7   | webuser  

RE: Load problems with 3.23.51

2002-06-29 Thread Michael Widenius


Hi!

> "Steven" == Steven Roussey <[EMAIL PROTECTED]> writes:

Steven> I tried the skip-name-resolve and it had no effect. So there goes my
Steven> hypothesis. 

Steven> Here are the results from test:

Steven> Benchmark DBD suite: 2.14
Steven> Date of test:2002-06-24 11:19:19
Steven> Running tests on:Linux 2.4.16-0.13smp i686
Steven> Arguments:
Steven> Comments:
Steven> Limits from:
Steven> Server version:  MySQL 3.23.51 log



Steven> TOTALS  2098.00  436.22  126.65  562.87

The above looks quite ok.

On a Intel Xeon 2M cache, 4x700 Mhz, 2G, key_buffer=16M, gcc 3.1
machine I get:

TOTALS  3399.00  664.19  179.00  843.19

(This is a newer benchmark version with some new tests, but still
comparable)

So at least there is nothing strange with the basic MySQL queries on
the machine.

Now there are two different possible problems:

- A problem with the thread library that causes a problem when using
  many threads.
- Some query / specific feature that you use that is slower like
  before. (For example a query that doesn't use indexes anymore).

Could you by any change check by using the slow query log if there is
some specific query that is causing problems ?

Another option is to run the 3.23.51 server for a while and when you
get a load problem do 'mysqladmin proc ext'.  This command should show
us if MySQL is using more table scans than usual.

Regards,
Monty

-
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: Load problems with 3.23.51

2002-06-24 Thread Steven Roussey

I used the mysql builds myself. Funny thing is that I use your tool
'mytop', which is very cool by the way, to watch things and it pauses
for about 5-8 seconds when refreshing with .51 and is almost instant
with .47

Sincerely,
Steven Roussey
http://Network54.com/?pp=e

> -Original Message-
> As another data point for you, I've got 3.23.51 running on our master
> quite well.  The difference is that I built it from source (to get a
> critical InnoDB patch).  I don't recall which compiler the MySQL folks
> used (and which glibc), but my source build used Debian Woody's gcc
> 2.95.4.
> 
> That could have something to do with it...




-
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: Load problems with 3.23.51

2002-06-24 Thread Heikki Tuuri

Hi!

I just ran the standard

perl run-all-tests --small-test --small-tables --create-options=type=innodb

on 3.23.49a and an in-house prerelease of 3.23.51, on Linux 2.4.16. The
times were essentially the same.

3.23.50 and .51 are almost identical in source code. But as we remember,
3.23.51 was built by a new build master using a new build procedure. There
may be some subtle change in glibc which only demonstrates itself under
certain load or platform.

Regards,

Heikki
Innobase Oy

- Original Message -
From: "Sinisa Milivojevic" <[EMAIL PROTECTED]>
Newsgroups: mailing.database.mysql
Sent: Monday, June 24, 2002 4:14 PM
Subject: Re: Load problems with 3.23.51


> Jeremy Zawodny writes:
> > On Sat, Jun 22, 2002 at 05:25:59PM -0700, Steven Roussey wrote:
> >
> > As another data point for you, I've got 3.23.51 running on our master
> > quite well.  The difference is that I built it from source (to get a
> > critical InnoDB patch).  I don't recall which compiler the MySQL folks
> > used (and which glibc), but my source build used Debian Woody's gcc
> > 2.95.4.
> >
> > That could have something to do with it...
> >
> > Jeremy
> > --
> > Jeremy D. Zawodny, <[EMAIL PROTECTED]>
> > Technical Yahoo - Yahoo Finance
> > Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936
> >
> > MySQL 3.23.51: up 24 days, processed 523,371,775 queries (248/sec. avg)
> >
>
> Using 2.95.* or 3.* is just fine, with proper configuration, as
> explained in our fine manual.
>
> --
> Regards,
>__  ___ ___   __
>   /  |/  /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic <[EMAIL PROTECTED]>
>  / /|_/ / // /\ \/ /_/ / /__   MySQL AB, Fulltime Developer
> /_/  /_/\_, /___/\___\_\___/   Larnaca, Cyprus
><___/   www.mysql.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
>



-
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: Load problems with 3.23.51

2002-06-24 Thread Michael Bacarella

On Mon, Jun 24, 2002 at 12:43:47PM -0700, Jeremy Zawodny wrote:
> > I will second this.
> > 
> > I attempted an upgrade from 3.23.50 to 3.23.51 and hit immediate
> > performance problems. I tried for about 20 minutes to see what was
> > causing it but to no avail. I reverted to 3.23.50.
> > 
> > At first I thought it was my fault so I decided not to report it
> > until I did some further research.
> 
> What OS are you using?  And did you use the pre-built binaries or
> build from source?

Stock Red Hat 7.2.  Pre-built mysql-max binaries. InnoDB tables.

-- 
Michael Bacarella  | Netgraft Corporation
   | 545 Eighth Ave #401
 Systems Analysis  | New York, NY 10018
Technical Support  | 212 946-1038 | 917 670-6982
 Managed Services  | [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: Load problems with 3.23.51

2002-06-24 Thread Jeremy Zawodny

On Mon, Jun 24, 2002 at 03:11:53PM -0400, Michael Bacarella wrote:
> I will second this.
> 
> I attempted an upgrade from 3.23.50 to 3.23.51 and hit immediate
> performance problems. I tried for about 20 minutes to see what was
> causing it but to no avail. I reverted to 3.23.50.
> 
> At first I thought it was my fault so I decided not to report it
> until I did some further research.

What OS are you using?  And did you use the pre-built binaries or
build from source?
-- 
Jeremy D. Zawodny, <[EMAIL PROTECTED]>
Technical Yahoo - Yahoo Finance
Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936

MySQL 3.23.51: up 25 days, processed 549,473,907 queries (246/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: Load problems with 3.23.51

2002-06-24 Thread Michael Bacarella

I will second this.

I attempted an upgrade from 3.23.50 to 3.23.51 and hit immediate
performance problems. I tried for about 20 minutes to see what was
causing it but to no avail. I reverted to 3.23.50.

At first I thought it was my fault so I decided not to report it
until I did some further research.

-M

On Mon, Jun 24, 2002 at 11:52:47AM -0700, Steven Roussey wrote:
> I tried 'skip-name-resolve' but it had no impact. :( So it may have
> nothing to do with name resolution.
> 
> Here are the results in file RUN-mysql-Linux_2.4.16_0.13smp_i686:
> 
> 
> I'm going to run the tests on .47 next to see if there is any
> difference.
> 
> 
> Sincerely,
> Steven Roussey
> http://Network54.com/?pp=e
> 
> > -Original Message-
> > From: Michael Widenius [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 24, 2002 4:24 am
> > To: [EMAIL PROTECTED]
> > Cc: Steven Roussey; [EMAIL PROTECTED]
> > Subject: Re: Load problems with 3.23.51
> > 
> > 
> > Hi!
> > 
> > >>>>> "Jeremy" == Jeremy Zawodny <[EMAIL PROTECTED]> writes:
> > 
> > Jeremy> On Sat, Jun 22, 2002 at 05:25:59PM -0700, Steven Roussey
> wrote:
> > >> Hi all,
> > >>
> > >> I have MySQL 3.23.47 running on our sever. I skipped 48 through 50
> and
> > >> tried 51. No dice. It does not handle load, CPU and the load
> average go
> > >> through the roof. I'm using Red Hat Linux 7.2 and the official
> mysql
> > >> binaries. It appears to be slow to connect, causing 0.5 to 1.0
> second
> > >> delay on connection. Using persistent connections from PHP does not
> > make
> > >> much of a difference. I thought it might be the hostname lookup
> changes
> > >> so I chose skip-grant-tables. This doesn't actually skip the
> hostname
> > >> lookup though and had no effect.
> > >>
> > >> Most queries are shorter than 1 second so this problem causes
> > >> catastrophic problems by making queries last a multiple times
> longer,
> > >> which make the number of concurrent queries jump exponentially.
> This is
> > >> a bad thing. And sadly makes 3.23.51 unusable.
> > >>
> > >> Does anyone else note these types of issues?
> > 
> > Jeremy> As another data point for you, I've got 3.23.51 running on our
> > master
> > Jeremy> quite well.  The difference is that I built it from source (to
> get
> > a
> > Jeremy> critical InnoDB patch).  I don't recall which compiler the
> MySQL
> > folks
> > Jeremy> used (and which glibc), but my source build used Debian
> Woody's
> > gcc
> > Jeremy> 2.95.4.
> > 
> > We are using gcc 2.95.3 and a patched glibc, the later one that we
> > used in many builds before.
> > 
> > This is the first email I got that 3.23.51 would be slow.
> > 
> > Steven, could you try to run the MySQL benchmark suite on your machine
> > and post me the results ?
> > 
> > cd sql-bench
> > perl run-all-tests --log
> > 
> > The file I am interested in is the summary file named 'output/RUN-*'
> > 
> > Regards,
> > Monty
> 
> 
> 
> -
> 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
> 

-- 
Michael Bacarella  | Netgraft Corporation
   | 545 Eighth Ave #401
 Systems Analysis  | New York, NY 10018
Technical Support  | 212 946-1038 | 917 670-6982
 Managed Services  | [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: Load problems with 3.23.51

2002-06-24 Thread Steven Roussey
12.007.134.47   11.60
80
select_big_str19.006.423.65   10.07
1
select_column+column   1.000.290.320.61
1
select_diff_key   76.000.250.030.28
500
select_distinct4.000.770.231.00
800
select_group  21.000.900.211.11
2911
select_group_when_MANY_tables 27.001.310.431.74
1
select_join1.000.220.070.29
100
select_key77.00   44.418.29   52.70
20
select_key2   85.00   42.516.77   49.28
20
select_key2_return_key82.00   40.646.48   47.12
20
select_key2_return_prim   83.00   41.887.19   49.07
20
select_key_prefix 87.00   43.347.64   50.98
20
select_key_prefix_join 3.001.310.842.15
100
select_key_return_key 76.00   40.186.97   47.15
20
select_many_fields 9.003.072.795.86
2000
select_query_cache49.004.040.414.45
1
select_query_cache2   49.003.850.334.18
1
select_range  88.003.091.624.71
410
select_range_key2 10.003.910.744.65
25010
select_range_prefix   12.003.930.774.70
25010
select_simple  1.000.220.340.56
1
select_simple_join 1.000.240.090.33
500
update_big11.000.000.000.00
10
update_of_key 13.002.291.183.47
5
update_of_key_big  7.000.020.010.03
501
update_of_primary_key_many_keys   11.000.030.000.03
256
update_with_key   58.00   10.907.23   18.13
30
update_with_key_prefix18.004.102.436.53
10
wisc_benchmark 2.001.060.371.43
114
TOTALS  2098.00  436.22  126.65  562.87
2667247

Sincerely,
Steven Roussey
http://Network54.com/?pp=e

> -Original Message-
> From: Michael Widenius [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 24, 2002 4:24 am
> To: [EMAIL PROTECTED]
> Cc: Steven Roussey; [EMAIL PROTECTED]
> Subject: Re: Load problems with 3.23.51
> 
> 
> Hi!
> 
> >>>>> "Jeremy" == Jeremy Zawodny <[EMAIL PROTECTED]> writes:
> 
> Jeremy> On Sat, Jun 22, 2002 at 05:25:59PM -0700, Steven Roussey
wrote:
> >> Hi all,
> >>
> >> I have MySQL 3.23.47 running on our sever. I skipped 48 through 50
and
> >> tried 51. No dice. It does not handle load, CPU and the load
average go
> >> through the roof. I'm using Red Hat Linux 7.2 and the official
mysql
> >> binaries. It appears to be slow to connect, causing 0.5 to 1.0
second
> >> delay on connection. Using persistent connections from PHP does not
> make
> >> much of a difference. I thought it might be the hostname lookup
changes
> >> so I chose skip-grant-tables. This doesn't actually skip the
hostname
> >> lookup though and had no effect.
> >>
> >> Most queries are shorter than 1 second so this problem causes
> >> catastrophic problems by making queries last a multiple times
longer,
> >> which make the number of concurrent queries jump exponentially.
This is
> >> a bad thing. And sadly makes 3.23.51 unusable.
> >>
> >> Does anyone else note these types of issues?
> 
> Jeremy> As another data point for you, I've got 3.23.51 running on our
> master
> Jeremy> quite well.  The difference is that I built it from source (to
get
> a
> Jeremy> critical InnoDB patch).  I don't recall which compiler the
MySQL
> folks
> Jeremy> used (and which glibc), but my source build used Debian
Woody's
> gcc
> Jeremy> 2.95.4.
> 
> We are using gcc 2.95.3 and a patched glibc, the later one that we
> used in many builds before.
> 
> This is the first email I got that 3.23.51 would be slow.
> 
> Steven, could you try to run the MySQL benchmark suite on your machine
> and post me the results ?
> 
> cd sql-bench
> perl run-all-tests --log
> 
> The file I am interested in is the summary file named 'output/RUN-*'
> 
> Regards,
> Monty



-
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: Load problems with 3.23.51

2002-06-24 Thread Steven Roussey

I tried 'skip-name-resolve' but it had no impact. :( So it may have
nothing to do with name resolution.

Here are the results in file RUN-mysql-Linux_2.4.16_0.13smp_i686:


I'm going to run the tests on .47 next to see if there is any
difference.


Sincerely,
Steven Roussey
http://Network54.com/?pp=e

> -Original Message-
> From: Michael Widenius [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 24, 2002 4:24 am
> To: [EMAIL PROTECTED]
> Cc: Steven Roussey; [EMAIL PROTECTED]
> Subject: Re: Load problems with 3.23.51
> 
> 
> Hi!
> 
> >>>>> "Jeremy" == Jeremy Zawodny <[EMAIL PROTECTED]> writes:
> 
> Jeremy> On Sat, Jun 22, 2002 at 05:25:59PM -0700, Steven Roussey
wrote:
> >> Hi all,
> >>
> >> I have MySQL 3.23.47 running on our sever. I skipped 48 through 50
and
> >> tried 51. No dice. It does not handle load, CPU and the load
average go
> >> through the roof. I'm using Red Hat Linux 7.2 and the official
mysql
> >> binaries. It appears to be slow to connect, causing 0.5 to 1.0
second
> >> delay on connection. Using persistent connections from PHP does not
> make
> >> much of a difference. I thought it might be the hostname lookup
changes
> >> so I chose skip-grant-tables. This doesn't actually skip the
hostname
> >> lookup though and had no effect.
> >>
> >> Most queries are shorter than 1 second so this problem causes
> >> catastrophic problems by making queries last a multiple times
longer,
> >> which make the number of concurrent queries jump exponentially.
This is
> >> a bad thing. And sadly makes 3.23.51 unusable.
> >>
> >> Does anyone else note these types of issues?
> 
> Jeremy> As another data point for you, I've got 3.23.51 running on our
> master
> Jeremy> quite well.  The difference is that I built it from source (to
get
> a
> Jeremy> critical InnoDB patch).  I don't recall which compiler the
MySQL
> folks
> Jeremy> used (and which glibc), but my source build used Debian
Woody's
> gcc
> Jeremy> 2.95.4.
> 
> We are using gcc 2.95.3 and a patched glibc, the later one that we
> used in many builds before.
> 
> This is the first email I got that 3.23.51 would be slow.
> 
> Steven, could you try to run the MySQL benchmark suite on your machine
> and post me the results ?
> 
> cd sql-bench
> perl run-all-tests --log
> 
> The file I am interested in is the summary file named 'output/RUN-*'
> 
> Regards,
> Monty



-
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: Load problems with 3.23.51

2002-06-24 Thread Jayce^

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> I have MySQL 3.23.47 running on our sever. I skipped 48 through 50 and
> tried 51. No dice. It does not handle load, CPU and the load average go
> through the roof. I'm using Red Hat Linux 7.2 and the official mysql
> binaries. It appears to be slow to connect, causing 0.5 to 1.0 second
> delay on connection.

We have had the exact opposite reaction on our RH 7.2 boxes.  .49 would 
consistently crash every hour under load (the innodb high avail_cc thingy).  
But since upgrading to .51 our load has been down, and we've only restarted 
once, to enact some .cnf changes.  For us, the upgrade has been a godsend.  
This is using the official binaries (not RPM if that makes a difference at 
all).

Jayce^
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9F0YmoTgdT9hhlCIRAtTSAJ49rm81dRjAfLq7qWQbyzXJTccWQgCfR/K9
rsRDVWUd3UssqzMcvk1RB64=
=C/uf
-END PGP SIGNATURE-


-
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: Load problems with 3.23.51

2002-06-24 Thread Sinisa Milivojevic

Jeremy Zawodny writes:
> On Sat, Jun 22, 2002 at 05:25:59PM -0700, Steven Roussey wrote:
> 
> As another data point for you, I've got 3.23.51 running on our master
> quite well.  The difference is that I built it from source (to get a
> critical InnoDB patch).  I don't recall which compiler the MySQL folks
> used (and which glibc), but my source build used Debian Woody's gcc
> 2.95.4.
> 
> That could have something to do with it...
> 
> Jeremy
> -- 
> Jeremy D. Zawodny, <[EMAIL PROTECTED]>
> Technical Yahoo - Yahoo Finance
> Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936
> 
> MySQL 3.23.51: up 24 days, processed 523,371,775 queries (248/sec. avg)
> 

Using 2.95.* or 3.* is just fine, with proper configuration, as
explained in our fine manual.

-- 
Regards,
   __  ___ ___   __
  /  |/  /_ __/ __/ __ \/ /Mr. Sinisa Milivojevic <[EMAIL PROTECTED]>
 / /|_/ / // /\ \/ /_/ / /__   MySQL AB, Fulltime Developer
/_/  /_/\_, /___/\___\_\___/   Larnaca, Cyprus
   <___/   www.mysql.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




Re: Load problems with 3.23.51

2002-06-24 Thread Michael Widenius


Hi!

> "Jeremy" == Jeremy Zawodny <[EMAIL PROTECTED]> writes:

Jeremy> On Sat, Jun 22, 2002 at 05:25:59PM -0700, Steven Roussey wrote:
>> Hi all,
>> 
>> I have MySQL 3.23.47 running on our sever. I skipped 48 through 50 and
>> tried 51. No dice. It does not handle load, CPU and the load average go
>> through the roof. I'm using Red Hat Linux 7.2 and the official mysql
>> binaries. It appears to be slow to connect, causing 0.5 to 1.0 second
>> delay on connection. Using persistent connections from PHP does not make
>> much of a difference. I thought it might be the hostname lookup changes
>> so I chose skip-grant-tables. This doesn't actually skip the hostname
>> lookup though and had no effect.
>> 
>> Most queries are shorter than 1 second so this problem causes
>> catastrophic problems by making queries last a multiple times longer,
>> which make the number of concurrent queries jump exponentially. This is
>> a bad thing. And sadly makes 3.23.51 unusable.
>> 
>> Does anyone else note these types of issues?

Jeremy> As another data point for you, I've got 3.23.51 running on our master
Jeremy> quite well.  The difference is that I built it from source (to get a
Jeremy> critical InnoDB patch).  I don't recall which compiler the MySQL folks
Jeremy> used (and which glibc), but my source build used Debian Woody's gcc
Jeremy> 2.95.4.

We are using gcc 2.95.3 and a patched glibc, the later one that we
used in many builds before.

This is the first email I got that 3.23.51 would be slow.

Steven, could you try to run the MySQL benchmark suite on your machine
and post me the results ?

cd sql-bench
perl run-all-tests --log

The file I am interested in is the summary file named 'output/RUN-*'

Regards,
Monty

-
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: Load problems with 3.23.51

2002-06-24 Thread Jeff Kilbride

What about using the skip-name-resolve option rather than skip-grant-tables?
I'm using the 3.23.51 binaries, also, and would appreciate knowing if this
makes a difference. Debian potato 2.95.2 is a known good compiler, too,
isn't it Jeremy? I may have to recompile my own anyway to change
ft_min_word_length.

On another note with 3.23.51, I'm getting these errors every 30 seconds in
my slave error logs:


020624  5:00:00  Slave: Failed reading log event, reconnecting to retry, log
'db1-bin.008' position 3112
020624  5:00:00  Slave: reconnected to master
'[EMAIL PROTECTED]:3306',replication resumed in log 'db1-bin.008' at position
3112
020624  5:00:30  Error reading packet from server:  (server_errno=1159)


Is this just a normal timeout I can ignore? I'm still developing, so there's
no real activity on these machines, yet. Is there a timeout value I can
adjust? It's just annoying to see my error log growing so much with no
activity.

Thanks,
--jeff

- Original Message -
From: "Jeremy Zawodny" <[EMAIL PROTECTED]>
To: "Steven Roussey" <[EMAIL PROTECTED]>
Cc: "'Mysql'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, June 23, 2002 2:55 AM
Subject: Re: Load problems with 3.23.51


> On Sat, Jun 22, 2002 at 05:25:59PM -0700, Steven Roussey wrote:
> > Hi all,
> >
> > I have MySQL 3.23.47 running on our sever. I skipped 48 through 50 and
> > tried 51. No dice. It does not handle load, CPU and the load average go
> > through the roof. I'm using Red Hat Linux 7.2 and the official mysql
> > binaries. It appears to be slow to connect, causing 0.5 to 1.0 second
> > delay on connection. Using persistent connections from PHP does not make
> > much of a difference. I thought it might be the hostname lookup changes
> > so I chose skip-grant-tables. This doesn't actually skip the hostname
> > lookup though and had no effect.
> >
> > Most queries are shorter than 1 second so this problem causes
> > catastrophic problems by making queries last a multiple times longer,
> > which make the number of concurrent queries jump exponentially. This is
> > a bad thing. And sadly makes 3.23.51 unusable.
> >
> > Does anyone else note these types of issues?
>
> As another data point for you, I've got 3.23.51 running on our master
> quite well.  The difference is that I built it from source (to get a
> critical InnoDB patch).  I don't recall which compiler the MySQL folks
> used (and which glibc), but my source build used Debian Woody's gcc
> 2.95.4.
>
> That could have something to do with it...
>
> Jeremy
> --
> Jeremy D. Zawodny, <[EMAIL PROTECTED]>
> Technical Yahoo - Yahoo Finance
> Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936
>
> MySQL 3.23.51: up 24 days, processed 523,371,775 queries (248/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
>


-
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: Load problems with 3.23.51

2002-06-23 Thread Jeremy Zawodny

On Sat, Jun 22, 2002 at 05:25:59PM -0700, Steven Roussey wrote:
> Hi all,
> 
> I have MySQL 3.23.47 running on our sever. I skipped 48 through 50 and
> tried 51. No dice. It does not handle load, CPU and the load average go
> through the roof. I'm using Red Hat Linux 7.2 and the official mysql
> binaries. It appears to be slow to connect, causing 0.5 to 1.0 second
> delay on connection. Using persistent connections from PHP does not make
> much of a difference. I thought it might be the hostname lookup changes
> so I chose skip-grant-tables. This doesn't actually skip the hostname
> lookup though and had no effect.
> 
> Most queries are shorter than 1 second so this problem causes
> catastrophic problems by making queries last a multiple times longer,
> which make the number of concurrent queries jump exponentially. This is
> a bad thing. And sadly makes 3.23.51 unusable.
> 
> Does anyone else note these types of issues?

As another data point for you, I've got 3.23.51 running on our master
quite well.  The difference is that I built it from source (to get a
critical InnoDB patch).  I don't recall which compiler the MySQL folks
used (and which glibc), but my source build used Debian Woody's gcc
2.95.4.

That could have something to do with it...

Jeremy
-- 
Jeremy D. Zawodny, <[EMAIL PROTECTED]>
Technical Yahoo - Yahoo Finance
Desk: (408) 349-7878   Fax: (408) 349-5454   Cell: (408) 685-5936

MySQL 3.23.51: up 24 days, processed 523,371,775 queries (248/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