powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Оптимизация MySQL по результатам mysqltuner.pl
41 сообщений из 41, показаны все 2 страниц
Оптимизация MySQL по результатам mysqltuner.pl
    #38264567
Inside22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброго дня,

буду очень признателен если вы мне поможете в оптимизации MySQL.

[!!] Query cache efficiency: 1.5% (15K cached / 999K selects)

Я правильно понимаю, всего лишь 1.5% из всех запросов кешируются?

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

[!!] Joins performed without indexes: 3122
Выходит что у меня слишком много запросов которые выполняются без индекса.
Можно ли как то логировать запросы которые выполняются без индекса?

[OK] InnoDB data size / buffer pool: 1.2G/2.0G
Размер базы данных 1.2G, а размер буфера 2.0G?
Разве буфер это не то место где кешируются запросы?

[--] Reads / Writes: 99% / 1%
Большинство запросов у меня на чтение, поэтому можно смело ставить индексы на все возможные поля используемые в запросах-выборках.

[--] Total buffers: 5.3G global + 2.0G per thread (151 max threads)
[!!] Maximum possible memory usage: 307.7G (1976% of installed RAM)

Кол-во тредов я ручками не увеличивал, но интуиция подсказывает что это слишком большое значение для max_connections, так как Max_used_connections = 25
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264607
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
у тя проблемы какие или так, любопытства ради?
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264695
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22[!!] Query cache efficiency: 1.5% (15K cached / 999K selects)

Я правильно понимаю, всего лишь 1.5% из всех запросов кешируются?

Подскажите пожалуйста от каких параметров зависит кеширование запросов? Каким образом можно выяснить почему такой низкий показатель кеширования?Понимаете правильно. Варианты могут быть разные. Наиболее вероятный - мал кэш запросов. А еще не все запросы в принципе могут кэшироваться. Например, те, которые используют текущую дату/время, случайные числа, гуиды и т.п.Inside22[!!] Joins performed without indexes: 3122
Выходит что у меня слишком много запросов которые выполняются без индекса.
Можно ли как то логировать запросы которые выполняются без индекса?См. в доке Slow log, там есть опция, которая позволяет кэшировать запросы без применения индексов. Однако сами по себе таки запросы не являются автоматически плохими, с ними надо разбираться.Inside22[OK] InnoDB data size / buffer pool: 1.2G/2.0G
Размер базы данных 1.2G, а размер буфера 2.0G?
Разве буфер это не то место где кешируются запросы?Нет, это кэш таблиц и индесов InnoDB. Кэш запросов - это query_cache_size Inside22[--] Total buffers: 5.3G global + 2.0G per thread (151 max threads)
[!!] Maximum possible memory usage: 307.7G (1976% of installed RAM)2.0G per thread - это очень много, почти наверняка сильно избыточно.

Почитайте http://dev.mysql.com/doc/refman/5.5/en/memory-use.html
Там в т.ч. расписано, какие буфера выделяются на сессию.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264704
Shahriyar.R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Inside22,

First of all every time you ask questions write MySQL version and Platform.

1.
[!!] Query cache efficiency: 1.5%
So it indicates that your data and queries changes frequently that q_cache simple cant cache your selects. or your select dont use q_cache
I advice just disable query_cache permanently:
Код: sql
1.
2.
3.
query_cache_type               = 0
query_cache_size               = 0
query_cache_limit              = 0


2.
[!!] Joins performed without indexes: 3122
You can enable slow_query_log with logging queries that dont use indexes.
Write into my.cnf under [mysqld] catalog:
Код: sql
1.
2.
3.
4.
# LOGGING #
log_queries_not_using_indexes  = 1
slow_query_log                 = 1
slow_query_log_file            = /var/lib/mysql/mysql-slow.log


But it is very memory consuming process. because your slow log may grow very large. Just run MySQL for a 3 hours eg. to log queries then disable this feature.
log_queries_not_using_indexes = 0

3.
Разве буфер это не то место где кешируются запросы?
NO. Read documentation for innodb_buffer_pool:
InnoDB Buffer Pool

InnoDB maintains a storage area called the buffer pool for caching data and indexes in memory

4.
WOW 2.0G per thread??!! Something going wrong here.
151x2G=302G
302G+5.3G~~307.3 G = 1976% of installed RAM :D

It must be 2.2 or 2.8 MB per thread. Your per-session variables must be given too large it is very dangerous:
Check out them:
Код: sql
1.
2.
3.
select @@sort_buffer_size;
select @@read_buffer_size;
select @@read_rnd_buffer_size;
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264706
Shahriyar.R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,

