Уровень изоляции транзакций

[regii]

Уровень изоляции транзакций

Есть mysql+apache+nginx. Информационный сайт, все выборки в основном select.
Для статей на сайте ведется подсчет просмотров запросом вида "update table set views=views+1 where id=123;"
Периодически(если много людей начинает заходить на адрес одной статьи) mysql хватает deadlock, затем еще один и еще и весь пул тредов mysql забивается(смотрю через innotop), соответственно вылетает 502 ошибка.
Все таблицы innodb, используется pconnect, уровень изоляции repeatable read.

Пока мысль только одна - снизить уровень изоляции до read commited. Чем это может грозить в данном случае? Потерей нескольких апдейтов(просмотров статьи в статистике)? Может, есть какие-то варианты? Не знаю, куда копать.

 

[whirlwind]

А апдейт и селект на колво показов в одной транзакции выполняются?

 

[regii]

Идет только запись в бд, выборки не происходит. Т.е. выборка происходит тогда, когда админ смотрит через спец интерфейс, что бывает редко.

 

[KR]

вариант использовать дозапись данных в файл (a+) + обработка по крону файлов с данными и сваливание в базу

 

[dimagolov]

regii, а по полю views есть индекс? есть подозрение, что проблема не в обновлении как таковом, а в перестройке индекса, которое оно вызывает.

 

[dr-sm]

отцепи views в отдельную таблицу и делай в нее insert on dupicate key update.
но если по уму, лучше парсить логи вебсервера.

-~{}~ 28.02.10 03:29:

также не забываем про show engine innodb status

 

[pilot911]

а можно узнать цифру апдейтов в сек, при которой наблюдается такое событие ?

 

[regii]

dimagolov: по полю views индекс есть. Но так же есть другая ситуация, когда дедлок происходит в таблице, в которой 7 записей и нет индексов. Запросы на селект к ней идут раз в час(как кеш очищается), все остальное время идут запросы вида UPDATE table SET cnt=cnt+1 WHERE id IN(10, 43, 12); Может быть, стоит разбить этот запрос на 3?

pilot911: подавляющее большинство запросов к базе идет на selet. update - всего процентов 5. Вся система стабильно работала при нагрузке в 1к запросов в секунду(буквально пару недель назад), дедлоков не было, функционал был тот же, настройки те же. Сейчас в среднем - около 250-300 запросов в секунду(в основном селекты).

Интересно еще то, что дедлоки стали появляться практически повсеместно, и на маленьких таблицах без индексов, где всего 7 записей, и на таблицах, где около 70к записей.

 

[dr-sm]

ты в каком-то из долгоживущих соединений забыл сказать commit после селекта.

-~{}~ 01.03.10 15:40:

иннодб статус покажи

 

[dimagolov]

Все таблицы innodb, используется pconnect, уровень изоляции repeatable read.

сам не сталкивался, но народ жаловался на проблемы с pconnect. убери pconnect для начала.

 

[fixxxer]

c pconnect проблема, если я все верно понимаю, весьма банальная - один клиент отвалился посреди чтения результата, второй реюзнул соединение и схватил его остатки. возможно, точно так же может быть и "остаток" транзакции подхвачен, хотя по идее такое контролируется, но кто его знает - раз первое иногда некорреткно обрабатывается, то и второе может.