Задавайте вопросы, мы ответим
Вы не зашли.
на сервере
# mysql -V
mysql Ver 14.14 Distrib 5.1.60, for portbld-freebsd7.4 (amd64) using 5.2
"Threads_connected" составляет в среднем 50.71, а количество запросов в секунду 11.76. в чем может быть дело? или это нормальное соотношение?
my.cnf:
[client]
default-character-set=cp1251
port = 3306
socket = /tmp/mysql.sock
[mysqld]
character-set-server=cp1251
collation-server=cp1251_general_ci
init-connect="SET NAMES cp1251"
port = 3306
socket = /tmp/mysql.sock
skip-external-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 70
query_cache_size= 32M
thread_concurrency = 8
log-bin=mysql-bin
log-warnings=2
server-id = 1
max_connections=400
innodb_data_home_dir = /var/db/mysql/innodb
innodb_data_file_path = ibdata1:10M:autoextend:max:1100M
innodb_log_group_home_dir = /var/db/mysql/innodb
innodb_buffer_pool_size = 1024M
innodb_additional_mem_pool_size = 20M
innodb_log_file_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table = 1
[mysqldump]
quick
max_allowed_packet = 16M
[mysql]
no-auto-rehash
[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M
[myisamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M
[mysqlhotcopy]
interactive-timeout
данные по тредам
| Threads_cached | 15 |
| Threads_connected | 73 |
| Threads_created | 834 |
| Threads_running | 1 |
имеет ли смысл увеличивать количество кэшируемых тредов?
с mysql работают postfix, clamav, spamassassin
PS. при этом в соседнем jail (только веб проекты) "Threads_connected" в среднем 3.73, а запросов с секунду 90.
| Threads_cached | 60 |
| Threads_connected | 3 |
| Threads_created | 63 |
| Threads_running | 1 |
при том же значении
thread_cache_size = 70
Неактивен
А что Вас смущает то?
Неактивен
обнаружил периодичность пиковых скачков количества тредов, раз в 5 минут, график из забикса прикреплен. похоже это коннекты pop3 клиентов (и соответственно коннекты к mysql для авторизации).
paulus написал:
А что Вас смущает то?
то что с периодичностью 5 минут создается несколько десятков тредов, вместо того чтобы браться из кэша.
Неактивен
Ну так приходит нагрузка — появляются потоки. В чем проблема? Смотрите, какие
запросы они выполняют, пробуйте с ними что-то поделать.
Неактивен
paulus написал:
Ну так приходит нагрузка — появляются потоки. В чем проблема?
так а кэширование тредов для чего включается?
а проблема на мой взгляд в том, что кэшируется их почему-то недостаточно. хотя на другом сервере с более высокой и постоянной нагрузкой треды кэшируются в достаточном количестве.
Неактивен
Что такое «кэширование тредов»?
Неактивен
paulus написал:
Что такое «кэширование тредов»?
я думал это Вы тут отвечаете на вопросы ))
сомневаюсь что Вы не знаете назначение параметра thread_cache_size
попробую сформулировать вопрос четче.
есть mysql-server со средней нагрузкой ~90qps. на нем включено кэширование потоков, и оно работает нормально - потоки кэшируются и при необходимости берутся из кэша, новые практически не создаются, собственно значения
| Threads_cached | 60 |
| Threads_connected | 3 |
| Threads_created | 63 |
| Threads_running | 1 |
и есть сервер аналогичной версии со средней нагрузкой ~3.7qps. на нем так же включено кэширование потоков, но при этом там постоянно создаются новые потоки, вместо того чтобы браться из кэша, собственно значения
| Threads_cached | 15 |
| Threads_connected | 73 |
| Threads_created | 834 |
| Threads_running | 1 |
собственно проблема в созданни новых потоков вместо использования потоков из кэша.
можно конечно оптимизировать запросы, менять софт и пр. но есть конкретный инструмент который я пытаюсь использовать, вопрос в том почему он не работает так как ожидается?
Неактивен
Я просто пытаюсь понять, что Вы подразумеваете, когда произносите эти слова
ОК, давайте попробую объяснить. У Вас есть пул соединений. Каждое новое подклю-
чение в базе создает новый поток. Когда соединение завершается, этот поток можно
или удалить, или положить в потоковый кэш. Тогда при установлении нового соедине-
ния поток можно будет не создавать, а взять уже готовый, и начать его использовать.
Теперь давайте посмотрим, что происходит на Ваших серверах.
«Хороший» сервер:
Подключено потоков 3, закэшировано 60. Это значит, что если подключится еще пачка
(скажем, 40), то они все возьмутся из кэша.
«Плохой» сервер:
Подключено потоков 73, закэшировано 15. Это значит, что если та же пачка подклю-
чится, то 25 потоков прийдется досоздать. А потом выбросить, потому что, в кэше поло-
жено держать не более 15 (у Вас же такие настройки, да?)
То есть потоки создаются из-за того, что на серверах у Вас отличается количество
открытых уже соединений в 24 раза. Ну и плюс thread_cache_size разный
Неактивен
paulus написал:
не более 15 (у Вас же такие настройки, да?)
...
Ну и плюс thread_cache_size разный
в том-то и вопрос, что thread_cache_size одинаковый на обоих серверах и равен 70:
mysql> show variables like 'thread%';
+-------------------+---------------------------+
| Variable_name | Value |
+-------------------+---------------------------+
| thread_cache_size | 70 |
| thread_handling | one-thread-per-connection |
| thread_stack | 262144 |
+-------------------+---------------------------+
3 rows in set (0.00 sec)
mysql> show variables like 'thread%';
+-------------------+---------------------------+
| Variable_name | Value |
+-------------------+---------------------------+
| thread_cache_size | 70 |
| thread_handling | one-thread-per-connection |
| thread_stack | 262144 |
+-------------------+---------------------------+
3 rows in set (0.00 sec)
Неактивен
Ну, ок. Попробуйте набить пул потоками (сделайте 40 параллельных сессий и
отсоединитесь) — значение должно вырасти. Если не вырасло — или у Вас таки
стоит меньше кэш (например, поменяли конфиг, но не перезапустили демон),
или ошибка в ПО, тогда обновиться, и, если воспроизводится, — bugs.mysql.com.
Неактивен
да, количество закэшированых тердов растет, но в процессе работы и уменьшается. потоки из кэша удаляются по какому-то таймауту?
а может быть причина в пиковом характере нагрузки? если параметр thread_cache_size не позволяет закэшировать 117 потоков, то он вообще ни одного потока не берет из кэша, а все 117 создает?
Неактивен
Потоки приходят не одновременно, а последовательно, поэтому нельзя говорить, вообще
говоря, об одновременных 117 потоках. Поэтому кэш, естественно, используется.
Неактивен