Меню
Что нового?

MySQL запросы в состоянии Locked

  • Автор темы Автор темы xInOrK
  • Дата начала Дата начала
xInOrK

xInOrK

Новичок
MySQL запросы в состоянии Locked

OS: FreeBSD 7.2-RELEASE (amd64, i386, на обоих проверено, но вроде не важно)
MySQL: 5.1.22-rc

Всё работает замечательно все запросы проходят быстро в процессах не наблюдается вообще долго выполняющихся или в состоянии "Locked". Но если обновить MySQL до последней версии то происходит что-то странное, под большой нагрузкой начинаются копится в большом количестве запросы "UPDATE" в состоянии "Locked" и тем самым блокируют таблицу для чтения, сначала всё это происходит на 1-10 секунд но потом в итоге это доходит до состояния что они там начинают висеть по паре минут и сайт просто перестаёт работать.

MySQL устанавливаю из портов "ports". Возможности протестировать сайт на разных версихя MySQL особо не было, но уже с релизами MySQL годичной давности сайт нормально не пахал.

Я всё понимаю что наверное пора взятся за эти таблицы над которыми производятся очень частые UPDATE и разбить их чтобы UPDATE и SELECT друг другу не мешали но всётаки.
 
Мысль такая тоже мелькала но пока есть некоторые специфические вещи, да и база очень большая чтобы так резко и быстро перейти.
 
Мысль такая тоже мелькала
Нажмите для раскрытия...
ну если запросы не оптимизируются, то уход от блокировок можно так сделать. InnoDB блокирует на уровне строки. MyISAM на уровне таблицы.

думай сам...
 
Да мне впринципе проще остаться на той версии на которой всё работает и без этого, я просто думал что может кто в курсе чего такого радикального могли поменять что вот с новыми версиями 5.1.* случается такое.
 
ну сами конфиги дам если про my.cnf, насчёт системных переменных не знаю
 
ну сами конфиги дам
Нажмите для раскрытия...
так ты сам сравни параметры запуска разных версий? скока под что памяти отдается, что под ключи, что под кеш и т.д. там много настроек. они одинаковые?
 
я все версии пробовал с таким my.cnf

Код: 
[client]
port = 3306
socket = /tmp/mysql.sock

[mysqld]
port = 3306
socket = /tmp/mysql.sock
skip-locking
key_buffer_size = 384M
max_allowed_packet = 1M
table_open_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
thread_concurrency = 8

#skip-networking
#log-bin=mysql-bin
#server-id = 1
skip-innodb

[mysqldump]
quick
max_allowed_packet = 32M

[mysql]
no-auto-rehash
#safe-updates

[myisamchk]
key_buffer_size = 256M
sort_buffer_size = 256M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout
 
Но если обновить MySQL до последней версии
Нажмите для раскрытия...
а до какой собственно?

-~{}~ 23.12.09 20:39:

а может просто настроить конфиг исходя из состояния сервера, что б базе комфортно было?
=)
 
Ну в портах имеется mysql51-server (5.1.41)

сервера почти идентичные по крайней мере память процы
 
под большой нагрузкой
Нажмите для раскрытия...
судя под конфигу никакой нагрузки и нету?
=)
скока в секунду летит? размер базы? скока памяти на севрере? что там еще крутиться?

-~{}~ 23.12.09 20:44:

посмотрите
Код: 
tornado(root):/usr/ports/databases/mysql51-server#>lsl /usr/local/share/mysql/ | grep my-
-r--r--r--   1 root  wheel    4757 11 НЙР 06:23 my-huge.cnf
-r--r--r--   1 root  wheel   20160 11 НЙР 06:23 my-innodb-heavy-4G.cnf
-r--r--r--   1 root  wheel    4731 11 НЙР 06:23 my-large.cnf
-r--r--r--   1 root  wheel    4742 11 НЙР 06:23 my-medium.cnf
-r--r--r--   1 root  wheel    2380 11 НЙР 06:23 my-small.cnf

Код: 
 1047 mysql      18  44    0  1295M   210M ucond  0   0:14  0.00% mysqld


может пригодиться?
 
RAM: 4-8 GB
CPU: 2x DC Xeon (Opteron)

база весит 550 MB
запросов по разному от 200-600 в секунду очень по разному, SELECT 50-60%, INSERT 1%, UPDATE 5%

-~{}~ 23.12.09 19:45:

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

могли тупо индексы слететь? и дазу-то апгрейдили прежде чем с версии на версию перепрыгивать?

что говорит myisamchk рпо базу? там все чисто?
 
slow_query ну там много запросов но там только тяжёлые которые выполняются по крону.

а как видно из процессов то убивают обычные UPDATE над одной таблицей где постоянно делается SELECT.

----

индексы впорядке
раз в пару часов делается OPTIMIZE TABLE таблицам

таблице все в рабочем состоянии тоесть REPAIR им не нужен
 
Ну ладно раз нету мыслей то буду потихоньку смотреть Changelog MySQL -а на предмет интересных изменений.

А серваки не могу дать посмотреть сорри.
 
Войдите или зарегистрируйтесь для ответа.
Сверху