[Dimka88]

Столкнулся с ситуацией производительности freeradius2 rlm_perl. Операционная система Gentoo. Биллинг Abills. В после аварии начинается многократная авторизация пользователей. После чего радиус начинает в лог кричать

Error: Discarding duplicate request from client pptp2 port 35157 - ID: 205 due to unfinished request 7086426

Перл собран с поддержкой потоков, что бы request выполнялись параллельно.

billing ~ # perl -V | grep USE_I
                       USE_64_BIT_INTUSE_ITHREADS USE_LARGE_FILES

 

~ # cat /etc/raddb/radiusd.conf

prefix = /usr
exec_prefix = ${prefix}
sysconfdir = /etc
localstatedir = /var/lib
sbindir = ${exec_prefix}/sbin
logdir = /var/log/radius
raddbdir = ${sysconfdir}/raddb
radacctdir = ${logdir}/radacct
name = radiusd
confdir = ${raddbdir}
run_dir =/var/run/radiusd
db_dir = ${raddbdir}
libdir = /usr/lib64/freeradius
pidfile = ${run_dir}/${name}.pid
user = radiusd
group = radiusd
max_request_time = 30
cleanup_delay = 5
max_requests = 3840000
#debug_level = 1

listen {
  type = auth
  ipaddr = *
  port = 0
}

listen {
  ipaddr = *
  port = 0
  type = acct
}

hostname_lookups = no
allow_core_dumps = no
regular_expressions   = yes
extended_expressions   = yes
log {
  destination = files
  file = ${logdir}/radius.log
  syslog_facility = daemon
  stripped_names = no
  auth = no
  auth_badpass = no
  auth_goodpass = no
}

checkrad = ${sbindir}/checkrad

security {
  max_attributes = 200
  reject_delay = 1
  status_server = yes
}

proxy_requests  = no
$INCLUDE clients.conf

thread pool {
  start_servers = 32
  max_servers = 32
  min_spare_servers = 3
  max_spare_servers = 10
  max_requests_per_server = 0
}

modules {
  $INCLUDE ${confdir}/modules/
}

instantiate {
  exec
  expiration
  logintime
}

$INCLUDE policy.conf
$INCLUDE sites-enabled/default

 

~ # cat /etc/raddb/modules/perl

perl {
module = /usr/abills/libexec/rlm_perl.pl
func_authorize = authorize
func_accounting = accounting
func_authenticate = authenticate
func_preacct = preacct
func_checksimul = checksimul
func_xlat = xlat
max_clones = 32
start_clones = 32
min_spare_clones = 0
max_spare_clones = 32
cleanup_delay = 5
max_request_per_clone = 0
}

Вопрос: Как сделать радиус производительнее? И как диагностировать данную проблему?

Edited May 21, 2013 by Dimka88

[[anp/hsw]]

Не уверен, что это проблема производительности radius-сервера, по-моему дело в клиенте.

У нас freeradius2 + UTM5, такие строчки в логе тоннами валятся.

Каждый SQL-запрос руками писал, и потом делал бенчмарк на копии боевой базы.

Могу с уверенностью сказать, что дело не в производительности radius-SQL и не в radius-perl (отключение perl-логики вообще никак не влияет на эти сообщения).

 

Исходя из сообщения ошибки предположил, что в radiusclient'е слижком маленький таймаут, и он посылает повторный request, но radius-сервер отвечает менее чем за 100мс, и в клиенте я таких таймаутов не нашел.

tcpdump вам подтвердит, что это именно два запроса от клиента с одинаковым ID, и никак не проблема сервера.

[Dimka88]

' timestamp='1369119765' post=840403]

tcpdump вам подтвердит, что это именно два запроса от клиента с одинаковым ID, и никак не проблема сервера.

Спасибо за пинок, стоит проработать данную мысль. Доп информация. В качестве NAS используется accel-pptp 0.8.5 патчи pppd на гигаворд и COA.