sorry i dont refresh page while writing comment. You have already answered ;)
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264712
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shahriyar.Rmiksoft,

sorry i dont refresh page while writing comment. You have already answered ;)Ничего страшного. Ваш ответ содержит несколько другой взгляд на вещи, так что это только приветствуется.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264727
Shahriyar.R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,

Thumbs up! :)
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264799
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shahriyar.R. Your per-session variables must be given too large it is very dangerous:

На самом деле нет. очень редки случаи когда все буфера используются на 100%.
В реальности нужно мониторить фактическое среднее потребление памяти mysql-ем, а не бросаться в панику от дебильных советов mysqltuner
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264854
Shahriyar.R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
netwind,

there is really a big reason to panic. you should not touch per-session variables untill the query really needs it.
From High Perfomance MySQL 3rd edition book page 336 chapter 8:


1. read_buffer_size
MySQL doesn’t allocate any memory for this buffer until a query needs it, but then
it immediately allocates the entire chunk of memory
specified here.

2. read_rnd_buffer_size
MySQL doesn’t allocate any memory for this buffer until a query needs it, and then
it allocates only as much memory as needed. (The name max_read_rnd
_buffer_size would describe this variable more accurately.)


3. sort_buffer_size
MySQL doesn’t allocate any memory for this buffer until a query needs to do a
sort. However, when there’s a sort, MySQL allocates the entire chunk of memory
immediately, whether the full size is required or not.



You should not raise the value of a per-connection setting globally unless you know it’s
the right thing to do. Some buffers are allocated all at once, even if they’re not needed,
so a large global setting can be a huge waste. Instead, you can raise the value when a
query needs it.
The most common example of a variable that you should probably keep small and raise
only for certain queries is sort_buffer_size, which controls how large the sort buffer
should be for filesorts. MySQL performs some work to initialize the sort buffer after
allocating it.
In addition, the sort buffer is allocated to its full size even for very small sorts, so if you
make it much larger than the average sort requires, you’ll be wasting memory and
adding allocation cost.
In summary, a large sort buffer can be very expensive, so don’t increase its size unless
you know it’s needed.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264926
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Shahriyar.R, раз уж в этой в книге не обсуждается вероятность одновременного использования всех трех типов буферов сразу во всех потоках, не вижу оснований приводить тут цитатки в качестве аргументации.
В стандартном использовании mysql для веб максимальное число соединений определяется не на основе max_connections, а на лимитах веб-сервера. Я посмотрел код и вижу, что скрипт определяет планку исключительно из max_connections.
И ТС даже привел данные по фактической планке :
авторКол-во тредов я ручками не увеличивал, но интуиция подсказывает что это слишком большое значение для max_connections, так как Max_used_connections = 25

так что паника скорее не нужна. Нужен мониторинг.

Кстати, с tmp_table_size и max_heap_table_size не понятно. Несмотря на очевидное использование этих переменных per-thread, планка начала паники должна бы снизиться еще ниже, однако судя по коду, авторы скрипта решили не использовать их для прогноза. Ну что за бардак ? Где единообразие?
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264947
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftкоторая позволяет кэшировать запросы без применения индексов"логировать" же :)
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38264949
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tanglirmiksoftкоторая позволяет кэшировать запросы без применения индексов"логировать" же :)Да, сорри.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265002
Inside22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoft,
спасибо большое за дельные советы.

Shahriyar.R,
thank you for advice. Cox maraqlı bloqunuz vardır.

База работает, по большому счету проблем нету, но есть запросы которые выполняются по 1-4 секунды.

К примеру есть у меня один очень странный пример:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
{
-- первый запрос
} UNION ALL {
-- второй запрос
} UNION ALL {
-- третий запрос
} UNION ALL {
-- четвертый запрос
}



Это все выполняется в течении 3 секунд. Каждый же запрос по отдельности выполняется в течении 0,15 секунд.
Я первый раз сталкиваюсь с таким явлением.

После этого я увеличил нижеперечисленные параметры согласно советам MYSQLTUNER.PL, после этого 3-х секундный запрос начал выполнятся за 0,15 секунд, но только со второго раза. После рестарта ДБ первый раз запрос выполняется все равно по 3 секунды.


Код: php
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
innodb_file_per_table=1
max_allowed_packet=2048M

