Какое железо нужно?

В связи с высокими нагрузками на mysql на одном сервере, прошу подсказать железо для таких дел.

Сейчас Celeron 2.4Mhz / 1024 RAM

Железо какого уровня посоветуете, чтоб увеличить производительность? Ценовые пределы не имеют значения, так как окупаемость сайта прямо пропорционально зависит от его производительности. Хотелось бы конешно иметь раза в 4 быстрей базу mysql

Вопрос абстрактный.
Если ценовые пределы не имеют значения и от производительности сервера напрямую зависят доходы то возьми
Quad Opteron Server
4 OPTERON 885 Dual Core 2.60GHz 2Mb L2
DDR ECC Reg: 64GB KIT PC2700 ECC Reg

на сегодня это пожалуй самый мощный 1U-сервер

а если хочешь в 4 раза быстрее базу сделать то возьми пень 4 любой и памяти гиг добавь а лучше 3

а вообще не зная что именно там в базе ответа дать не возможно.

В базе восновном относительно долго выполняются join больших таблиц. Слишком много хитов в день, 1-2 млн.

если все это на целероне работает, то возми core2duo 6600 c 4ГБ памяти, думаю этого хватит с головой пока что.
если думаеш что сайт будет рости и надо будет через пару месяцев опять апгрейдиться - возми сразу дуал ксеон....

wonderfulzi писал:

В базе восновном относительно долго выполняются join больших таблиц. Слишком много хитов в день, 1-2 млн.

А сколько запросов к базе приходится на каждый хит? Может проблема не в железе а в структуре базы?

Да вы че, ребят... Такой гроб для базы мускуля - это ж бля целую сеть мегафона обслужит.

топикстартер, ебни по рукам твоего программера. У тебя индексы не правильно стоят или не стоят вообще. Поправь индексы (как минимум по одному индексу на каждый FOREIGHN KEY) и не надо никакое железо менять.

руки должны расти из плеч а не из попы. и у программера и у сисадмина.

Ану запусти запрос SHOW STATUS и скажи свои значения:
Select_full_join
Select_full_range_join
Select_scan
Uptime

получится что за (Uptime/3600) часов база обработала Select_full_join запросов, в которых при джойне не используется индекс и идет скан всех таблиц.

Так же за это время было обработано Select_Scan запросов, где в условии отбора не использовался индекс и шел скан всей таблицы.

-----

Pentarh писал:

Да вы че, ребят... Такой гроб для базы мускуля - это ж бля целую сеть мегафона обслужит. топикстартер, ебни по рукам твоего программера. У тебя индексы не правильно стоят или не стоят вообще. Поправь индексы (как минимум по одному индексу на каждый FOREIGHN KEY) и не надо никакое железо менять. руки должны расти из плеч а не из попы. и у программера и у сисадмина. Ану запусти запрос SHOW STATUS и скажи свои значения: Select_full_join Select_full_range_join Select_scan Uptime

Select_full_join = 1683
Select_full_range_join = 0
Select_scan = 478883
Uptime = 154201

Печально. С джойнами более-менее. за 42 часа "всего" 2к безиндексных джойнов. Немного подтюнить.

А вот со сканом даа... Надо понаставить индексики.

The number of joins that did a full scan of the first table. This variable was added in MySQL 3.23.25.

Ну там еще буфера подтюнить.

А что там у вас со Slow_queries?

Короче, не нужно тебе железо. Оптимизация мускуля тебе нужна, ато и более мощный сервер положишь я представляю как у тя винт пыхтит ) 10к полных сканов таблиц в час при джойне...

покури на досуге вот

http://dev.mysql.com/doc/refman/4.1/en/server-status-variables.html

Код:

+----------------------------+------------+ | Variable_name              | Value      | +----------------------------+------------+ | Aborted_clients            | 133        | | Aborted_connects           | 20         | | Binlog_cache_disk_use      | 0          | | Binlog_cache_use           | 0          | | Bytes_received             | 689194621  | | Bytes_sent                 | 648015447  | | Com_admin_commands         | 1393507    | | Com_alter_db               | 0          | | Com_alter_table            | 0          | | Com_analyze                | 0          | | Com_backup_table           | 0          | | Com_begin                  | 0          | | Com_change_db              | 475089     | | Com_change_master          | 0          | | Com_check                  | 0          | | Com_checksum               | 0          | | Com_commit                 | 0          | | Com_create_db              | 0          | | Com_create_function        | 0          | | Com_create_index           | 0          | | Com_create_table           | 0          | | Com_dealloc_sql            | 0          | | Com_delete                 | 303403     | | Com_delete_multi           | 0          | | Com_do                     | 0          | | Com_drop_db                | 0          | | Com_drop_function          | 0          | | Com_drop_index             | 0          | | Com_drop_table             | 0          | | Com_drop_user              | 0          | | Com_execute_sql            | 0          | | Com_flush                  | 0          | | Com_grant                  | 0          | | Com_ha_close               | 0          | | Com_ha_open                | 0          | | Com_ha_read                | 0          | | Com_help                   | 0          | | Com_insert                 | 856019     | | Com_insert_select          | 1714       | | Com_kill                   | 0          | | Com_load                   | 0          | | Com_load_master_data       | 0          | | Com_load_master_table      | 0          | | Com_lock_tables            | 92         | | Com_optimize               | 0          | | Com_preload_keys           | 0          | | Com_prepare_sql            | 0          | | Com_purge                  | 0          | | Com_purge_before_date      | 0          | | Com_rename_table           | 0          | | Com_repair                 | 0          | | Com_replace                | 0          | | Com_replace_select         | 0          | | Com_reset                  | 0          | | Com_restore_table          | 0          | | Com_revoke                 | 0          | | Com_revoke_all             | 0          | | Com_rollback               | 0          | | Com_savepoint              | 0          | | Com_select                 | 1902519    | | Com_set_option             | 452        | | Com_show_binlog_events     | 0          | | Com_show_binlogs           | 8          | | Com_show_charsets          | 113        | | Com_show_collations        | 113        | | Com_show_column_types      | 0          | | Com_show_create_db         | 0          | | Com_show_create_table      | 4          | | Com_show_databases         | 25         | | Com_show_errors            | 0          | | Com_show_fields            | 5          | | Com_show_grants            | 69         | | Com_show_innodb_status     | 0          | | Com_show_keys              | 41         | | Com_show_logs              | 0          | | Com_show_master_status     | 0          | | Com_show_ndb_status        | 0          | | Com_show_new_master        | 0          | | Com_show_open_tables       | 0          | | Com_show_privileges        | 0          | | Com_show_processlist       | 206        | | Com_show_slave_hosts       | 0          | | Com_show_slave_status      | 0          | | Com_show_status            | 2633       | | Com_show_storage_engines   | 0          | | Com_show_tables            | 324        | | Com_show_variables         | 274        | | Com_show_warnings          | 0          | | Com_slave_start            | 0          | | Com_slave_stop             | 0          | | Com_stmt_close             | 0          | | Com_stmt_execute           | 0          | | Com_stmt_prepare           | 0          | | Com_stmt_reset             | 0          | | Com_stmt_send_long_data    | 0          | | Com_truncate               | 0          | | Com_unlock_tables          | 90         | | Com_update                 | 1188964    | | Com_update_multi           | 0          | | Connections                | 480279     | | Created_tmp_disk_tables    | 424679     | | Created_tmp_files          | 202        | | Created_tmp_tables         | 533876     | | Delayed_errors             | 0          | | Delayed_insert_threads     | 1          | | Delayed_writes             | 134704     | | Flush_commands             | 1          | | Handler_commit             | 20         | | Handler_delete             | 320809     | | Handler_discover           | 0          | | Handler_read_first         | 317594     | | Handler_read_key           | 427320426  | | Handler_read_next          | 1353890044 | | Handler_read_prev          | 0          | | Handler_read_rnd           | 28440913   | | Handler_read_rnd_next      | 906778337  | | Handler_rollback           | 491514     | | Handler_update             | 133315964  | | Handler_write              | 96325200   | | Key_blocks_not_flushed     | 0          | | Key_blocks_unused          | 0          | | Key_blocks_used            | 115980     | | Key_read_requests          | 164389594  | | Key_reads                  | 849962     | | Key_write_requests         | 1792977    | | Key_writes                 | 1049377    | | Max_used_connections       | 224        | | Not_flushed_delayed_rows   | 0          | | Open_files                 | 115        | | Open_streams               | 0          | | Open_tables                | 256        | | Opened_tables              | 7876       | | Qcache_free_blocks         | 72         | | Qcache_free_memory         | 134041288  | | Qcache_hits                | 1014236    | | Qcache_inserts             | 1021993    | | Qcache_lowmem_prunes       | 0          | | Qcache_not_cached          | 880426     | | Qcache_queries_in_cache    | 138        | | Qcache_total_blocks        | 367        | | Questions                  | 6214434    | | Rpl_status                 | NULL       | | Select_full_join           | 1714       | | Select_full_range_join     | 0          | | Select_range               | 485150     | | Select_range_check         | 0          | | Select_scan                | 490709     | | Slave_open_temp_tables     | 0          | | Slave_retried_transactions | 0          | | Slave_running              | OFF        | | Slow_launch_threads        | 0          | | Slow_queries               | 96210      | | Sort_merge_passes          | 0          | | Sort_range                 | 132        | | Sort_rows                  | 37806909   | | Sort_scan                  | 759033     | | Table_locks_immediate      | 4692174    | | Table_locks_waited         | 192737     | | Threads_cached             | 13         | | Threads_connected          | 16         | | Threads_created            | 17843      | | Threads_running            | 4          | | Uptime                     | 157807     | +----------------------------+------------+