[Dimka88]

[anp/hsw] как вы и писали tcpdump(ом) увидел следующее

10:48:27.168728 IP 10.1.1.1.44973 > 10.0.0.1.radius-acct: RADIUS, Accounting Request (4), id: 0xb3 length: 161
10:48:27.169616 IP 10.1.1.1.44973 > 10.0.0.1.radius-acct: RADIUS, Accounting Request (4), id: 0xb3 length: 161
10:48:27.173274 IP 10.0.0.1.radius-acct > 10.1.1.1.44973: RADIUS, Accounting Response (5), id: 0xb3 length: 20

 

То есть бороться необходимо с NAS?

 

В radiusclient-ng/radiusclient.conf есть такие строки

radius_timeout  10         #Время ожидания ответа от RADIUS сервера
radius_retries  3          #Повторит запрос 3 раза  прежде чем начать подключение к следующему RADIUS серверу

 

Интересно radius_timeout 10(Это секунды?)

если секунды то почему так

10:48:27.168728 IP 10.1.1.1.44973 > 10.0.0.1.radius-acct: RADIUS, Accounting Request (4), id: 0xb3 length: 161
10:48:27.169616 IP 10.1.1.1.44973 > 10.0.0.1.radius-acct: RADIUS, Accounting Request (4), id: 0xb3 length: 161

Edited May 21, 2013 by Dimka88

[[anp/hsw]]

Да, таймауты все в секундах. Видимо повторный пакет не является следствием превышения таймаута, и регулируется какой-то другой настройкой.

accel-pptp тут непричем, rp-pppoe также флудит. Тут дело, думаю, в libradiusclient или libradiusclient-ng (я пробовал оба, но результат одинаков).

[Abram]

У меня похожим образом mpd5 флудит. Гуглил - проблема в libradiusclient, даже патч какой-то проскакивал. В конце концов забил. :)

[Dimka88]

Если все с этим живут, тогда интересный вопрос, почему Abills считает, что ему не пришли аккаунтинг пакеты оn некоторых сессий? и он берёт их и просто ZAP. А потом выдаёт IP которые на NAS висят а в биллинге их уже нет. Есть ли способ ограничить количество авторизаций за секунду на стороне freeradius2, так как accel-pptp старые(с новыми не вышло получить такую производительность) со стороны NAS не получится? Дописывать файл авторизации Abills с счётчиками и посылать REJECT если лимит авторизаций превысил?

Edited May 21, 2013 by Dimka88

[~AsmodeuS~]

Если все с этим живут, тогда интересный вопрос, почему Abills считает, что ему не пришли аккаунтинг пакеты оn некоторых сессий? и он берёт их и просто ZAP. А потом выдаёт IP которые на NAS висят а в биллинге их уже нет. Есть ли способ ограничить количество авторизаций за секунду на стороне freeradius2, так как accel-pptp старые(с новыми не вышло получить такую производительность) со стороны NAS не получится? Дописывать файл авторизации Abills с счётчиками и посылать REJECT если лимит авторизаций превысил?

Абилс работает только с теми пакетами чсто пришли

 

елси какотой пакет не пришёл попробуйте его найти в детализации акаунтинга очень сомниваюсь что он там будет

 

скорее всего проблема в чёмто другом стоит смореть еще sql_errors

[Dimka88]

скорее всего проблема в чёмто другом стоит смореть еще sql_errors

Не исключаю, что проблема может быть в mysql но в sql_errors пару ошибок, и то с web интерфейса.

Детализацию акаунтинга отключил, слишком много ресурсов потребляет. Специально аварию правоцировать не буду.В дальнейшем возьмусь детальнее изучать slow_query и соответствие radius пакетов.

 

В mysql наблюдаю следующее.

Смущает количество неудачных попыток и перерванных запросов.

 

 

Вот что говорят некоторые переменные

