Назад | Перейти на главную страницу

Двухъядерный четырехъядерный процессор Xeon, но все еще высокая нагрузка

У меня есть выделенный сервер со следующими характеристиками:

  1. Два процессора Intel Xeon-Harpertown 5430-Quadcore [2,66 ГГц]
  2. 4 ГБ оперативной памяти DDRII
  3. 500 ГБ SATAII HD
  4. CentOS 5.5 64-разрядная.

Проблема в том, что даже с такими характеристиками MySQL по-прежнему сильно загружает процессор. Он почти все время остается выше 150% и большую часть времени превышает 300%. Я узнал об этом после запуска команды «top». Теперь дело в том, что как только я запускаю "watch mysqladmin pr", чтобы увидеть, что происходит, я не вижу никаких проблем. Хотя есть запросы, выполняющиеся, но они не похожи на некоторые очень тяжелые запросы, за исключением одного или двух.

Я запустил mysqltunner.pl, и он показал мне следующее:

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 362M (Tables: 255)
[--] Data in InnoDB tables: 880K (Tables: 55)
[!!] Total fragmented tables: 2

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3h 26m 51s (1M q [138.122 qps], 43K conn, TX: 3B, RX: 246M)
[--] Reads / Writes: 93% / 7%
[--] Total buffers: 830.0M global + 3.9M per thread (300 max threads)
[OK] Maximum possible memory usage: 1.9G (50% of installed RAM)
[OK] Slow queries: 0% (47/1M)
[OK] Highest usage of available connections: 6% (18/300)
[OK] Key buffer size / total MyISAM indexes: 256.0M/169.9M
[OK] Key buffer hit rate: 100.0% (5B cached / 36K reads)
[OK] Query cache efficiency: 84.2% (1M cached / 1M selects)
[!!] Query cache prunes per day: 338346
[OK] Sorts requiring temporary tables: 0% (989 temp sorts / 242K sorts)
[!!] Temporary tables created on disk: 38% (160K on disk / 420K total)
[OK] Thread cache hit rate: 99% (18 created / 43K connections)
[OK] Table cache hit rate: 98% (446 open / 452 opened)
[OK] Open file limit used: 1% (663/65K)
[OK] Table locks acquired immediately: 99% (684K immediate / 684K locks)
[OK] InnoDB data size / buffer pool: 880.0K/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Temporary table size is already large - reduce result set size
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
    query_cache_size (> 64M)
------------------------------------------------------------------------------

Как видите, большинство параметров верны, за исключением нескольких вроде двух таблиц дефрагментации и небольшого размера кеша запросов. Даже если я исправлю это, я не увижу заметного увеличения производительности. Итак, теперь я обратил свое внимание на «Временные таблицы, созданные на диске 38%». Как вы думаете, это из-за того, что MySQL занимает слишком много процессорного времени? Как я могу это улучшить? Или вы думаете, что после просмотра результата есть что-то еще?

В настоящее время мои настройки временных таблиц в конфигурационном файле MySQL:

tmp_table_size = 1000M max_heap_table_size = 500M

Даже если я увеличу эти значения, MySQL все равно будет создавать временные таблицы на диске. Как мне это исправить? Я вижу, что mysqltuner.pl также говорит, что мне нужно уменьшить свой набор результатов, но если я дам ему много ОЗУ для создания временных таблиц, не должна ли проблема исчезнуть?

Спасибо

Возможно, вы обращаетесь к симптому, а не к проблеме. Для начала посмотрите, что делает вашу нагрузку такой высокой. Это активность в режиме ядра? Это активность пользователя? Если это режим ядра, я предполагаю, что у вас проблемы с записью на диск достаточно быстро, а io находится в состоянии ожидания. Посмотрите на такие инструменты, как top, iostat, vmstat и т. Д., Чтобы начать сужать проблему.

При такой высокой нагрузке вы, вероятно, увидите какое-то ожидание, которое заставляет ядро ​​ставить запросы в очередь.

Пожалуйста, проверьте несколько вещей:

1) join_buffer_size
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_join_buffer_size
http://www.mysqlperformanceblog.com/2010/07/05/how-is-join_buffer_size-allocated/

2) sort_buffer_size
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_join_buffer_size

3) Создание временного файла
http://dev.mysql.com/doc/refman/5.1/en/ Contemporary-files.html

4) SELECT запросы, которые имеют вложенные SELECT

Вероятно, у вас есть много запросов, которые выполняют медленное соединение из-за наличия таблиц без индексируемых столбцов.

Если ваш буфер соединения / буфер сортировки в данном соединении с БД слишком мал для хранения временных результатов, буфер соединения и / или буфер сортировки должны будут выгружаться на диск в виде временной таблицы.