Jump to content
Калькуляторы

Davion

Активный участник
  • Content Count

    664
  • Joined

  • Last visited

1 Follower

About Davion

  • Rank
    Аспирант

Информация

  • Пол
    Не определился

Recent Profile Visitors

3522 profile views
  1. Коллеги подскажите ктонибудь использует параметр radius-server throttle accounting Из доки немогу понять как он ограничивает пакеты к радиусу.
  2. Требуется обязательно Лизы, чтобы айпи адреса высвобождать... И сохранять айпи за абонентом в течение срока действия Лизы...
  3. Не уверен это чуть модернизированный штатный запрос радиуса, нашим билингистом, а я разгребаю )
  4. Да уже куча опытов было)) сейчас с индексом на айдрес, пул и время и узернейм. Выхлопа не много, если лиза истекал все пропало. У всех адресов лиза не истекла. EXPLAIN SELECT framedipaddress FROM radippool WHERE pool_name = 'test' AND ( (username = 'test') OR (expiry_time < NOW() OR expiry_time IS NULL) ) ORDER BY (username <> 'test'), expiry_time LIMIT 1 FOR UPDATE; +----+-------------+-----------+------------+-------------+-------------------------------+----------------------+---------+------+------+----------+---------------------------------------------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------+------------+-------------+-------------------------------+----------------------+---------+------+------+----------+---------------------------------------------------------------------+ | 1 | SIMPLE | radippool | NULL | index_merge | poolname,username,expiry_time | username,expiry_time | 194,6 | NULL | 2 | 50.00 | Using sort_union(username,expiry_time); Using where; Using filesort | +----+-------------+-----------+------------+-------------+-------------------------------+----------------------+---------+------+------+----------+---------------------------------------------------------------------+ 1 row in set, 1 warning (0,00 sec) У всех адресов лиза истекла.(все в ж....) mysql> EXPLAIN SELECT framedipaddress FROM radippool WHERE pool_name = test' AND ( (username = 'test) OR (expiry_time < NOW() OR expiry_time IS NULL) ) ORDER BY (username <> 'test'), expiry_time LIMIT 1 FOR UPDATE; +----+-------------+-----------+------------+------+-------------------------------+----------+---------+-------+-------+----------+-----------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------+------------+------+-------------------------------+----------+---------+-------+-------+----------+-----------------------------+ | 1 | SIMPLE | radippool | NULL | ref | poolname,username,expiry_time | poolname | 92 | const | 28898 | 46.00 | Using where; Using filesort | +----+-------------+-----------+------------+------+-------------------------------+----------+---------+-------+-------+----------+-----------------------------+ 1 row in set, 1 warning (0,00 sec) Индексы не составные
  5. проблема видимо в INDEX datetime
  6. Total sent : 1936 Total retransmits : 2 Total succeeded : 1936 Total failed : 0 Total no reply : 0 Total time (s) : 5.015 Packets/s : 386 Response times: < 10 usec : 0 < 100 usec : 0 < msec : 0 < 10 msec : 0 < 0.1s : 1810 < s : 124 < 10s : 2 < 100s : 0 Если expiry_time еще не истек, тогда все хорошо) Без SKIP LOCKED тоже все ок... Если expiretime истек, то все ступор.
  7. Удалось разогнать Total sent : 1936 Total retransmits : 7 Total succeeded : 1936 Total failed : 0 Total no reply : 0 Total time (s) : 73.341 Packets/s : 26 Response times: < 10 usec : 0 < 100 usec : 0 < msec : 0 < 10 msec : 0 < 0.1s : 0 < s : 32 < 10s : 1904 < 100s : 0 Но до Postgresql не дотягивает: Total sent : 1936 Total retransmits : 0 Total succeeded : 1936 Total failed : 0 Total no reply : 0 Total time (s) : 20.880 Packets/s : 93 Response times: < 10 usec : 0 < 100 usec : 0 < msec : 0 < 10 msec : 0 < 0.1s : 0 < s : 1936 < 10s : 0 < 100s : 0 Без SKIP LOCKED все в ступор впадает...   Индексы сделал несоставные
  8. Поигрался с индексами чуть удалось разогнать, но не сильно) 60 тыс. записей Гугол не знае про округление индексов...
  9. Были не составные разницы никакой. В MySQL 8.0.1 был введен модификатор SKIP LOCKED, использующийся для не детерминистического чтения из таблицы с пропуском строк, заблокированых другими пользователями. https://sqlinfo.ru/articles/info/41.html
  10. +----+-------------+-----------+------------+------+-----------------------+-----------+---------+-------+-------+----------+------------------------------------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------+------------+------+-----------------------+-----------+---------+-------+-------+----------+------------------------------------------+ | 1 | SIMPLE | radippool | NULL | ref | pool_name,pool_name_2 | pool_name | 92 | const | 28978 | 46.00 | Using where; Using index; Using filesort | +----+-------------+-----------+------------+------+-----------------------+-----------+---------+-------+-------+----------+------------------------------------------+ 1 row in set, 1 warning (0,00 sec) Все ок.   mysql> show indexes from radippool; +-----------+------------+-------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment | Visible | Expression | +-----------+------------+-------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ | radippool | 0 | PRIMARY | 1 | id | A | 57731 | NULL | NULL | | BTREE | | | YES | NULL | | radippool | 1 | pool_name | 1 | pool_name | A | 1 | NULL | NULL | | BTREE | | | YES | NULL | | radippool | 1 | pool_name | 2 | username | A | 57731 | NULL | NULL | | BTREE | | | YES | NULL | | radippool | 1 | pool_name | 3 | expiry_time | A | 57731 | NULL | NULL | YES | BTREE | | | YES | NULL | | radippool | 1 | pool_name | 4 | framedipaddress | A | 57731 | NULL | NULL | | BTREE | | | YES | NULL | | radippool | 1 | pool_name_2 | 1 | pool_name | A | 1 | NULL | NULL | | BTREE | | | YES | NULL | | radippool | 1 | pool_name_2 | 2 | expiry_time | A | 12004 | NULL | NULL | YES | BTREE | | | YES | NULL | | radippool | 1 | pool_name_2 | 3 | username | A | 55087 | NULL | NULL | | BTREE | | | YES | NULL | | radippool | 1 | pool_name_2 | 4 | framedipaddress | A | 56460 | NULL | NULL | | BTREE | | | YES | NULL | +-----------+------------+-------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+---------------+---------+------------+ Ну логично что блокируется вся таблица без SKIP LOCK
  11. Текущая конфигурация индексов Create Table CREATE TABLE `radippool` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `pool_name` varchar(30) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, `framedipaddress` varchar(15) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '', `nasipaddress` varchar(15) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '', `calledstationid` varchar(30) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, `callingstationid` varchar(30) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, `expiry_time` datetime DEFAULT NULL, `username` varchar(64) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT '', `pool_key` varchar(30) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, PRIMARY KEY (`id`), KEY `pool_name` (`pool_name`,`username`,`expiry_time`,`framedipaddress`), KEY `pool_name_2` (`pool_name`,`expiry_time`,`username`,`framedipaddress`) ) ENGINE=InnoDB AUTO_INCREMENT=70092 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci Для отсутствия блокировки таблицы, используется MySQL 8 c SKIP LOCK allocate_find = "\ SELECT framedipaddress FROM ${ippool_table} \ WHERE pool_name = 'test' \ AND ( (username = '%{User-Name}') OR (expiry_time < NOW() OR expiry_time IS NULL) ) \ ORDER BY \ (username <> '%{User-Name}'), \ expiry_time \ LIMIT 1 \ FOR UPDATE SKIP LOCKED"
  12. Так и сделано, правда индекс еще и по адресу.
  13. Это было проверено первым) когда у тебя 10 тыс клиентов подключается, все просто умирает)
  14. Да уже как только и индексы не крутил, и различные тюнинги, всеравно просто жо... Интересно как у других оно, наверняка уже набили шишки.
  15. Коллеги дайте совет. Есть Freeradius где абонентам выделяются IP адреса используя следующие запросы. allocate_find = "\ SELECT framedipaddress FROM ${ippool_table} \ WHERE pool_name = 'test' \ AND ( (username = '%{User-Name}') OR (expiry_time < NOW() OR expiry_time IS NULL) ) \ ORDER BY \ (username <> '%{User-Name}'), \ expiry_time \ LIMIT 1 \ FOR UPDATE" allocate_update = "\ UPDATE ${ippool_table} \ SET \ nasipaddress = '%{NAS-IP-Address}', pool_key = '${pool_key}', \ callingstationid = '%{Calling-Station-Id}', \ username = '%{User-Name}', expiry_time = NOW() + INTERVAL ${lease_duration} SECOND \ WHERE framedipaddress = '%I'" Если использовать mariadb 10.3 + InnoDB(myisam не подходит из за необходимости транзакций) то при тестирование база быстро загибается, в процессах повисают SELECT. При использование Postgres из коробки все летает, все достаточно быстро обрабатывает. После небольшого тюнинга производительность вырасла еще в два раза... Пробовал использовать MySQL с функцией построчной блокировки FOR UPDATE SKIP LOCK производительность MySQL выросла, но всеравно в разы хуже чем у Postgresql Неужели у MySQL+InnoDB все так плохо? Кто какие решения использует?