Aborted clients = 651 #Количество прерванных соединений в связи с потерей связи и неверно закрытым соединением клиента.

Aborted connects = 82 #Количество неудавшихся попыток соединения к серверу MySQL.

Created tmp disk tables = 29.6 k #Количество временных таблиц, автоматически созданных сервером на диске, во время выполнения SQL-выражений.

#tmp_table_size увеличу при следующих плановых работах до 400k

Created tmp tables = 278.8 k #Количество временных таблиц в памяти, созданных сервером автоматически в процессе выполнения SQL-выражений.

Handler read rnd = 6.4 M #Количество запросов, на чтение строки, основанных на ее позиции. Большое значение переменной может быть обусловлено

#частым выполнением запросов использующих сортировку результата, выполнением большого числа запросов требующих полного

#сканирования таблиц, наличием объединений не использующих индексы надлежащим образом.

Handler read rnd next = 32.3 G #Количество запросов на чтение следующей строки из файла данных. Данное значение будет высоким, при частом

#сканировании таблиц. Обычно это означает, что таблицы не проиндексированы надлежащим образом или запросы не

#используют преимущества индексов.

Innodb buffer pool reads = 3.7 k #Количество последовательных запросов на чтение, которые InnoDB не смог выполнить из буферного пула и использовал

#постраничное чтение.

Opened tables = 10.3 k #Общее количество открывавшихся таблиц. При большом значении переменной рекомендуется увеличить размер кеша таблиц

Slow queries = 131 #Количество запросов, выполнявшихся более long_query_time секунд.

Sort merge passes = 419 #Количество проходов, сделанных алгоритмом сортировки.

Table locks waited = 135.4 k #Количество запросов на блокировку таблицы, которые были удовлетворены только после определенного периода ожидания.

#Если значение велико и есть проблемы с производительностью, необходимо сначала оптимизировать свои запросы, а затем

#разбить свою таблицу (или таблицы) или использовать репликацию.

Необходимость оптимизировать БД присутствует это очевидно.

 

Покажет кто конфиг оптимизированной mysql с таблицами MyISAM для биллинговых систем?

[pppoetest]

Тут с индексами надо воевать, которых вообще нет, имхо.

Edited May 22, 2013 by pppoetest

[~AsmodeuS~]

Тут с индексами надо воевать, которых вообще нет, имхо.

ну ну пожалуста по подробней где нету индексов ?

[NiTr0]

если секунды то почему так

С сетью все в порядке? Мож свичик какой вызывает раздвоение пакетов? На брасе дамп снимали?

[~AsmodeuS~]

скорее всего проблема в чёмто другом стоит смореть еще sql_errors

Не исключаю, что проблема может быть в mysql но в sql_errors пару ошибок, и то с web интерфейса.

Детализацию акаунтинга отключил, слишком много ресурсов потребляет. Специально аварию правоцировать не буду.В дальнейшем возьмусь детальнее изучать slow_query и соответствие radius пакетов.

 

В mysql наблюдаю следующее.

Смущает количество неудачных попыток и перерванных запросов.

 

 

Вот что говорят некоторые переменные

Aborted clients = 651 #Количество прерванных соединений в связи с потерей связи и неверно закрытым соединением клиента.

Aborted connects = 82 #Количество неудавшихся попыток соединения к серверу MySQL.

Created tmp disk tables = 29.6 k #Количество временных таблиц, автоматически созданных сервером на диске, во время выполнения SQL-выражений.

#tmp_table_size увеличу при следующих плановых работах до 400k

Created tmp tables = 278.8 k #Количество временных таблиц в памяти, созданных сервером автоматически в процессе выполнения SQL-выражений.

Handler read rnd = 6.4 M #Количество запросов, на чтение строки, основанных на ее позиции. Большое значение переменной может быть обусловлено

#частым выполнением запросов использующих сортировку результата, выполнением большого числа запросов требующих полного