#razmer bufera, vydeljaemogo pod indeksy i dostupnogo vsem potokam.
#rekomenduetsja 15-30% ot obshhego ob#ema OZU.
key_buffer_size=2048M

#razmer bufera, vydeljaemogo MyISAM dlja sortirovki indeksov pri REPAIR TABLE i$
myisam_sort_buffer_size=1024M

default-storage-engine=MyISAM
collation_server=utf8_general_ci
character_set_server=utf8

local-infile=0

#razmer pamjati, vydeljaemyj InnoDB dlja hranenija razlichnyh vnutrennih strukt
#esli InnoDB budet nedost,atochno jetoj pamjati to budet zaproshena pamjat u OS
innodb_additional_mem_pool_size=1024M

#razmer pamjati, vydeljaemyj InnoDB dlja hranenija i indeksov i dannyh.
# Mozhno uvelichivat vplot do obshhego razmera vseh InnoDB tablic ili do 80% $
innodb_buffer_pool_size=2G

innodb_flush_log_at_trx_commit=1

query_cache_size=256M
join_buffer_size=256M
thread_cache_size=36
query_cache_limit=256M
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265016
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22К примеру есть у меня один очень странный пример:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
{
-- первый запрос
} UNION ALL {
-- второй запрос
} UNION ALL {
-- третий запрос
} UNION ALL {
-- четвертый запрос
}

Это все выполняется в течении 3 секунд. Каждый же запрос по отдельности выполняется в течении 0,15 секунд.
Я первый раз сталкиваюсь с таким явлением.А я вот не первый. И встречались ситуации, когда единственным действенным вариантом было переделывать клиентское приложение так, чтобы оно последовательно вызвало четыре запроса по-отдельности.

Inside22после этого 3-х секундный запрос начал выполнятся за 0,15 секунд, но только со второго раза. После рестарта ДБ первый раз запрос выполняется все равно по 3 секунды.Само по себе это логично, разнообразные кэши должны наполниться, прежде чем начать работать эффективно.

Inside22
Код: php
1.
2.
key_buffer_size=2048M
innodb_buffer_pool_size=2G

Не понял, вы одновременно используете оба типа таблиц?
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265027
Inside22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Сервер достаточно мощный
CentoS 6
MySQL 5.5.30
2 процессора Intel Xeon E5620 @ 2.40GHz (Cores 4, Threads 8)
Hard disks4x300GB SAS 15k
RAM 16GB
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265029
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22RAM 16GBА, так вот почему вы так вольно память раздаете.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265030
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22увеличил нижеперечисленные параметры согласно советам MYSQLTUNER.PL, ...
запрос выполняется все равно по 3 секунды.