Народ, такой вопрос, имеет ли смысл создавать индекс для таблицы, если в колонке могут быть только 2 значения?

тем более имеет смысл

вообще создавай индексы по всем полям которые у тебя где либо встречаются в конструкции WHERE

Практически при каждом хите используется или INSERT или UPDATE. Запросы разные и много и сайт продолжает развиватся, использоватся все поля таблиц могут по разному, тогда что лучше:

1) Делать отдельно индекс из набора колонок для каждого запроса
2) Просто сделать отдельные индексы для каждой колонки

по нормализации баз данных есть целые книжки
оптимизация запросов тоже штука не простая,
очень все зависит от твоих запросов и твоей базы, может у тебя структура таблиц в базе сама по себе не удачно выбранна, может запросы не оптимизированы, тут много чего...
конкретно по индексам, тоже все зависит от запросов, индекс для набора называется составной индекс и работает он так:
индекс по полям (a, b, c)
1) поиск по a, b - индекс применяется
2) поиск по a, c - индекс применятся, но не так эффективно как в 1
3) поиск по b, c - индекс НЕ применятся.
все зависит от запросов...
читай здесь: http://www.intuit.ru/department/database/sqlserver2000/17/2.html
и здесь
http://www.sql.ru/articles/mssql/03013101Indexes.shtml

Апсалютна согласен - оторви программеру руки.

Насчет железа: если не можешь оторвать руки, то тебе надо очень быстрые диски а не процессор. Тоесть, 4 диска 10К rpm, raid 5 с правильным контроллером.

wonderfulzi писал:

Практически при каждом хите используется или INSERT или UPDATE.

подумайте над логикой работы, а действительно нужно-ли это?..

из гаданий на кофейной гуще: можно бросать необработанные данные в тхт файл, а потом по крону раз в 10-30 минут разгребать их, попутно производя их обработку и группировку. мне данный вариант несколько раз помогал. за счет группировки кол-во обращений к sql снижается в несколько тысяч раз.

Посмотрел я твою инфу и вот что скажу.

1. По оптимизации самого мускуля

Снижаем нагрузку на винт.
Opened_tables - слишком большое, увеличь значение table_cache в my.cnf
Created_tmp_disk_tables - очень большое. надо существенно увеличить значение tmp_table_size в my.cnf

остальное вроде в порядке

2. По оптимизации запросов.
Используй INSERT DELAYED вместо INSERT
Не пиши данные вроде логов из скрипта прямо в базу. Пиши их куда то в файл и периодически кроном очищай этот файл и вставляй данные в базу.
У тебя очень большое количество инсертов и/или апдейтов идет, по этому злоупотреблять индексами не стоит. Надо ставить их ровно там, где они действительно нужны. А где они нужны? Ну это надо смотреть твои запросы в коде и расставлять индексы одинарные, двойные или тройные.