Pull to refresh

Comments 19

А объяснить, что это такое, как оно связано, и как выбирать значение «от 8 до 100»?
Рекомендуется постепенно повышать значение thread_cache_size и наблюдать за Threads_created до тех пор, пока Threads_created будет незначительно больше Threads_cached.

Подробнее на эту тему можно прочитать по адресу mysqltips.blogspot.ru/2007/03/mysql-threads-tunning.html
А какой смысл в вашем посте без объяснения, что это все значит?
Кстати, вот реальный пример, как изменилась нагрузка при изменении thread_cache_size с 8 до 50 (настройку применил примерно в 23:00):
cacti cpu load
На таком графике не видно. Приложите суточные графики до оптимизации и после.
Приведите лучше цифры. Ибо по графикам я могу судить лишь о ночном спаде нагрузки.
mysqladmin -u root -p extended-status | grep Threads
Enter password:
| Threads_cached | 57 |
| Threads_connected | 24 |
| Threads_created | 619671 |
| Threads_running | 2 |

/etc/mysql/my.cnf:thread_cache_size = 64

mysql Ver 14.14 Distrib 5.5.25a

Cколько ставить? :)
Неплохой у вас проект судя по цифрам. У меня показатели почти как у вас, только чуть ниже. Стоял thread_cache_size 32, сделал 64. Будем посмотреть.
Поделитесь графиками, если будет существенный результат :-)
Попробуйте поставить 96 и понаблюдать.
Какие минусы? Сейчас на одном из проектов thread_cache_size отключен (0).
| Threads_cached                           | 0             |
| Threads_connected                        | 4             |
| Threads_created                          | 17591353      |
| Threads_running                          | 4             |

Стоит включить?
Threads_created практически равно числу соединений (Connections).
| Threads_cached                        | 2             |
| Threads_connected                     | 1             |
| Threads_created                       | 3             |
| Threads_running                       | 1             |

Миллионы запросов в сутки. Но — fastcgi + persistent connection.
Более интересные формулы:

Мануал

dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_thread_cache_size

… if you have a lot of new connections… hundreds of connections per second…
… если у вас много новых соединений… сотни в секунду…


dev.mysql.com/doc/refman/5.0/en/server-status-variables.html#statvar_Threads_created

… The cache miss rate can be calculated as Threads_created/Connections…
… Коэффициент «недокэша» м.б. посчитан как Threads_created/Connections…


=> Для того, чтобы понять, стоит ли включать, надо вычислить среднее число соединений в секунду. Вот если их сотни, то тогда следует. Число соединений в секунду вычисляется, как Threads_created / Uptime. Если у нас жалкие числа, явно меньше ста, то извините.

olemskoi, может ли быть, что улучшение произошло из-за чего-то другого? Или там были некие пики — т.е. всё время условно мало соединений в секунду и тут опа — тыщи их. Может быть такое?

Стэк

serverfault.com/questions/408845/what-value-of-thread-cache-size-should-i-use

… At the very least, thread_cache_size should be greater than Max_used_connections…
… Как минимум, thread_cache_size д.б. больше Max_used_connections…


dev.mysql.com/doc/refman/5.0/en/server-status-variables.html#statvar_Max_used_connections

=> Вот это мне даже больше нравится — тупо смотрим, а сколько же у нас в принципе было в свое время одновременных подключений и делаем чутка больше. Затем уже играем с другими формулами.
а если выставить thread_cache_size с запасом скажем сразу поставить 100 или 500?
Будет резервировать впустую оперативную память.
Sign up to leave a comment.

Articles