А ну вот тут и стоило задуматься, зачем вообще лезть мучать параметры, если их изменения ни к чему не привели?
Может нужно позвать программиста?
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265032
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft[А я вот не первый. И встречались ситуации, когда единственным действенным вариантом было переделывать клиентское приложение так, чтобы оно последовательно вызвало четыре запроса по-отдельности.


Раз уж у нас топик армянского английского, процитируем золотые бессмертные строки
Schwartz B., Zaitsev P., Tkachenko V. - High Performance MySQL, 3rd Edition It’s usually better to configure the basic settings correctly (and there are only a few that really matter
in most cases) and spend more time on schema optimization, indexes, and query design.
After you’ve set MySQL’s basic configuration options correctly, the potential gains
from further changes are usually small .

В русской редакции второго издания этот абзац - полнейшая безысходность:
Возможно, вы заметите, что некоторый запрос выполняется медленно, и сумеете улучшить
его, подправив один-два параметра, но заставить сервер работать на порядок быстрее удается крайне редко .
Чтобы достичь такого результата, обычно приходится пересматривать схему, запросы и всю архитектуру приложения.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265033
Inside22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoftСамо по себе это логично, разнообразные кэши должны наполниться, прежде чем начать работать эффективно.
Ничего себе. Не знал и ни когда не сталкивался с таким явлением.

Странно очень, получается что MySQL сам не может выполнить 4 запроса и объедить? Интересно, с чем связано такое резкое увеличение времени? Есть ли этому какое то логическое объяснение?
miksoftInside22
Код: php
1.
2.
key_buffer_size=2048M
innodb_buffer_pool_size=2G


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

key_buffer_size=2048M это пережитки оставшиеся с момента установки на сервер MySQL.
База данных у нас InnoDB.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265054
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22Странно очень, получается что MySQL сам не может выполнить 4 запроса и объедить? Интересно, с чем связано такое резкое увеличение времени? Есть ли этому какое то логическое объяснение?Думаю, это связано с материализацией подзапросов... во всяком случае не раз сталкивался, когда UNION ALL нескольких быстрых объёмных запросов из однотипных пухлых таблиц даёт немеряные тормоза - и зачастую формирование MERGE-надтаблицы снимает проблему.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265069
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22miksoftСамо по себе это логично, разнообразные кэши должны наполниться, прежде чем начать работать эффективно.Ничего себе. Не знал и ни когда не сталкивался с таким явлением.Это общее свойство всех (не только в СУБД) кэшей при операциях чтения.
Inside22Странно очень, получается что MySQL сам не может выполнить 4 запроса и объедить? Интересно, с чем связано такое резкое увеличение времени? Есть ли этому какое то логическое объяснение?Могу (глядя в потолок) предположить, что MySQL пытается разместить весь результирующий набор в памяти, которой не хватает, в результате чего выборка уезжает на диск.
Но детально я этот вопрос не исследовал, могу и ошибаться.
Inside22key_buffer_size=2048M это пережитки оставшиеся с момента установки на сервер MySQL.
База данных у нас InnoDB.Ну так сократите key_buffer_size до, например, 64М. Если объектов (таблиц) в БД очень много, то, возможно, понадобится немного побольше.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265109
Фотография Akina
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftМогу (глядя в потолок) предположить, что MySQL пытается разместить весь результирующий набор в памяти, которой не хватает, в результате чего выборка уезжает на диск.Скорее всего так. Причём уезжает она туда ВСЯ, а не только непоместившийся в мозгах шмот. И отдаётся на клиента она тоже ВСЯ с диска. И ещё - если такая фигня произошла, результаты этого запроса искать в кэше бессмысленно, второй раз всё повторится с самого начала.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265147
Shahriyar.R
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Inside22,

Here is What i found from your my.cnf as misconfiguration:
* max_allowed_packet=2048M value is very high. in my production server i gave this value only 16M
* key_buffer_size=2048M if your tables primarily InnoDB why use 2G myisam key buffer?. also in my server i put this value only 16M
* myisam_sort_buffer_size=1024M . the default value for this variable is only 8M and let it be as default.
* innodb_additional_mem_pool_size=1024M is too high again. Maybe the 20M will be better for this variable.
But if you want exaclty optimize this value. You can check and find optimal value as :
Код: sql
1.
2.
3.
4.
5.
6.
7.
show engine innodb status;

----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated xxxx; in additional pool allocated xxxx
Dictionary memory allocated xxxxx



25-30% more than the value from "in additional pool allocated"
But i dont think that it is very important at this moment.

* innodb_buffer_pool_size=2G too low. if you have Centos with 16G with InnoDB why you dont give for eg 10G to innodb_buffer?
* join_buffer_size=256M what kind of join will use 256M? do not touch per-session variables instead of try to do first of all query optimization with proper indexing techniques. So i suggest to delete this from my.cnf
You can read about join_buffer_size from What is join buffer?
If to give large value to this variable you will likely see following bug/error: Join buffer allocation fails silently

*автор после этого 3-х секундный запрос начал выполнятся за 0,15 секунд, но только со второго раза. После рестарта ДБ первый раз запрос выполняется все равно по 3 секунды.

Maybe it is because of your query_cache so i advice to disable query_cache enable slow_query_log run for a while and check the slow query log with a tool from percona toolkit pt-query-digest.
If problem exists and you can not solve open new topic with your slow query. experts surely will help.


The main question of this topic , i think is answered. the pros-cons of variables observed by experts such miksoft , Akina , netwind
So dear Inside22 read all comments take your notes.
I think that was the best discussion in forum that i participate it is really great pleasure to be with you ;)
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38265472
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Akina,

Ежели слегка вспомнить что всё крутится на банальном Фон Неймане, то медленное исполнение union и даже all - ничегшо удивительного не содержит. Это "дорогая" операция для него. Надо последовательно выбрать данные в 4 временных буфера, а потом(!) собрать всё вместе в один буфер перебирая буфера позаписно... а потом(!) результат отдать клиенту. Объем временных данных, опять же сильно зависит от количества выбираемых столбцов (ширины), а не токмо строк.