#сканирования таблиц, наличием объединений не использующих индексы надлежащим образом.

Handler read rnd next = 32.3 G #Количество запросов на чтение следующей строки из файла данных. Данное значение будет высоким, при частом

#сканировании таблиц. Обычно это означает, что таблицы не проиндексированы надлежащим образом или запросы не

#используют преимущества индексов.

Innodb buffer pool reads = 3.7 k #Количество последовательных запросов на чтение, которые InnoDB не смог выполнить из буферного пула и использовал

#постраничное чтение.

Opened tables = 10.3 k #Общее количество открывавшихся таблиц. При большом значении переменной рекомендуется увеличить размер кеша таблиц

Slow queries = 131 #Количество запросов, выполнявшихся более long_query_time секунд.

Sort merge passes = 419 #Количество проходов, сделанных алгоритмом сортировки.

Table locks waited = 135.4 k #Количество запросов на блокировку таблицы, которые были удовлетворены только после определенного периода ожидания.

#Если значение велико и есть проблемы с производительностью, необходимо сначала оптимизировать свои запросы, а затем

#разбить свою таблицу (или таблицы) или использовать репликацию.

Необходимость оптимизировать БД присутствует это очевидно.

 

Покажет кто конфиг оптимизированной mysql с таблицами MyISAM для биллинговых систем?

 

 

уже больше 2 лет мы рекомендуем использовать исключительно innodb так ккак в системе используются транзации и другие возможности реляционых баз данных которых нет в myisam

[Dimka88]

С сетью все в порядке? Мож свичик какой вызывает раздвоение пакетов? На брасе дамп снимали?

Дамп снимал, с сетью все в порядке.

 

уже больше 2 лет мы рекомендуем использовать исключительно innodb так ккак в системе используются транзации и другие возможности реляционых баз данных которых нет в myisam

 

Очень полезная информация, куда мои глаза глядели когда сервер готовил.

 

Ваш пост на форуме Abills(Пт апр 01, 2011 9:28 pm)

следующая версия которая війдет скорее всего будет использовать по умолчанию не MyISAM єто произойдёт в ближайшие месяцы

Рекомендую в вашем dokuwiki написать про это, лишним не будет.

 

Тут с индексами надо воевать, которых вообще нет, имхо.

 

Возможно Abills не причём к таким индексам, скорее всего мои специфические статистики (Очень нужные, выполняются не более 5 раз в месяц).

Edited May 22, 2013 by Dimka88

[NiTr0]

Дамп снимал, с сетью все в порядке.

 

Т.е. уже на ифейсе браса двоение?

Если так - смотрите, не подгружается ли радиус-модуль дважды.

[Dimka88]

Т.е. уже на ифейсе браса двоение?

Радиус клиент отправляет пакет на сервер, радиус сервер не успевает ответить, тогда радиус клиент шлёт пакет повторно через 0.1 секунды.

Если так - смотрите, не подгружается ли радиус-модуль дважды.

Модуль подгружен один раз.

[Davion]

скорее всего проблема в чёмто другом стоит смореть еще sql_errors

Не исключаю, что проблема может быть в mysql но в sql_errors пару ошибок, и то с web интерфейса.

Детализацию акаунтинга отключил, слишком много ресурсов потребляет. Специально аварию правоцировать не буду.В дальнейшем возьмусь детальнее изучать slow_query и соответствие radius пакетов.

 

В mysql наблюдаю следующее.

Смущает количество неудачных попыток и перерванных запросов.

 

 

Вот что говорят некоторые переменные

Aborted clients = 651 #Количество прерванных соединений в связи с потерей связи и неверно закрытым соединением клиента.

Aborted connects = 82 #Количество неудавшихся попыток соединения к серверу MySQL.

Created tmp disk tables = 29.6 k #Количество временных таблиц, автоматически созданных сервером на диске, во время выполнения SQL-выражений.

