Оптимизация Mysql для VPS

Оптимизация Mysql для VPS

У меня возникли некоторые проблемы с оптимизацией настроек mysql моего VPS (Linux / Cpanel). Я не очень разбираюсь в Mysql и использую этот VPS примерно для 50 разных веб-сайтов. У всех было менее 100 посетителей в день, так что трафик не является моей проблемой. Мой VPS работает хорошо в данный момент, но меня беспокоят [!!] предупреждения в mysqltuner.pl, стоит ли мне беспокоиться?

=> Информация о моем VPS:

Processor Information
**Total processors: 6**
Processor #1
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #2
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #3
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #4
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #5
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB
Processor #6
Vendor
GenuineIntel
Name
Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
Speed
2394.454 MHz
Cache
15360 KB

Memory Information
Memory: 30789880k/**32505856k** available (5336k kernel code, 1050056k absent, 665920k reserved, 7016k data, 1288k init)

System Information
Linux xl.xlxlxl.com 2.6.32-504.12.2.el6.x86_64 #1 SMP Wed Mar 11 22:03:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Current Memory Usage
             total       used       free     shared    buffers     cached
Mem:      30812400   30064332     748068        244    3883652   17129112
-/+ buffers/cache:    9051568   21760832
Swap:            0          0          0
Total:    30812400   30064332     748068

=> Мой.cnf:

[mysqld]
max_allowed_packet=268435456
open_files_limit=10000
query_cache_type=1
query_cache_size=768M
query_cache_limit=2048M
sort_buffer_size=4M
join_buffer_size=26M
read_rnd_buffer_size = 1M
max_heap_table_size = 1024M
tmp_table_size = 1024M
table_open_cache = 15000
innodb_log_buffer_size = 64M
max_connections=200
wait_timeout=26000
interactive_timeout=26000
innodb_buffer_pool_size=256M

=> Mysqltuner.pl:

 >>  MySQLTuner 1.4.0 - Major Hayden <[email protected]>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
[OK] Currently running supported MySQL version 5.6.23
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in MyISAM tables: 3G (Tables: 3156)
[--] Data in InnoDB tables: 183M (Tables: 1455)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 52)
[!!] Total fragmented tables: 5

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2d 20h 23m 59s (11M q [45.850 qps], 381K conn, TX: 85B, RX: 2B)
[--] Reads / Writes: 82% / 18%
[--] Total buffers: 2.1G global + 31.4M per thread (200 max threads)
[OK] Maximum possible memory usage: 8.2G (27% of installed RAM)
[OK] Slow queries: 0% (4/11M)
[OK] Highest usage of available connections: 7% (14/200)
[OK] Key buffer size / total MyISAM indexes: 8.0M/432.3M
[OK] Key buffer hit rate: 99.6% (493M cached / 1M reads)
[OK] Query cache efficiency: 59.6% (5M cached / 8M selects)
[!!] Query cache prunes per day: 143463
[OK] Sorts requiring temporary tables: 0% (16 temp sorts / 434K sorts)
[!!] Joins performed without indexes: 2610
[!!] Temporary tables created on disk: 83% (458K on disk / 550K total)
[OK] Thread cache hit rate: 99% (36 created / 381K connections)
[!!] Table cache hit rate: 13% (1K open / 12K opened)
[OK] Open file limit used: 1% (324/30K)
[OK] Table locks acquired immediately: 99% (4M immediate / 4M locks)
[!!] Connections aborted: 18%
[OK] InnoDB buffer pool / data size: 256.0M/183.9M
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Increasing the query_cache size over 128M may reduce performance
    Adjust your join queries to always utilize indexes
    Temporary table size is already large - reduce result set size
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
    Your applications are not closing MySQL connections properly
Variables to adjust:
    query_cache_size (> 768M) [see warning above]
    join_buffer_size (> 26.0M, or always use indexes with joins)
    table_open_cache (> 15000)

решение1

Идея mysqltuner — рекомендовать действия для лучшей производительности. Таблица оптимизации будет заботиться о фрагментации. Оптимизация больших таблиц занимает некоторое время, пока оптимизируемая таблица заблокирована. Обычно предупреждения с префиксом [!!]комментируются в General recommendationsразделе.

Перед настройкой параметров mysql по умолчанию, вам следует проверить ваши SQL-выражения и SQL-соединения. Объединения без индексов приводят к серьезным потерям производительности. Попробуйте использовать slow_queriesдля определения того, какие запросы следует оптимизировать.

Также размер набора результатов часто слишком велик. Представьте себе систему магазина с базой данных.

Пример

Допустим, у вас в системе магазина есть 10 000 товаров, тогда select * from items;вызов вернет все 10 000 товаров, поэтому размер вашего набора результатов составит 10 000. Но маловероятно, что вам действительно понадобятся все 10 000 товаров сразу.

Основная цель SQL на самом деле заключается в сокращении набора результатов с помощью фильтров, которые наиболее эффективно работают с индексами. Например, вы ищете все элементы, которые имеют желтый цвет, вы уменьшаете размер набора результатов наselect * from items where color="yellow";

Но если у вас есть несколько сотен желтых элементов, это все еще слишком много, чтобы отобразить на веб-странице. Поэтому вы ограничиваете свои результаты

select * from items where color="yellow" limit 1,10

для первой страницы из 10 пунктов

select * from items where color="yellow" limit 11,20

для следующей страницы и так далее ... .

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

Одним из наиболее полезных инструментов для отладки объединений и индексов является использование explainперед операторами select:

explain select i.name, l.address
    from items i
         inner join location l on i.location = l.id
    where l.description like '%universe%';

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

Связанный контент