.. и вот тут, для временных буферов может оказаться недостаточно памяти и они полезут на диск (как правило, внезапно и неожиданно: работало вроде же! угу... пока объем выборки был мал)
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38270875
InterSky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть лог медленных запросов, есть лог запросов которые не используют индексы...
Почему нету лога запросов которые задействуют диск?
Ну или хотябы расширеного EXPLAIN который бы показал что и насколько задействовалось при выполнении запроса? (сколько и в каких буферах/дисках занял места)
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38271052
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
InterSkyЕсть лог медленных запросов, есть лог запросов которые не используют индексы...
Почему нету лога запросов которые задействуют диск?
Ну или хотябы расширеного EXPLAIN который бы показал что и насколько задействовалось при выполнении запроса? (сколько и в каких буферах/дисках занял места)
Потому практика использования задает возможности ПО. Все возможности строятся из практических потребностей.
Медленные запросы как раз и задействуют диск.

Отдельно в патчах от percona есть специальные данные задействована ли сортировка на диске и по операциям чтения innodb. Может поможет вам.

Расширенный explain называется show profile и show status .
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38272658
Inside22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
доброго времени суток.
спасибо вам за ценнейшие советы.
на данный момент чисто визуально работа с БД стала на много быстрее. От отдела продаж жалобы больше не поступают.

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

На данный момент у меня вот чего:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
default-storage-engine=INNODB
collation_server=utf8_general_ci
character_set_server=utf8

innodb_file_per_table=1
max_allowed_packet=512M

local-infile=0
innodb_additional_mem_pool_size=512M
innodb_buffer_pool_size=2048M
innodb_flush_log_at_trx_commit=1

query_cache_size=512M
join_buffer_size=2G
thread_cache_size=36
query_cache_limit=512M

key_buffer_size=2048M
join_buffer_size=512M



Вот с этим конфигом я получил не плохой прирост эффективности кеша, до 24.0% выросло значение.


Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
 >>  MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>;
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.30-cll
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 26M (Tables: 64)
[--] Data in InnoDB tables: 1G (Tables: 167)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 23

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 2d 0h 16m 14s (840K q [4.839 qps], 46K conn, TX: 1B, RX: 187M)
[--] Reads / Writes: 52% / 48%
[--] Total buffers: 5.0G global + 2.0G per thread (151 max threads)
[color=red][!!] Maximum possible memory usage: 307.4G (1975% of installed RAM)[/color]
[color=green][OK] Slow queries: 0% (15/840K)[/color]
[OK] Highest usage of available connections: 29% (44/151)
[OK] Key buffer size / total MyISAM indexes: 2.0G/5.9M
[OK] Key buffer hit rate: 99.9% (1M cached / 721 reads)
[color=green][OK] Query cache efficiency: 24.0% (100K cached / 420K selects)[/color]
[!!] Query cache prunes per day: 2428
[OK] Sorts requiring temporary tables: 0% (8 temp sorts / 18K sorts)
[!!] Joins performed without indexes: 20848
[OK] Temporary tables created on disk: 17% (5K on disk / 32K total)
[OK] Thread cache hit rate: 99% (50 created / 46K connections)
[OK] Table cache hit rate: 52% (348 open / 663 opened)
[OK] Open file limit used: 4% (179/4K)
[OK] Table locks acquired immediately: 100% (465K immediate / 465K locks)
[OK] InnoDB data size / buffer pool: 1.2G/2.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Enable the slow query log to troubleshoot bad queries
    Increasing the query_cache size over 128M may reduce performance
    Adjust your join queries to always utilize indexes
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (> 512M) [see warning above]
    join_buffer_size (> 2.0G, or always use indexes with joins)




Буду очень вам признателен если вы мне подскажите каким образом можно логировать запросы в которых не использовались индексы.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38272664
Inside22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Текущие значения:

max_heap_table_size=16M
tmp_table_size=16M

Увеличу до:

max_heap_table_size=64M
tmp_table_size=64M

через пару дней проверю разницу в анализе mysqltuner-a.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38272672
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22
Код: sql
1.
2.
3.
[--] Data in MyISAM tables: 26M (Tables: 64)
[OK] Key buffer size / total MyISAM indexes: 2.0G/5.9M
[OK] Key buffer hit rate: 99.9% (1M cached / 721 reads)

Ну и зачем нам такой тюнинг в Воронежском зоопарке? (с)

И join_buffer_size зачем так задран? Чем значение по умолчание не нравится?
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38272677
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22Текущие значения:

max_heap_table_size=16M
tmp_table_size=16M

Увеличу до:

max_heap_table_size=64M
tmp_table_size=64M

