Master-X
Форум | Новости | Статьи
Главная » Форум » Хостинги / Домены / Железо » 
Тема: Какое железо нужно?
цитата
04/01/07 в 11:24
 wonderfulzi
В связи с высокими нагрузками на mysql на одном сервере, прошу подсказать железо для таких дел.

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

Железо какого уровня посоветуете, чтоб увеличить производительность? Ценовые пределы не имеют значения, так как окупаемость сайта прямо пропорционально зависит от его производительности. Хотелось бы конешно иметь раза в 4 быстрей базу mysql
цитата
04/01/07 в 11:45
 Tornado
Вопрос абстрактный.
Если ценовые пределы не имеют значения и от производительности сервера напрямую зависят доходы то возьми
Quad Opteron Server
4 OPTERON 885 Dual Core 2.60GHz 2Mb L2
DDR ECC Reg: 64GB KIT PC2700 ECC Reg

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

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

а вообще не зная что именно там в базе ответа дать не возможно.
цитата
04/01/07 в 11:51
 wonderfulzi
В базе восновном относительно долго выполняются join больших таблиц. Слишком много хитов в день, 1-2 млн.
цитата
04/01/07 в 15:20
 Bullet
если все это на целероне работает, то возми core2duo 6600 c 4ГБ памяти, думаю этого хватит с головой пока что.
если думаеш что сайт будет рости и надо будет через пару месяцев опять апгрейдиться - возми сразу дуал ксеон....
цитата
04/01/07 в 16:39
 Gourad
wonderfulzi писал:
В базе восновном относительно долго выполняются join больших таблиц. Слишком много хитов в день, 1-2 млн.

А сколько запросов к базе приходится на каждый хит? Может проблема не в железе а в структуре базы?
цитата
04/01/07 в 17:17
 Pentarh
Да вы че, ребят... Такой гроб для базы мускуля - это ж бля целую сеть мегафона обслужит.

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

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

Ану запусти запрос SHOW STATUS и скажи свои значения:
Select_full_join
Select_full_range_join
Select_scan
Uptime
цитата
04/01/07 в 17:24
 Pentarh
получится что за (Uptime/3600) часов база обработала Select_full_join запросов, в которых при джойне не используется индекс и идет скан всех таблиц.

Так же за это время было обработано Select_Scan запросов, где в условии отбора не использовался индекс и шел скан всей таблицы.
цитата
04/01/07 в 17:33
 wonderfulzi
-----
цитата
04/01/07 в 17:40
 wonderfulzi
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
цитата
04/01/07 в 17:44
 Pentarh
Печально. С джойнами более-менее. за 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?
цитата
04/01/07 в 17:47
 Pentarh
Короче, не нужно тебе железо. Оптимизация мускуля тебе нужна, ато и более мощный сервер положишь icon_smile.gif я представляю как у тя винт пыхтит ) 10к полных сканов таблиц в час при джойне...

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

http://dev.mysql.com/doc/refman/4.1/en/server-status-variables.html
цитата
04/01/07 в 18:35
 wonderfulzi
Код:
+----------------------------+------------+
| 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     |
+----------------------------+------------+
цитата
04/01/07 в 18:48
 wonderfulzi
Народ, такой вопрос, имеет ли смысл создавать индекс для таблицы, если в колонке могут быть только 2 значения?
цитата
04/01/07 в 18:50
 bleed

тем более имеет смысл
цитата
04/01/07 в 18:52
 bleed
вообще создавай индексы по всем полям которые у тебя где либо встречаются в конструкции WHERE
цитата
04/01/07 в 18:58
 wonderfulzi
Практически при каждом хите используется или INSERT или UPDATE. Запросы разные и много и сайт продолжает развиватся, использоватся все поля таблиц могут по разному, тогда что лучше:

1) Делать отдельно индекс из набора колонок для каждого запроса
2) Просто сделать отдельные индексы для каждой колонки
цитата
04/01/07 в 20:25
 bleed
по нормализации баз данных есть целые книжки
оптимизация запросов тоже штука не простая,
очень все зависит от твоих запросов и твоей базы, может у тебя структура таблиц в базе сама по себе не удачно выбранна, может запросы не оптимизированы, тут много чего...
конкретно по индексам, тоже все зависит от запросов, индекс для набора называется составной индекс и работает он так:
индекс по полям (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
цитата
04/01/07 в 22:22
 alex pilosov
Апсалютна согласен - оторви программеру руки.

Насчет железа: если не можешь оторвать руки, то тебе надо очень быстрые диски а не процессор. Тоесть, 4 диска 10К rpm, raid 5 с правильным контроллером.
цитата
04/01/07 в 23:26
 Dak
wonderfulzi писал:
Практически при каждом хите используется или INSERT или UPDATE.


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

из гаданий на кофейной гуще: можно бросать необработанные данные в тхт файл, а потом по крону раз в 10-30 минут разгребать их, попутно производя их обработку и группировку. мне данный вариант несколько раз помогал. за счет группировки кол-во обращений к sql снижается в несколько тысяч раз.
цитата
05/01/07 в 06:48
 Pentarh
Посмотрел я твою инфу и вот что скажу.

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

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

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

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


Эта страница в полной версии