Fast my.cnf
max_connections = 3000
sort_buffer_size = 64K
join_buffer_size = 1M
query_cache_size = 0
thread_stack = 196K
innodb_data_file_path = ibdata1:100M:autoextend
innodb_file_per_table = 1
innodb_status_file = 0
max_prepared_stmt_count = 1000000
skip_grant_tables
skip_locking
innodb_thread_concurrency = 0
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 8M


Slow my.cnf 300x diff
max_connections = 1000
sort_buffer_size = 8M
join_buffer_size = 8M
query_cache_size = 64M
thread_stack = 192K
innodb_data_file_path = ibdata1:4G:autoextend
innodb_thread_concurrency = 16
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 256M


Machine has 8gigs of memory running 2 Intel(R) Xeon(R) CPU 5130 @ 2.00GHz , 4 cores

INSERT INTO 1_subscribers (email, name, lastName, idGroup, dateSubscribed, confirmed, prefersHtml, subPassword) VALUES ('email@domain.47123', 'first47123', 'last47123', 1, '2010-04-14 15:16:16', -1, -1, '2492')

The diff in an insert query of 100k records was 74secs. Vs 21 mins!

Any thoughts?

I guess innodb_flush_log_at_trx_commit is key. flush to disk is slow operation.

Ok... what about the change at

sort_buffer_size = 8M
join_buffer_size = 8M

we dropped those down a ton - could prob bring those back up? Any suggestions would be great