через пару дней проверю разницу в анализе mysqltuner-a.Последите за размером временных файлов, обычно они создаются в /tmp.
Если файлов много и/или они большие, то эти величины лучше увеличить.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38272678
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22Буду очень вам признателен если вы мне подскажите каким образом можно логировать запросы в которых не использовались индексы. http://dev.mysql.com/doc/refman/5.5/en/slow-query-log.html log_queries_not_using_indexes must be enabled
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38272684
Inside22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Добавляю логирование медленных запросов которые были выполнены без использования индексов.

log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
log-queries-not-using-indexes
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38272694
Inside22
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
miksoftInside22
Код: sql
1.
2.
3.
[--] Data in MyISAM tables: 26M (Tables: 64)
[OK] Key buffer size / total MyISAM indexes: 2.0G/5.9M
[OK] Key buffer hit rate: 99.9% (1M cached / 721 reads)

Ну и зачем нам такой тюнинг в Воронежском зоопарке? (с)

И join_buffer_size зачем так задран? Чем значение по умолчание не нравится?

Я правильно понимаю, key_buffer_size используется только при работе с MyISAM базой данных?

Это я в самом начале своего пути понатыкал максимальные значения... а сейчас каждую конфигурацию изучаю :-)
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38272705
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Inside22Я правильно понимаю, key_buffer_size используется только при работе с MyISAM базой данных?Да.
Чтобы про каждый параметр не переспрашивать - вот справочник .
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38492921
morgot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чтобы не создавать новую тему, спрошу здесь. Есть база данных около гигабайта, MyISAM, изменять ее структуру не могу, могу лишь настраивать параметры Mysql-сервера. Тюнер пишет такое:

[!!] Highest connection usage: 99% (109/110)
[!!] Query cache prunes per day: 22868
[!!] Joins performed without indexes: 31442
[!!] Table cache hit rate: 1% (309 open / 26K opened)


Это очень плохо? И можно ли что-то поменять, учитывая что структуру БД (добавить индексы эти) я вряд ли смогу поменять (это цмс, и там наверное надо все переписывать).
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38492929
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morgot,

Сколько времени отработал MySQL к моменту снятия показаний?
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38492945
morgot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft, авторUp for: 1d 18h 38m 3s
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38492957
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morgot,

Это примерно 153000 секунд.
Получается в среднем каждые 5 секунд выполняется запрос с join-ом без индексов. Много это или мало пока сказать нельзя, возможно это копеечный запрос. Но, имхо, стоит исследовать этот вопрос. Включите slow_query_log и log_queries_not_using_indexes и посмотрите, что туда нападает.

Highest connection usage: 99% - тоже нехорошо, но это, скорее всего, лишь следствие каких-то тормозов.

Table cache hit rate: 1% - маловато, попробуйте увеличить table_open_cache (table_cache в старых версиях) в несколько раз.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38493283
morgot
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft, включил slow_query_log на зеркале, т.е. на ресурсе без посетителей, чтобы там экспериментировать. Поймал 2 запроса, на 8 и 13 секунд. К сожалению, не могу понять, можно ли что-то оптимизировать, так как запрос сложный, но вероятно на него жалуется Mysql tuner (JOIN без индекса).

Код: sql
1.
2.
3.
4.
5.
6.
7.
SELECT lmr.id_member, lmr.id_msg, t.id_topic
                FROM table_topics AS t
                        INNER JOIN table_log_mark_read AS lmr ON (lmr.id_board = t.id_board
                                AND lmr.id_msg > t.id_first_msg AND lmr.id_msg > 487040)
                        LEFT JOIN table_log_topics AS lt ON (lt.id_topic = t.id_topic AND lt.id_member = lmr.id_member)
                WHERE t.id_topic IN (15242)
                        AND lmr.id_msg > IFNULL(lt.id_msg, 0);



Второй раза в три больше. Phpmyadmin пишет, что в таблицах нет индексов и primary key, может стоит добавить? Там действительно идут просто значения, без нумерации. Могу привести структуру таблицы или еще какие-нибудь данные.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38493298
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторМогу привести структуру таблицы или еще какие-нибудь данные.
explain запроса давай.
...
Рейтинг: 0 / 0
Оптимизация MySQL по результатам mysqltuner.pl
    #38493478
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
morgotизменять ее структуру не могу, могу лишь настраивать параметры Mysql-сервера.
достаточно. можно сразу в сад.
...
Рейтинг: 0 / 0
41 сообщений из 41, показаны все 2 страниц
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Оптимизация MySQL по результатам mysqltuner.pl
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]