BiTel

Добрый день Коллеги !
У нас BGradius перестает обрабатывать запросы в то время, когда мы открываем mysql клиентом таблицу bgbilling.log_server_6_201111.

В логах идут ошибки: WARN [RadiusListener] RadiusListener - RadiusListener authentication queue full...
Bgbilling шлет письма: "В рамках отведенного переменными количества потоков auth.thread.count и размером очереди обработки auth.thread.queue RADIUS сервер не успеевает производить обработку авторизационных запросов.Возможная причина - загруженность базы данных."
Проблема похожа на заявленную в теме: viewtopic.php?f=5&t=6048&hilit=auth%2A

Проявление проблемы не зависит от нагрузки на сервер.
Есть четкий фактор, который приводит к проблеме и убирает проблему.

Глючное состояние проявляется при:
подключении к mysql клиентом dbForgeStudio с правами пользователя, который может выполнять только SELECT запросы и
наличии активной сессии в течении которой скачивается большое кол-во записей из таблицы log_server_6_201111

SQL запрос вызывающий ступор у BGRadius-а: select * from bgbilling.log_server_6_201111

Клиент dbForgeStudio, получая от mysql сервера данные из таблицы регулирует скорость поступления данных средствами протокола TCP. В частности, после приема определенной порции данных он анонсирует нулевой размер окна приема данных. Передача данных таблицы от mysql приостанавливается.
Пока mysql сервер не вернет все записи в таблице приложению dbForgeStudio работа Radius сервера блокируется по непонятным для нас причинам.
В то же самое время любой конкурирующий sql клиент может делать с таблицей все что угодно (insert,update,delete....). Никаких table lock с нашей стороны на таблицу мы не применяем.

Т.о. нам не понятно, как поступать, елси есть необходимость скачать таблицу log_server_6_201111 по медленному каналу при этом не заблокировав Radius сервер. Нам не понятно почему он вообще блокируется ?


p.s. При нахождении в глючном состоянии Радиус сервер тем не менее принимая AUTH запрос, выполнят скрипт предобработки и помещает данные в таблицу og_server_6_201111 но при этом не возвращает AUTH-ACCEPT до тех пор пока dbForgeStudiuo не докачает таблицу или не отцепится от базы данных.

Может быть проблема в dbForgeStudiuo? Попробуйте другим клиентом смотреть .

Попробуйте другим клиентом (SQLyog например), или же в запросе писать LIMITы

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Корень проблемы не в dbForgeStudiuo.
Проблема воспроизводится и при не больших значениях Limit. Например "LIMIT 100".
Если эти 100 записей качать по медленному каналу 2 кб/сек ( в т.ч. другим клиентом), то проблема присутствует все время скачивания !
При тех же самых условиях если открыть, к примеру таблицу log_session_6_XXXXX то никаких конфликтов не возникает.....

Что в my.cnf?

#cat my.cnf
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
socket = /var/run/mysqld/mysqld.sock
port = 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp
language = /usr/share/mysql/english
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
myisam-recover = BACKUP
max_connections = 800
#table_cache = 64
thread_concurrency = 20
query_cache_limit = 1M
query_cache_size = 16M
log = /var/log/mysql/mysql.log
# Error logging goes to syslog. This is a Debian improvement
# Here you can see queries with especially long duration
#log_slow_queries = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#server-id = 1
#log_bin = /var/log/mysql/mysql-bin.log
expire_logs_days = 10
max_binlog_size = 100M
skip-bdb
[mysqldump]
quick
quote-names
max_allowed_packet = 16M
[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
[isamchk]
key_buffer = 16M
!includedir /etc/mysql/conf.d/