#tmp_table_size увеличу при следующих плановых работах до 400k

Created tmp tables = 278.8 k #Количество временных таблиц в памяти, созданных сервером автоматически в процессе выполнения SQL-выражений.

Handler read rnd = 6.4 M #Количество запросов, на чтение строки, основанных на ее позиции. Большое значение переменной может быть обусловлено

#частым выполнением запросов использующих сортировку результата, выполнением большого числа запросов требующих полного

#сканирования таблиц, наличием объединений не использующих индексы надлежащим образом.

Handler read rnd next = 32.3 G #Количество запросов на чтение следующей строки из файла данных. Данное значение будет высоким, при частом

#сканировании таблиц. Обычно это означает, что таблицы не проиндексированы надлежащим образом или запросы не

#используют преимущества индексов.

Innodb buffer pool reads = 3.7 k #Количество последовательных запросов на чтение, которые InnoDB не смог выполнить из буферного пула и использовал

#постраничное чтение.

Opened tables = 10.3 k #Общее количество открывавшихся таблиц. При большом значении переменной рекомендуется увеличить размер кеша таблиц

Slow queries = 131 #Количество запросов, выполнявшихся более long_query_time секунд.

Sort merge passes = 419 #Количество проходов, сделанных алгоритмом сортировки.

Table locks waited = 135.4 k #Количество запросов на блокировку таблицы, которые были удовлетворены только после определенного периода ожидания.

#Если значение велико и есть проблемы с производительностью, необходимо сначала оптимизировать свои запросы, а затем

#разбить свою таблицу (или таблицы) или использовать репликацию.

Необходимость оптимизировать БД присутствует это очевидно.

 

Покажет кто конфиг оптимизированной mysql с таблицами MyISAM для биллинговых систем?

 

Не подскажете что за веб интерфейс используете для отчетов по MySQL?

[Dimka88]

Не подскажете что за веб интерфейс используете для отчетов по MySQL?

phpmyadmin версии 3.5.3 на главной странице в горизонтальном меню кнопка Состояние.

[NiTr0]

Радиус клиент отправляет пакет на сервер, радиус сервер не успевает ответить, тогда радиус клиент шлёт пакет повторно через 0.1 секунды.

 

Не через 0.1 сек. А чарез 0.001 сек. Т.е. - практически сразу же:

10:48:27.168728 IP 10.1.1.1.44973 > 10.0.0.1.radius-acct: RADIUS, Accounting Request (4), id: 0xb3 length: 161
10:48:27.169616 IP 10.1.1.1.44973 > 10.0.0.1.radius-acct: RADIUS, Accounting Request (4), id: 0xb3 length: 161

[~AsmodeuS~]

Не подскажете что за веб интерфейс используете для отчетов по MySQL?

phpmyadmin версии 3.5.3 на главной странице в горизонтальном меню кнопка Состояние.

уже добавлено недостающие отчёты в ABillS SQL commander

[Dimka88]

Решил переехать с MyISAM на InnoDB. Будут ли подводные камни, кто сталкивался? Если не сложно поделитесь my.cnf под Abills для InnoDB.

 

UPD// нашёл в abills/misc/mysql/my.cnf

[client]
port		= 3306
#socket		= /tmp/mysql.sock

# The MySQL server
[mysqld]
port		= 3306
#socket		= /tmp/mysql.sock
skip-external-locking
query_cache_size=128M
query-cache-type=1
join_buffer_size=256K
key_buffer=640M
query_cache_limit=2M
max_allowed_packet=1M
#table_cache=512
sort_buffer=12M
read_buffer_size=12M
net_buffer_length=16K
myisam_sort_buffer_size=64M
thread_cache_size=4
server-id       = 1
max_connections = 1500
slave-compressed = 1
#log-bin=abills-bin.log
#log-bin
long_query_time = 5
slow_query_log
slow_query_log_file = mysqld-slow-query.log
#log=mysql_query.log
#------------------
#_REPLICATION_
#------------------

