Изменение памяти для производительности MySQL - MySQLTuner - PullRequest
0 голосов
/ 12 июня 2018

У меня недавно были проблемы с тем, что в моей системе заканчивались соединения с MySQL (технически MariaDB).

Я установил max_connections на 250 (вместо 151).Но я запутался в том, как мне нужно распределять оперативную память.Машина имеет 32 ГБ оперативной памяти, и если я правильно читаю результаты из mysqltuner ... Я разрешаю использовать только до 1 ГБ.Но при 250 соединениях * 2,8M / поток он должен достигать 700M + глобальный уровень в 328M?

Похоже, мы достигли пика в 755M.Но с учетом того, что у меня есть лишняя память, я должен немного открыть ее, чтобы позволить MariaDB дышать?

Правильно ли я читаю?

Эта машина работает как сервер apache & db.Даже при полном наклоне я редко вижу, как машина использует более 3 или 4 ГБ общей системной памяти

Я запустил mysqltuner и вот результаты производительности:

-------- Performance Metrics -----------------------------------------------------------------------
[--] Up for: 34d 1h 32m 42s (74M q [25.213 qps], 26M conn, TX: 46G, RX: 42G)
[--] Reads / Writes: 98% / 2%
[--] Binary logging is disabled
[--] Physical Memory     : 31.5G
[--] Max MySQL memory    : 1.0G
[--] Other process memory: 647.4M
[--] Total buffers: 328.0M global + 2.8M per thread (250 max threads)
[--] P_S Max memory usage: 0B
[--] Galera GCache Max memory usage: 0B
[OK] Maximum reached memory usage: 755.5M (2.34% of installed RAM)
[OK] Maximum possible memory usage: 1.0G (3.20% of installed RAM)
[OK] Overall possible memory usage with other process is compatible with memory available
[OK] Slow queries: 0% (0/74M)
[OK] Highest usage of available connections: 60% (152/250)
[OK] Aborted connections: 0.00%  (2/26423553)
[!!] name resolution is active : a reverse name resolution is made for each new connection and can reduce performance
[!!] Query cache may be disabled by default due to mutex contention.
[OK] Query cache efficiency: 45.7% (21M cached / 47M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 1% (541 temp sorts / 32K sorts)
[!!] Joins performed without indexes: 24537
[OK] Temporary tables created on disk: 1% (644 on disk / 51K total)
[OK] Thread cache hit rate: 98% (383K created / 26M connections)
[!!] Table cache hit rate: 0% (120 open / 36K opened)
[OK] Open file limit used: 0% (24/4K)
[OK] Table locks acquired immediately: 99% (5M immediate / 5M locks)

1 Ответ

0 голосов
/ 12 июня 2018

Вы должны понимать, что вычисление MySQLtuner "Max MySQL Memory" - полная чушь.

Это основано на теоретическом максимуме - который возможен, только если вы максимизируете max_connections, а затем каждое соединение выполняетсязапрос в точно в тот же момент, и каждый из этих запросов использует максимально возможные буферы сортировки, буферы чтения и буферы соединения.Реально, это никогда не произойдет на реальном сервере.

Когда я запускаю MySQLTuner на большинстве поддерживаемых серверов баз данных, максимальный объем памяти MySQL сообщается как в сотни раз больше , чемфактическая физическая память на сервере.Это не проблема, потому что это теоретический максимум, которого никогда не будет на самом деле.

Если вы запустите SHOW PROCESSLIST на своем сервере базы данных, даже если все 150 или 250 потоков подключены, вы увидите только 6-8 потоков выполняют запрос, в то время как большинство других потоков находятся в состоянии «Sleeping».

Это как если бы вы вошли на сервер с ssh и ваш терминал готов к работе по приглашению оболочки.У вас есть какая-нибудь команда?Нет. Ваша оболочка бездействует.Но вы все еще подключены .

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

В любой данный момент число подключенных потоков может быть большим, даже если эти соединения, на самом деле выполняющие запрос, невелики.Вы можете сравнить:

mysql> show global status like 'Threads%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 510   |
| Threads_running   | 13    |
+-------------------+-------+

Выше приведены типичные числа из занятого производственного экземпляра MySQL.По моему опыту, соотношение потоков, подключенных к потокам, работает в диапазоне от 10: 1 до 100: 1.

Но вычисления MySQLTuner не реалистичны - они предполагают, что отношение потоков, подключенных к потокам, составляет 1: 1.

Таким образом, память, которую вы выделяете для MySQL, не имеет ничего общего с max_connections, который вы разрешаете.

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

Я рекомендую прочитать https://www.percona.com/blog/2016/10/12/mysql-5-7-performance-tuning-immediately-after-installation/

Или, если вы хотите углубиться в изучение, прочитайте: Высокопроизводительный MySQL, 3-е издание

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...