# innodb
default-storage-engine = innodb
innodb_file_per_table
innodb_additional_mem_pool_size = 16M
#x8
#innodb_buffer_pool_size = 2G # or 9G on x64
innodb_thread_concurrency = 4
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 8M
innodb_log_file_size = 128M
innodb_log_files_in_group = 2
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120
#
innodb_flush_method = O_DIRECT
##

[mysqldump]
quick
max_allowed_packet=32M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer=40M
sort_buffer=40M
read_buffer=10M
write_buffer=10M

[myisamchk]
key_buffer=40M
sort_buffer=40M
read_buffer=10M
write_buffer=10M

[mysqlhotcopy]
interactive-timeout

Edited June 10, 2013 by Dimka88

[NiTr0]

Посмотрите этот гайд. Доступно описано, откуда у параметров ноги растут. Хоть и не под абиллс, но принцип тот же, да и нагрузка от заббикса, кхм, "несколько" побольше буде, эдак на 1-2 порядка (sata raid1 на 7200рпм упрется в потолок по iops где-то при объеме записей порядка 3 ГБ/сутки).

[~AsmodeuS~]

вновом движке sql более интелектуальный конструктор уменьшает нагрузку на базу

[Dimka88]

вновом движке sql более интелектуальный конструктор уменьшает нагрузку на базу

Пока не планирую на новый движок бежать.

Переделал базу c MyISAM на InnoDB. Выполнял следующие процедуры:

# Сохраняем базу данных в файл
mysqldump abills > abills.sql -p

# Меняем ENGINE
sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' abills.sql > abills.innodb.sql

# Удаляем базу
mysqladmin -p drop abills

# Создаём базу
mysqladmin -p create abills

# Заливаем изменённый дамп базы
mysql -p abills < abills.innodb.sql

 

Далее изменил my.cnf, привёл к следующему виду.

[client]
port				= 3306
socket				= /var/run/mysqld/mysqld.sock

[mysqld_safe]
err-log				= /var/log/mysql/mysql.err

[mysqld]
character-set-server		= utf8
user				= mysql
port				= 3306
socket				= /var/run/mysqld/mysqld.sock
pid-file			= /var/run/mysqld/mysqld.pid
log-error			= /var/log/mysql/mysqld.err
basedir				= /usr
datadir				= /database/mysql/
skip-external-locking
query_cache_size		= 512M
query-cache-type		= 1
join_buffer_size		= 256K
key_buffer			= 640M
query_cache_limit		= 256M
max_allowed_packet		= 1M
sort_buffer			= 12M
read_buffer_size		= 12M
net_buffer_length		= 16K
myisam_sort_buffer_size		= 64M
thread_cache_size		= 4
server-id			= 1
max_connections			= 1500
slave-compressed		= 1
long_query_time			= 2
slow_query_log
slow_query_log_file		= mysqld-slow-query.log
tmp_table_size			= 256M
max_heap_table_size		= 256M
table_cache			= 512

# innodb
default-storage-engine		= innodb
innodb_file_per_table
innodb_additional_mem_pool_size = 16M
innodb_buffer_pool_size		= 12G
innodb_thread_concurrency	= 48
innodb_flush_log_at_trx_commit	= 2
innodb_log_buffer_size		= 8M
innodb_log_file_size		= 128M
innodb_log_files_in_group	= 2
innodb_max_dirty_pages_pct	= 90
innodb_lock_wait_timeout	= 120
innodb_flush_method		= O_DIRECT
innodb_data_home_dir = /database/mysql/
innodb_log_group_home_dir = /database/mysql/
innodb_data_file_path = ibdata1:100M:autoextend

[mysqldump]
quick
max_allowed_packet		= 32M
character-sets-dir		= /usr/share/mysql/charsets
default-character-set		= utf8

[mysql]
no-auto-rehash
character-sets-dir		= /usr/share/mysql/charsets
default-character-set		= utf8

[isamchk]
key_buffer			= 40M
sort_buffer			= 40M
read_buffer			= 10M
write_buffer			= 10M

[myisamchk]
key_buffer			= 40M
sort_buffer			= 40M
read_buffer			= 10M
write_buffer			= 10M

[mysqlhotcopy]
interactive-timeout

 

Железяка X2 Xeon, 48Gb ram, 4 SAS, задействованы под X2 RAID 1 под систему и X2 RAID 1 под базу.

 

При старте радиуса, mysql сервер прыгнул в полку на 10 секунд, но после выровнялся.

load averages: 0.01, 0.02, 0.05

 

Есть конечно еще нюансы над которыми необходимо работать.

 

Версия mysqld 5.1.66 (Запланировал через пару недель на 5.6.10, если не добьюсь производительности)

 

Aborted clients 3 Количество прерванных соединений в связи с потерей связи и неверно закрытым соединением клиента.

Aborted connects 1 Количество неудавшихся попыток соединения к серверу MySQL.

Created tmp disk tables 39 Количество временных таблиц, автоматически созданных сервером на диске, во время выполнения SQL-выражений. Если значение Created_tmp_disk_tables велико, следует увеличить значение переменной tmp_table_size, чтобы временные таблицы располагались в памяти, а не на жестком диске.

Handler read rnd 5.1 k Количество запросов, на чтение строки, основанных на ее позиции. Большое значение переменной может быть обусловлено частым выполнением запросов использующих сортировку результата, выполнением большого числа запросов требующих полного сканирования таблиц, наличием объединений не использующих индексы надлежащим образом.

Handler read rnd next 121.2 M Количество запросов на чтение следующей строки из файла данных. Данное значение будет высоким, при частом сканировании таблиц. Обычно это означает, что таблицы не проиндексированы надлежащим образом или запросы не используют преимущества индексов.

Innodb buffer pool pages dirty 43 Текущее количество "грязных" страниц.

Innodb buffer pool reads 17.3 k Количество последовательных запросов на чтение, которые InnoDB не смог выполнить из буферного пула и использовал постраничное чтение.

Opened tables 529 Общее количество открывавшихся таблиц. При большом значении переменной рекомендуется увеличить размер кеша таблиц (table_cache).

Slow queries 86 Количество запросов, выполнявшихся более long_query_time секунд.

Просмотрел журнал, записи следующего виде

SET timestamp=1371000864;
SELECT DECODE(password, 'secret') FROM users WHERE id='anylogin1';
# User@Host: abills[abills] @ localhost []
# Query_time: 2.526582  Lock_time: 0.000351 Rows_sent: 1  Rows_examined: ***
SET timestamp=1371000864;
SELECT DECODE(password, 'secret') FROM users WHERE id='anylogin2';
# User@Host: abills[abills] @ localhost []
# Query_time: 2.332391  Lock_time: 0.000207 Rows_sent: 1  Rows_examined: ***

Проверил выполнение DECODE, в 0.0003 вкладывается без кеш.

В пик при включении запросы сыпались, сейчас ничего не пишет.

 

Table locks waited 11.4 k Количество запросов на блокировку таблицы, которые были удовлетворены только после определенного периода ожидания. Если значение велико и есть проблемы с производительностью, необходимо сначала оптимизировать свои запросы, а затем разбить свою таблицу (или таблицы) или использовать репликацию.

 

C недавних пор занялся детально изучать mysql. Если видите, что то очевидное для оптимизации, буду рад совету.

[NiTr0]

А ничего, что innodb_file_per_table - бессмысленна сама по себе, ибо, исходя из мануала, должно быть innodb_file_per_table=1 ?

Ну и да, мануал от заббикса я привел. По сравнению с дефолтными значениями - у меня iops упал с 200 до 40. Как по мне - результат налицо.