Название: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 23 Декабря 2017, 18:20:49
Время от времени я вижу жалобы на то, что бывают разного рода глюки с выдачей динамических ip. Я тут хорошо покрутил все и кажется понял в чем проблема. На самом деле основные проблемы 2: 1) deadlock-и в mysql - это когда некоторые запросы блокируют друг-друга и из-за этого не дают выполняться другим 2) бывает, что ip на nas-е не соответствует ip, которое светится в биллинге Насчет deadlock-ов. Причин тут несколько: 1) сука тупой mysql. Вот реально гадина, я тебя всегда защищал, но ты впадаешь в лок на запросах, которые ну никак логически не должны приводить к такому 2) большая нагрузка Начнем с нагрузки. Старайтесь выносить такие модули ядра как сбор трафика и заглушка на другой сервер. Особенно заглушка ибо на нее бывает льется столько трафика, что отжирает 100% проца. Если нет возможности вынести - хотя бы ограничьте количество сессий с одного ip на заглушку. Что касается mysql. Мне пришлось кординально переделать процедуру get_ip. Я сделал такие 2 серьезных изменения: 1) сделал код примитивным и очень избыточным, что бы все sql были максимально нежными. Процедура стала выглядеть тупо, не показывайте ее профи)) 2) основной затык был в выборе незанятого динамического ip. Дело в том, что mysql при большом количестве запросов выдавало одну и туже свободную запись, в этом проблемы нет, это разруливалось, но из-за такой коллизии сильно росла нагрузка. Я бы мог сделать выборку и из нее выбрать случайную строку, но mysql в этом случае создает временную таблицу, а это тоже плохо. Поэтому я поступил хитро: в таблице ip (ip_pool) я физически перегруппировую записи по типу, тегам и т.д. Для этого я создал процедуру normalize_ippool: DROP FUNCTION IF EXISTS `normalize_ippool`;
DELIMITER $$
CREATE FUNCTION `normalize_ippool` ( )
RETURNS TINYINT NO SQL
BEGIN
DECLARE mid INTEGER UNSIGNED;
CREATE TEMPORARY TABLE temp_ip_pool(
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
ip_id BIGINT UNSIGNED NOT NULL,
PRIMARY KEY (id)
);
SELECT MAX(id) into mid FROM ip_pool;
UPDATE ip_pool SET id = id + mid;
INSERT temp_ip_pool (SELECT NULL, id FROM ip_pool ORDER BY realip, type, tags);
UPDATE ip_pool i JOIN temp_ip_pool t ON i.id = t.ip_id SET i.id = t.id;
DROP TEMPORARY TABLE IF EXISTS temp_ip_pool;
RETURN 1;
END$$
DELIMITER ; Вызов этой функции я добавлю в админку при изменении любого ip/пула. Благодаря этому в get_ip я сразу беру рандомную строку без предварительной выборки, зная только начальный и конечный id нужной группы. Конечно, вам эта инфа особо не интересна, это я так для себя чтоб сохранилось в истории, ну и может теоретически кому-то понадобится. Насчет дубликатов ip. Имеется ввиду такая ситуация: есть nas и есть сервер с биллингом. Сервер перезагружается, загружается больше 6 минут, запускает модуль ядра auth, который сразу освобождает все ip по таймауту. Он-то думает, что раз 6 минут не было аккаунтинга по данным ip - значит все сессии на насе кильнулись. Он же не знает, что просто небыло коннекта с nas. А на nas сесси-то висят, а биллинг считает ip свободными и выдает другим абонам. Когда я давно придумал схему с освобождением ip, я подумал, что сервер стартанет за пару минут. Кроме того, я не предусмотрел, что может быть разрыв канала больше чем 6 минут. Поэтому сейчас я установил таймаут в час (3600 секунд) в get_ip и set_auth: DROP PROCEDURE IF EXISTS `set_auth`;
DELIMITER $$
CREATE PROCEDURE `set_auth` (IN usr_ip VARCHAR(15), IN auth_properties VARCHAR(255))
BEGIN
DECLARE usr_id INT;
SELECT uid INTO usr_id FROM ip_pool WHERE INET_ATON(usr_ip) = ip LIMIT 1;
IF( usr_id > 0 ) THEN
INSERT INTO auth_now SET
ip = usr_ip,
properties = auth_properties,
start = UNIX_TIMESTAMP(),
last = UNIX_TIMESTAMP()
ON DUPLICATE KEY UPDATE
properties = IF(auth_properties!='',auth_properties,properties),
last = UNIX_TIMESTAMP();
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
WHERE ip = INET_ATON(usr_ip) AND type = 'dynamic' LIMIT 1;
END IF;
END$$
DELIMITER ;
DROP FUNCTION IF EXISTS `get_ip`;
DELIMITER $$
CREATE FUNCTION `get_ip` ( user_id INTEGER UNSIGNED )
RETURNS VARCHAR(15) NO SQL
BEGIN
DECLARE user_ip VARCHAR(15);
DECLARE real_ip VARCHAR(15) DEFAULT 0;
DECLARE row_cnt INTEGER;
DECLARE ip_id INTEGER;
DECLARE tries INTEGER DEFAULT 30;
DECLARE id_min INTEGER;
DECLARE id_max INTEGER;
SELECT INET_NTOA(ip) INTO user_ip FROM ip_pool
WHERE uid = user_id AND type='static' LIMIT 1;
IF( user_ip IS NOT NULL ) THEN RETURN user_ip; END IF;
SELECT 1 INTO real_ip FROM users_services WHERE uid = user_id AND tags LIKE '%,realip,%';
SELECT id, INET_NTOA(ip) INTO ip_id, user_ip FROM ip_pool
WHERE uid = user_id AND type = 'dynamic' AND realip = IF(real_ip>0,1,0)
LIMIT 1;
IF( ip_id IS NOT NULL) THEN
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
WHERE id = ip_id AND uid = user_id;
SELECT ROW_COUNT() INTO row_cnt;
IF( row_cnt > 0 ) THEN RETURN user_ip; END IF;
END IF;
SELECT MAX(id), MIN(id) INTO id_max, id_min
FROM ip_pool
WHERE type = 'dynamic' AND realip = IF(real_ip>0,1,0);
sel_ip: WHILE tries > 0 DO
SELECT id, INET_NTOA(ip) INTO ip_id, user_ip
FROM ip_pool
WHERE uid = 0
AND id >= (CEIL(RAND() * (id_max - id_min)) + id_min)
AND id <= id_max
LIMIT 1;
IF( user_ip IS NOT NULL) THEN
UPDATE ip_pool SET uid = user_id, `release` = UNIX_TIMESTAMP() + 3600
WHERE id = ip_id AND uid = 0;
SELECT ROW_COUNT() INTO row_cnt;
IF( row_cnt > 0 ) THEN RETURN user_ip; END IF;
SET tries = tries - 5;
END IF;
SET tries = tries - 1;
END WHILE;
END$$
DELIMITER ;
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 23 Декабря 2017, 18:25:17
Если вы захотите все это проверить уже сейчас, то после создания всех трех процедур и функций, надо выполнить: select normalize_ippool(); пока надо будет выполнять каждый раз если вы что-то будете менять в пуле ip
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 24 Декабря 2017, 10:10:50
Сюда же. В модуле ядра auth.pm есть такой sql, который удаляет некорректные записи в таблице текущих авторизаций: DELETE FROM auth_now WHERE INET_ATON(ip) NOT IN (SELECT ip FROM ip_pool WHERE uid>0)
его лучше заменить на 2: DELETE a FROM auth_now a LEFT JOIN ip_pool i ON INET_ATON(a.ip) = i.ip WHERE i.uid=0;
DELETE a FROM auth_now a LEFT JOIN ip_pool i ON INET_ATON(a.ip) = i.ip WHERE i.ip IS NULL;
(не тупо заменить, а сделать 2 Db->do(..)) я, конечно, это все включу в стандартную поставку
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fix от 04 Января 2018, 08:53:59
2) большая нагрузка:
Начнем с нагрузки. Старайтесь выносить такие модули ядра как сбор трафика и заглушка на другой сервер. Особенно заглушка ибо на нее бывает льется столько трафика, что отжирает 100% проца. Если нет возможности вынести - хотя бы ограничьте количество сессий с одного ip на заглушку.
Возможно у меня мало опыта, не видел чтоб заглушка отжирала 100% проца. Вы не ошиблись, может быть 100% ядра ? 100% ядра видел, а 100% всех 8-10-12-16 ядер не видел. 2) бывает, что ip на nas-е не соответсвует ip, которое светится в биллинге:
Насчет дубликатов ip. Имеется ввиду такая ситуация: есть nas и есть сервер с биллингом. Сервер перезагружается, загружается больше 6 минут, запускает модуль ядра auth, который сразу освобождает все ip по таймауту. Он-то думает, что раз 6 минут не было аккаунтинга по данным ip - значит все сессии на насе кильнулись. Он же не знает, что просто небыло коннекта с nas. А на nas сесси-то висят, а биллинг считает ip свободными и выдает другим абонам. Когда я давно придумал схему с освобождением ip, я подумал, что сервер стартанет за пару минут. Кроме того, я не предусмотрел, что может быть разрыв канала больше чем 6 минут. Поэтому сейчас я установил таймаут в час (3600 секунд) в get_ip и set_auth:
Подскажите пожалуйста, если например ночью упал канал, между биллингом и насом больше чем на час, например на 2-3-4 часа и в итоге ситуация с дубликатами и не соответствием айпи в биллинге и на насе станет возможной ? Перезагружать насы после восстановления связности ?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: cojiict от 04 Января 2018, 09:11:47
Подскажите пожалуйста, если например ночью упал канал, между биллингом и насом больше чем на час, например на 2-3-4 часа и в итоге ситуация с дубликатами и не соответствием айпи в биллинге и на насе станет возможной ?
Перезагружать насы после восстановления связности ?
noserver з певною періодичністю буде звертатись до бази даних і головне перевірити чи є між ними доступ. Все ще залежить від типу авторизації. Буває radius треба синхронізувати
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fix от 09 Января 2018, 14:16:10
Подскажите пожалуйста, если например ночью упал канал, между биллингом и насом больше чем на час, например на 2-3-4 часа и в итоге ситуация с дубликатами и не соответствием айпи в биллинге и на насе станет возможной ?
Перезагружать насы после восстановления связности ?
noserver з певною періодичністю буде звертатись до бази даних і головне перевірити чи є між ними доступ. Все ще залежить від типу авторизації. Буває radius треба синхронізувати После восстановления связности, с высокой вероятностью, связь между насом и биллингом восстановится "автоматически". Не могли бы Вы более развернуто выразить вашу мысль, про типы авторизации и синхронизацию радиуса ? Если мне не изменяет мой склероз, то дубликаты айпи, возможны при PPPoE авторизации, при отсутствии связности, некоторый промежуток времени(6 минут раньше, 60 минут сейчас), между насом и биллингом. Так вот меня очень интересует, после вышеописанных изменений, возможно ли повторение ситуации с дублями айпи, если связности между насом и биллингом, не будет больше часа ?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 09 Января 2018, 16:30:31
Если больше часа, то дубли будут. Есть возможность выявить такую ситуацию автоматически, просто надо подумать что делать в этом случае - в идеале послать команду дисконнекта, но mpd игнорит ее в аккаунтинге, поэтому надо привлекать модуль coa. Но отсутствие связи с базой в течение часа - это разве нормально?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fix от 09 Января 2018, 17:24:15
Если больше часа, то дубли будут. Есть возможность выявить такую ситуацию автоматически, просто надо подумать что делать в этом случае - в идеале послать команду дисконнекта, но mpd игнорит ее в аккаунтинге, поэтому надо привлекать модуль coa. Но отсутствие связи с базой в течение часа - это разве нормально?
Не совсем нормально, отсутствие связи. Связность в случаях с удаленными насами, имеет свойство иногда падать, по различным причинам. Не рядовое, но вполне обычное событие. Модуль радиус соа или вебсоа ? В идеале, "синхронизация" между насом и биллингом и посыл дисконнекта, с "неправильными" айпи адресами. Возможно, кто то предложит более изящное решение.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: sever от 24 Января 2018, 17:31:09
Кто-то в боевой режим уже внедрил?
Как успехи?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 24 Января 2018, 17:38:39
Я этот топик написал по факту внедрения. Вроде там несколько тысяч онлайна было
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 26 Января 2018, 14:00:13
Кто-то в боевой режим уже внедрил?
Как успехи?
Успехи внедрения из первого поста, работает отлично, 3-4К со старта авторизует и дальше, пока без проблем работает.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Cell от 26 Января 2018, 16:46:33
Может немного не в тему, но у меня вопрос - а в чем прикол динамических ip пулов? В чем их преимущество перед статическими?
Экономия ip адресов была актуальна лет 10 назад, если не больше. В настоящее время нет никакой экономии от слова совсем. Ну может 10% от общего числа и то этот процент скорее плавающая в сторону уменьшения величина по причине поголовного использования абонентами домашних роутеров.
Да, могу придумать плюсы для всяких дота-дрочеров, которым ипы банят на игровых серверах... им лафа - а для провайдера какой смысл? Все это уже проходили с прозрачными прокси-серверами экономя 15% трафика, где они сейчас?
Вот и хочу понять в чем извращение с этими динамическими пулами. Кто-то может ответить аргументированно, без "А мне так хочется"?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Warlock от 26 Января 2018, 19:36:01
Мы всем клиентам даём внешние айпи. И как тут без динамики?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 05 Февраля 2018, 11:33:22
Периодические записи в логе freeradius такого рода Sun Feb 4 08:53:43 2018 : Error: [sql] Couldn't update SQL accounting ALIVE record - Deadlock found when trying to get lock; try restarting transaction
Sun Feb 4 08:53:43 2018 : Error: rlm_sql_mysql: Cannot store result
Sun Feb 4 08:53:43 2018 : Error: rlm_sql_mysql: MySQL error 'Deadlock found when trying to get lock; try restarting transaction'
Mon Feb 5 01:32:00 2018 : Error: rlm_sql (sql) in sql_postauth: Database query error - Deadlock found when trying to get lock; try restarting transaction Говорят о данной проблеме ? В логе самого мускула пусто.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 05 Февраля 2018, 15:13:02
Периодические записи в логе freeradius такого рода Sun Feb 4 08:53:43 2018 : Error: [sql] Couldn't update SQL accounting ALIVE record - Deadlock found when trying to get lock; try restarting transaction
Sun Feb 4 08:53:43 2018 : Error: rlm_sql_mysql: Cannot store result
Sun Feb 4 08:53:43 2018 : Error: rlm_sql_mysql: MySQL error 'Deadlock found when trying to get lock; try restarting transaction'
Mon Feb 5 01:32:00 2018 : Error: rlm_sql (sql) in sql_postauth: Database query error - Deadlock found when trying to get lock; try restarting transaction Говорят о данной проблеме ? С какой периодичностью такое в логе ? Периодически, несколько строк, такое в логах раньше проскакивало и каких то ощутимых проблем небыло. Если такое валит в логе "пачками" и постоянно, то да, началось.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: NoDeny support от 05 Февраля 2018, 18:08:28
Периодические записи в логе freeradius такого рода Sun Feb 4 08:53:43 2018 : Error: [sql] Couldn't update SQL accounting ALIVE record - Deadlock found when trying to get lock; try restarting transaction
Sun Feb 4 08:53:43 2018 : Error: rlm_sql_mysql: Cannot store result
Sun Feb 4 08:53:43 2018 : Error: rlm_sql_mysql: MySQL error 'Deadlock found when trying to get lock; try restarting transaction'
Mon Feb 5 01:32:00 2018 : Error: rlm_sql (sql) in sql_postauth: Database query error - Deadlock found when trying to get lock; try restarting transaction Говорят о данной проблеме ? В логе самого мускула пусто. show engine innodb status; покажите что выдает
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 05 Февраля 2018, 19:26:29
InnoDB
=====================================
2018-02-05 19:21:42 7efd0e60b700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 7 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 5554631 srv_active, 0 srv_shutdown, 10469 srv_idle
srv_master_thread log flush and writes: 5564818
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 13794285
OS WAIT ARRAY INFO: signal count 14003827
Mutex spin waits 21527290, rounds 308023037, OS waits 9410597
RW-shared spins 4481949, rounds 130026393, OS waits 4275545
RW-excl spins 261627, rounds 4811527, OS waits 73024
Spin rounds per wait: 14.31 mutex, 29.01 RW-shared, 18.39 RW-excl
------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-02-05 19:16:27 7efd28157700
*** (1) TRANSACTION:
TRANSACTION 512587367, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1184, 2 row lock(s)
MySQL thread id 8358, OS thread handle 0x7efd6591f700, query id 946881457 172.19.0.1 nodeny updating
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 300
WHERE ip = INET_ATON( NAME_CONST('usr_ip',_latin1'10.193.2.1' COLLATE 'latin1_swedish_ci')) AND type = 'dynamic' LIMIT 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 856 page no 11 n bits 440 index `PRIMARY` of table `nodeny`.`ip_pool` trx table locks 1 total table locks 2 trx id 512587367 lock_mode X locks rec but not gap waiting lock hold time 0 wait time before grant 0
*** (2) TRANSACTION:
TRANSACTION 512587358, ACTIVE 0 sec fetching rows
mysql tables in use 3, locked 5
31 lock struct(s), heap size 6544, 15050 row lock(s)
MySQL thread id 8360, OS thread handle 0x7efd28157700, query id 946881408 172.19.0.1 nodeny Sending data
UPDATE ip_pool SET uid = NAME_CONST('user_id',812), `release` = UNIX_TIMESTAMP() + 300
WHERE id = (SELECT id FROM (
(SELECT id, uid FROM ip_pool
WHERE uid = 0
AND type = 'dynamic'
AND realip = IF( NAME_CONST('real_ip',NULL)>0,1,0)
LIMIT 1)
UNION
(SELECT id, uid FROM ip_pool
WHERE uid = NAME_CONST('user_id',812)
AND type = 'dynamic'
AND realip = IF( NAME_CONST('real_ip',NULL)>0,1,0)
LIMIT 1)
) AS tbl ORDER BY uid DESC LIMIT 1)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 856 page no 11 n bits 440 index `PRIMARY` of table `nodeny`.`ip_pool` trx table locks 1 total table locks 2 trx id 512587358 lock_mode X locks rec but not gap lock hold time 0 wait time before grant 0
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 856 page no 11 n bits 440 index `PRIMARY` of table `nodeny`.`ip_pool` trx table locks 1 total table locks 2 trx id 512587358 lock_mode X waiting lock hold time 0 wait time before grant 0
*** WE ROLL BACK TRANSACTION (1)
------------
TRANSACTIONS
------------
Trx id counter 512620496
Purge done for trx's n:o < 512620495 undo n:o < 0 state: running but idle
History list length 41
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 3053566, OS thread handle 0x7efd0e60b700, query id 946945312 localhost 127.0.0.1 root init
show engine innodb STATUS
---TRANSACTION 0, not started
MySQL thread id 3053518, OS thread handle 0x7efd067f5700, query id 946938247 localhost 127.0.0.1 mailuser cleaning up
---TRANSACTION 512615340, not started
MySQL thread id 3036125, OS thread handle 0x7efd0c150700, query id 946935274 172.19.0.12 nodeny cleaning up
---TRANSACTION 512618190, not started
MySQL thread id 3036106, OS thread handle 0x7efd0c39c700, query id 946941130 172.19.0.12 nodeny cleaning up
---TRANSACTION 512609773, not started
MySQL thread id 3033913, OS thread handle 0x7efcfb36c700, query id 946923378 localhost zabbix cleaning up
---TRANSACTION 512615302, not started
MySQL thread id 3031967, OS thread handle 0x7efd16dc4700, query id 946935206 localhost zabbix cleaning up
---TRANSACTION 512620471, not started
MySQL thread id 3012801, OS thread handle 0x7efd658bd700, query id 946945250 localhost nodeny cleaning up
---TRANSACTION 512620361, not started
MySQL thread id 2991498, OS thread handle 0x7efd0c08c700, query id 946944952 localhost zabbix cleaning up
---TRANSACTION 512617219, not started
MySQL thread id 2991436, OS thread handle 0x7efd0e5da700, query id 946938582 localhost zabbix cleaning up
---TRANSACTION 512617316, not started
MySQL thread id 2942979, OS thread handle 0x7efd0c11f700, query id 946938806 172.19.0.12 nodeny cleaning up
---TRANSACTION 512615152, not started
MySQL thread id 2936489, OS thread handle 0x7efd06452700, query id 946934803 172.19.0.12 nodeny cleaning up
---TRANSACTION 512618467, not started
MySQL thread id 2925925, OS thread handle 0x7efd0e578700, query id 946941680 localhost zabbix cleaning up
---TRANSACTION 512620345, not started
MySQL thread id 2307611, OS thread handle 0x7efd67567700, query id 946945229 localhost nodeny cleaning up
---TRANSACTION 512612607, not started
MySQL thread id 2184255, OS thread handle 0x7efd0e63c700, query id 946929535 localhost zabbix cleaning up
---TRANSACTION 512600694, not started
MySQL thread id 2183835, OS thread handle 0x7efd16c9e700, query id 946905732 localhost zabbix cleaning up
---TRANSACTION 512620088, not started
MySQL thread id 2183808, OS thread handle 0x7efd0e483700, query id 946944200 localhost zabbix cleaning up
---TRANSACTION 512606531, not started
MySQL thread id 2183767, OS thread handle 0x7efd65ad8700, query id 946916906 localhost zabbix cleaning up
---TRANSACTION 512594797, not started
MySQL thread id 2183746, OS thread handle 0x7efd5adc7700, query id 946894513 localhost zabbix cleaning up
---TRANSACTION 512620358, not started
MySQL thread id 493646, OS thread handle 0x7efd67472700, query id 946944939 localhost zabbix cleaning up
---TRANSACTION 512041425, not started
MySQL thread id 493697, OS thread handle 0x7efd16f1b700, query id 946940708 localhost zabbix cleaning up
---TRANSACTION 512615449, not started
MySQL thread id 493639, OS thread handle 0x7efd65b9c700, query id 946936160 localhost zabbix cleaning up
---TRANSACTION 512620289, not started
MySQL thread id 493642, OS thread handle 0x7efd67505700, query id 946944749 localhost zabbix cleaning up
---TRANSACTION 512620421, not started
MySQL thread id 493641, OS thread handle 0x7efd16d00700, query id 946945113 localhost zabbix cleaning up
---TRANSACTION 512620464, not started
MySQL thread id 493640, OS thread handle 0x7efd16d62700, query id 946945233 localhost zabbix cleaning up
---TRANSACTION 512361987, not started
MySQL thread id 493647, OS thread handle 0x7efd65b3a700, query id 946945130 localhost zabbix cleaning up
---TRANSACTION 512036270, not started
MySQL thread id 493661, OS thread handle 0x7efd68440700, query id 946945195 localhost zabbix cleaning up
---TRANSACTION 512620057, not started
MySQL thread id 493657, OS thread handle 0x7efd6afec700, query id 946944120 localhost zabbix cleaning up
---TRANSACTION 512620420, not started
MySQL thread id 493644, OS thread handle 0x7efd16c6d700, query id 946945108 localhost zabbix cleaning up
---TRANSACTION 510058043, not started
MySQL thread id 493643, OS thread handle 0x7efd16d93700, query id 946945287 localhost zabbix cleaning up
---TRANSACTION 512620387, not started
MySQL thread id 8968, OS thread handle 0x7efd65a45700, query id 946945019 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620433, not started
MySQL thread id 8330, OS thread handle 0x7efd65a14700, query id 946945131 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620427, not started
MySQL thread id 8331, OS thread handle 0x7efd16df5700, query id 946945114 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620419, not started
MySQL thread id 8332, OS thread handle 0x7efd16fae700, query id 946945091 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620410, not started
MySQL thread id 8333, OS thread handle 0x7efd16eb9700, query id 946945072 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620404, not started
MySQL thread id 8334, OS thread handle 0x7efd659b2700, query id 946945055 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620398, not started
MySQL thread id 8335, OS thread handle 0x7efd16f4c700, query id 946945039 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620392, not started
MySQL thread id 8336, OS thread handle 0x7efd16eea700, query id 946945020 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620385, not started
MySQL thread id 8337, OS thread handle 0x7efd65a76700, query id 946945002 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620379, not started
MySQL thread id 8338, OS thread handle 0x7efd16e57700, query id 946944986 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620373, not started
MySQL thread id 8339, OS thread handle 0x7efd280c4700, query id 946944970 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620367, not started
MySQL thread id 8340, OS thread handle 0x7efd16f7d700, query id 946944953 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620357, not started
MySQL thread id 8341, OS thread handle 0x7efd65b09700, query id 946944920 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620351, not started
MySQL thread id 8342, OS thread handle 0x7efd28126700, query id 946944904 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620343, not started
MySQL thread id 8343, OS thread handle 0x7efd28062700, query id 946944881 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620337, not started
MySQL thread id 8344, OS thread handle 0x7efd6585b700, query id 946944864 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620336, not started
MySQL thread id 8345, OS thread handle 0x7efd5ad34700, query id 946944849 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620325, not started
MySQL thread id 8346, OS thread handle 0x7efd65b6b700, query id 946944833 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620319, not started
MySQL thread id 8347, OS thread handle 0x7efd5adf8700, query id 946944817 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620313, not started
MySQL thread id 8348, OS thread handle 0x7efd5ad96700, query id 946944801 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620307, not started
MySQL thread id 8349, OS thread handle 0x7efd5acd2700, query id 946944783 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620301, not started
MySQL thread id 8350, OS thread handle 0x7efd16fdf700, query id 946944767 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620295, not started
MySQL thread id 8351, OS thread handle 0x7efd5ac3f700, query id 946944750 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620288, not started
MySQL thread id 8352, OS thread handle 0x7efd280f5700, query id 946944729 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620495, not started
MySQL thread id 8353, OS thread handle 0x7efd5aca1700, query id 946945288 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620488, not started
MySQL thread id 8354, OS thread handle 0x7efd5ad65700, query id 946945267 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620479, not started
MySQL thread id 8355, OS thread handle 0x7efd28031700, query id 946945251 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620470, not started
MySQL thread id 8356, OS thread handle 0x7efd5ac70700, query id 946945234 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620463, not started
MySQL thread id 8357, OS thread handle 0x7efd6588c700, query id 946945212 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620457, not started
MySQL thread id 8358, OS thread handle 0x7efd6591f700, query id 946945196 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620451, not started
MySQL thread id 8359, OS thread handle 0x7efd5ad03700, query id 946945179 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620445, not started
MySQL thread id 8360, OS thread handle 0x7efd28157700, query id 946945163 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620439, not started
MySQL thread id 8361, OS thread handle 0x7efd659e3700, query id 946945147 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620344, not started
MySQL thread id 8232, OS thread handle 0x7efd16e26700, query id 946944899 localhost nodeny cleaning up
---TRANSACTION 7548675, not started
MySQL thread id 1, OS thread handle 0x7efd6b07f700, query id 0 Waiting for requests
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
43077 OS file reads, 188349493 OS file writes, 176845559 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 11.14 writes/s, 10.28 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 3, seg size 5, 604 merges
merged operations:
insert 435, delete mark 420, delete 173
discarded operations:
insert 0, delete mark 0, delete 0
2284.96 hash searches/s, 122.70 non-hash searches/s
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 05 Февраля 2018, 19:27:33
---
LOG
---
Log sequence number 96134894828
Log flushed up to 96134894828
Pages flushed up to 96130246034
Last checkpoint at 96130130080
Max checkpoint age 80826164
Checkpoint age target 78300347
Modified age 4648794
Checkpoint age 4764748
0 pending log writes, 0 pending chkp writes
162846807 log i/o's done, 8.14 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 1124597760; in additional pool allocated 0
Total memory allocated by read views 11064
Internal hash tables (constant factor + variable factor)
Adaptive hash index 171231792 (18921928 + 152309864)
Page hash 139112 (buffer pool 0 only)
Dictionary cache 6901410 (4426736 + 2474674)
File system 1047568 (812272 + 235296)
Lock system 2680216 (2657176 + 23040)
Recovery system 0 (0 + 0)
Dictionary memory allocated 2474674
Buffer pool size 65528
Buffer pool size, bytes 1073610752
Free buffers 8195
Database pages 48037
Old database pages 17567
Modified db pages 882
Percent of dirty pages(LRU & free pages): 1.568
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 164426, not young 18029549
0.00 youngs/s, 0.00 non-youngs/s
Pages read 42898, created 53237, written 19904797
0.00 reads/s, 0.00 creates/s, 2.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 48037, unzip_LRU len: 0
I/O sum[2496]:cur[0], unzip sum[0]:cur[0]
----------------------
INDIVIDUAL BUFFER POOL INFO
----------------------
---BUFFER POOL 0
Buffer pool size 8191
Buffer pool size, bytes 134201344
Free buffers 1025
Database pages 5995
Old database pages 2192
Modified db pages 149
Percent of dirty pages(LRU & free pages): 2.122
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 24523, not young 3046416
0.00 youngs/s, 0.00 non-youngs/s
Pages read 7120, created 6807, written 2686010
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 5995, unzip_LRU len: 0
I/O sum[312]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 1
Buffer pool size 8191
Buffer pool size, bytes 134201344
Free buffers 1025
Database pages 6004
Old database pages 2196
Modified db pages 115
Percent of dirty pages(LRU & free pages): 1.636
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 21411, not young 2189526
0.00 youngs/s, 0.00 non-youngs/s
Pages read 4852, created 6728, written 2563605
0.00 reads/s, 0.00 creates/s, 0.14 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 6004, unzip_LRU len: 0
I/O sum[312]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 2
Buffer pool size 8191
Buffer pool size, bytes 134201344
Free buffers 1025
Database pages 6008
Old database pages 2197
Modified db pages 53
Percent of dirty pages(LRU & free pages): 0.753
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 19196, not young 2396644
0.00 youngs/s, 0.00 non-youngs/s
Pages read 5292, created 6950, written 1435746
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 6008, unzip_LRU len: 0
I/O sum[312]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 3
Buffer pool size 8191
Buffer pool size, bytes 134201344
Free buffers 1024
Database pages 6003
Old database pages 2195
Modified db pages 163
Percent of dirty pages(LRU & free pages): 2.319
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 21799, not young 2526399
0.00 youngs/s, 0.00 non-youngs/s
Pages read 4750, created 7109, written 3859919
0.00 reads/s, 0.00 creates/s, 1.29 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 6003, unzip_LRU len: 0
I/O sum[312]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 4
Buffer pool size 8191
Buffer pool size, bytes 134201344
Free buffers 1024
Database pages 6011
Old database pages 2198
Modified db pages 87
Percent of dirty pages(LRU & free pages): 1.236
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 18698, not young 1585210
0.00 youngs/s, 0.00 non-youngs/s
Pages read 4437, created 6690, written 2296132
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 6011, unzip_LRU len: 0
I/O sum[312]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 5
Buffer pool size 8191
Buffer pool size, bytes 134201344
Free buffers 1024
Database pages 6016
Old database pages 2200
Modified db pages 97
Percent of dirty pages(LRU & free pages): 1.378
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 18843, not young 2221107
0.00 youngs/s, 0.00 non-youngs/s
Pages read 6341, created 6186, written 2231536
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 6016, unzip_LRU len: 0
I/O sum[312]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 6
Buffer pool size 8191
Buffer pool size, bytes 134201344
Free buffers 1024
Database pages 6001
Old database pages 2195
Modified db pages 126
Percent of dirty pages(LRU & free pages): 1.793
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 21144, not young 2031219
0.00 youngs/s, 0.00 non-youngs/s
Pages read 5100, created 6494, written 2647712
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 6001, unzip_LRU len: 0
I/O sum[312]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 7
Buffer pool size 8191
Buffer pool size, bytes 134201344
Free buffers 1024
Database pages 5999
Old database pages 2194
Modified db pages 92
Percent of dirty pages(LRU & free pages): 1.310
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 18812, not young 2033028
0.00 youngs/s, 0.00 non-youngs/s
Pages read 5006, created 6273, written 2184137
0.00 reads/s, 0.00 creates/s, 0.57 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 5999, unzip_LRU len: 0
I/O sum[312]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
0 RW transactions active inside InnoDB
0 RO transactions active inside InnoDB
0 out of 1000 descriptors used
Main thread process no. 4434, id 139625259583232, state: sleeping
Number of rows inserted 31937246, updated 153406010, deleted 25269830, read 40621204230
3.86 inserts/s, 6.00 updates/s, 0.00 deletes/s, 4788.89 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 2
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================ Периодически, несколько строк, такое в логах раньше проскакивало и каких то ощутимых проблем небыло. Несколько раз в день, судя по логу. Ощутимых проблем нет, а по логу то уже есть. В последних ревизиях проблема решена?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 05 Февраля 2018, 20:16:39
Несколько раз в день, судя по логу. Ощутимых проблем нет, а по логу то уже есть.
В логах эти разовые "проблемы" могут возникать по различным причинам, и не факт, что необходимо устранять эти единичные случаи. Вот если начнется такое "пачками" непрерывно, Вы поймете сразу, что проблема началась. С другой стороны, почему бы не применить новые процедуры, которые работают лучше чем предыдущие ?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: NoDeny support от 05 Февраля 2018, 20:21:05
InnoDB
=====================================
2018-02-05 19:21:42 7efd0e60b700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 7 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 5554631 srv_active, 0 srv_shutdown, 10469 srv_idle
srv_master_thread log flush and writes: 5564818
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 13794285
OS WAIT ARRAY INFO: signal count 14003827
Mutex spin waits 21527290, rounds 308023037, OS waits 9410597
RW-shared spins 4481949, rounds 130026393, OS waits 4275545
RW-excl spins 261627, rounds 4811527, OS waits 73024
Spin rounds per wait: 14.31 mutex, 29.01 RW-shared, 18.39 RW-excl
------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-02-05 19:16:27 7efd28157700
*** (1) TRANSACTION:
TRANSACTION 512587367, ACTIVE 0 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1184, 2 row lock(s)
MySQL thread id 8358, OS thread handle 0x7efd6591f700, query id 946881457 172.19.0.1 nodeny updating
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 300
WHERE ip = INET_ATON( NAME_CONST('usr_ip',_latin1'10.193.2.1' COLLATE 'latin1_swedish_ci')) AND type = 'dynamic' LIMIT 1
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 856 page no 11 n bits 440 index `PRIMARY` of table `nodeny`.`ip_pool` trx table locks 1 total table locks 2 trx id 512587367 lock_mode X locks rec but not gap waiting lock hold time 0 wait time before grant 0
*** (2) TRANSACTION:
TRANSACTION 512587358, ACTIVE 0 sec fetching rows
mysql tables in use 3, locked 5
31 lock struct(s), heap size 6544, 15050 row lock(s)
MySQL thread id 8360, OS thread handle 0x7efd28157700, query id 946881408 172.19.0.1 nodeny Sending data
UPDATE ip_pool SET uid = NAME_CONST('user_id',812), `release` = UNIX_TIMESTAMP() + 300
WHERE id = (SELECT id FROM (
(SELECT id, uid FROM ip_pool
WHERE uid = 0
AND type = 'dynamic'
AND realip = IF( NAME_CONST('real_ip',NULL)>0,1,0)
LIMIT 1)
UNION
(SELECT id, uid FROM ip_pool
WHERE uid = NAME_CONST('user_id',812)
AND type = 'dynamic'
AND realip = IF( NAME_CONST('real_ip',NULL)>0,1,0)
LIMIT 1)
) AS tbl ORDER BY uid DESC LIMIT 1)
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 856 page no 11 n bits 440 index `PRIMARY` of table `nodeny`.`ip_pool` trx table locks 1 total table locks 2 trx id 512587358 lock_mode X locks rec but not gap lock hold time 0 wait time before grant 0
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 856 page no 11 n bits 440 index `PRIMARY` of table `nodeny`.`ip_pool` trx table locks 1 total table locks 2 trx id 512587358 lock_mode X waiting lock hold time 0 wait time before grant 0
*** WE ROLL BACK TRANSACTION (1)
------------
TRANSACTIONS
------------
Trx id counter 512620496
Purge done for trx's n:o < 512620495 undo n:o < 0 state: running but idle
History list length 41
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 3053566, OS thread handle 0x7efd0e60b700, query id 946945312 localhost 127.0.0.1 root init
show engine innodb STATUS
---TRANSACTION 0, not started
MySQL thread id 3053518, OS thread handle 0x7efd067f5700, query id 946938247 localhost 127.0.0.1 mailuser cleaning up
---TRANSACTION 512615340, not started
MySQL thread id 3036125, OS thread handle 0x7efd0c150700, query id 946935274 172.19.0.12 nodeny cleaning up
---TRANSACTION 512618190, not started
MySQL thread id 3036106, OS thread handle 0x7efd0c39c700, query id 946941130 172.19.0.12 nodeny cleaning up
---TRANSACTION 512609773, not started
MySQL thread id 3033913, OS thread handle 0x7efcfb36c700, query id 946923378 localhost zabbix cleaning up
---TRANSACTION 512615302, not started
MySQL thread id 3031967, OS thread handle 0x7efd16dc4700, query id 946935206 localhost zabbix cleaning up
---TRANSACTION 512620471, not started
MySQL thread id 3012801, OS thread handle 0x7efd658bd700, query id 946945250 localhost nodeny cleaning up
---TRANSACTION 512620361, not started
MySQL thread id 2991498, OS thread handle 0x7efd0c08c700, query id 946944952 localhost zabbix cleaning up
---TRANSACTION 512617219, not started
MySQL thread id 2991436, OS thread handle 0x7efd0e5da700, query id 946938582 localhost zabbix cleaning up
---TRANSACTION 512617316, not started
MySQL thread id 2942979, OS thread handle 0x7efd0c11f700, query id 946938806 172.19.0.12 nodeny cleaning up
---TRANSACTION 512615152, not started
MySQL thread id 2936489, OS thread handle 0x7efd06452700, query id 946934803 172.19.0.12 nodeny cleaning up
---TRANSACTION 512618467, not started
MySQL thread id 2925925, OS thread handle 0x7efd0e578700, query id 946941680 localhost zabbix cleaning up
---TRANSACTION 512620345, not started
MySQL thread id 2307611, OS thread handle 0x7efd67567700, query id 946945229 localhost nodeny cleaning up
---TRANSACTION 512612607, not started
MySQL thread id 2184255, OS thread handle 0x7efd0e63c700, query id 946929535 localhost zabbix cleaning up
---TRANSACTION 512600694, not started
MySQL thread id 2183835, OS thread handle 0x7efd16c9e700, query id 946905732 localhost zabbix cleaning up
---TRANSACTION 512620088, not started
MySQL thread id 2183808, OS thread handle 0x7efd0e483700, query id 946944200 localhost zabbix cleaning up
---TRANSACTION 512606531, not started
MySQL thread id 2183767, OS thread handle 0x7efd65ad8700, query id 946916906 localhost zabbix cleaning up
---TRANSACTION 512594797, not started
MySQL thread id 2183746, OS thread handle 0x7efd5adc7700, query id 946894513 localhost zabbix cleaning up
---TRANSACTION 512620358, not started
MySQL thread id 493646, OS thread handle 0x7efd67472700, query id 946944939 localhost zabbix cleaning up
---TRANSACTION 512041425, not started
MySQL thread id 493697, OS thread handle 0x7efd16f1b700, query id 946940708 localhost zabbix cleaning up
---TRANSACTION 512615449, not started
MySQL thread id 493639, OS thread handle 0x7efd65b9c700, query id 946936160 localhost zabbix cleaning up
---TRANSACTION 512620289, not started
MySQL thread id 493642, OS thread handle 0x7efd67505700, query id 946944749 localhost zabbix cleaning up
---TRANSACTION 512620421, not started
MySQL thread id 493641, OS thread handle 0x7efd16d00700, query id 946945113 localhost zabbix cleaning up
---TRANSACTION 512620464, not started
MySQL thread id 493640, OS thread handle 0x7efd16d62700, query id 946945233 localhost zabbix cleaning up
---TRANSACTION 512361987, not started
MySQL thread id 493647, OS thread handle 0x7efd65b3a700, query id 946945130 localhost zabbix cleaning up
---TRANSACTION 512036270, not started
MySQL thread id 493661, OS thread handle 0x7efd68440700, query id 946945195 localhost zabbix cleaning up
---TRANSACTION 512620057, not started
MySQL thread id 493657, OS thread handle 0x7efd6afec700, query id 946944120 localhost zabbix cleaning up
---TRANSACTION 512620420, not started
MySQL thread id 493644, OS thread handle 0x7efd16c6d700, query id 946945108 localhost zabbix cleaning up
---TRANSACTION 510058043, not started
MySQL thread id 493643, OS thread handle 0x7efd16d93700, query id 946945287 localhost zabbix cleaning up
---TRANSACTION 512620387, not started
MySQL thread id 8968, OS thread handle 0x7efd65a45700, query id 946945019 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620433, not started
MySQL thread id 8330, OS thread handle 0x7efd65a14700, query id 946945131 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620427, not started
MySQL thread id 8331, OS thread handle 0x7efd16df5700, query id 946945114 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620419, not started
MySQL thread id 8332, OS thread handle 0x7efd16fae700, query id 946945091 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620410, not started
MySQL thread id 8333, OS thread handle 0x7efd16eb9700, query id 946945072 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620404, not started
MySQL thread id 8334, OS thread handle 0x7efd659b2700, query id 946945055 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620398, not started
MySQL thread id 8335, OS thread handle 0x7efd16f4c700, query id 946945039 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620392, not started
MySQL thread id 8336, OS thread handle 0x7efd16eea700, query id 946945020 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620385, not started
MySQL thread id 8337, OS thread handle 0x7efd65a76700, query id 946945002 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620379, not started
MySQL thread id 8338, OS thread handle 0x7efd16e57700, query id 946944986 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620373, not started
MySQL thread id 8339, OS thread handle 0x7efd280c4700, query id 946944970 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620367, not started
MySQL thread id 8340, OS thread handle 0x7efd16f7d700, query id 946944953 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620357, not started
MySQL thread id 8341, OS thread handle 0x7efd65b09700, query id 946944920 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620351, not started
MySQL thread id 8342, OS thread handle 0x7efd28126700, query id 946944904 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620343, not started
MySQL thread id 8343, OS thread handle 0x7efd28062700, query id 946944881 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620337, not started
MySQL thread id 8344, OS thread handle 0x7efd6585b700, query id 946944864 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620336, not started
MySQL thread id 8345, OS thread handle 0x7efd5ad34700, query id 946944849 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620325, not started
MySQL thread id 8346, OS thread handle 0x7efd65b6b700, query id 946944833 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620319, not started
MySQL thread id 8347, OS thread handle 0x7efd5adf8700, query id 946944817 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620313, not started
MySQL thread id 8348, OS thread handle 0x7efd5ad96700, query id 946944801 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620307, not started
MySQL thread id 8349, OS thread handle 0x7efd5acd2700, query id 946944783 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620301, not started
MySQL thread id 8350, OS thread handle 0x7efd16fdf700, query id 946944767 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620295, not started
MySQL thread id 8351, OS thread handle 0x7efd5ac3f700, query id 946944750 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620288, not started
MySQL thread id 8352, OS thread handle 0x7efd280f5700, query id 946944729 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620495, not started
MySQL thread id 8353, OS thread handle 0x7efd5aca1700, query id 946945288 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620488, not started
MySQL thread id 8354, OS thread handle 0x7efd5ad65700, query id 946945267 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620479, not started
MySQL thread id 8355, OS thread handle 0x7efd28031700, query id 946945251 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620470, not started
MySQL thread id 8356, OS thread handle 0x7efd5ac70700, query id 946945234 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620463, not started
MySQL thread id 8357, OS thread handle 0x7efd6588c700, query id 946945212 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620457, not started
MySQL thread id 8358, OS thread handle 0x7efd6591f700, query id 946945196 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620451, not started
MySQL thread id 8359, OS thread handle 0x7efd5ad03700, query id 946945179 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620445, not started
MySQL thread id 8360, OS thread handle 0x7efd28157700, query id 946945163 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620439, not started
MySQL thread id 8361, OS thread handle 0x7efd659e3700, query id 946945147 172.19.0.1 nodeny cleaning up
---TRANSACTION 512620344, not started
MySQL thread id 8232, OS thread handle 0x7efd16e26700, query id 946944899 localhost nodeny cleaning up
---TRANSACTION 7548675, not started
MySQL thread id 1, OS thread handle 0x7efd6b07f700, query id 0 Waiting for requests
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
43077 OS file reads, 188349493 OS file writes, 176845559 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 11.14 writes/s, 10.28 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 3, seg size 5, 604 merges
merged operations:
insert 435, delete mark 420, delete 173
discarded operations:
insert 0, delete mark 0, delete 0
2284.96 hash searches/s, 122.70 non-hash searches/s
ссори не досмотрел, вам поможет то что описано в начале темы
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 05 Февраля 2018, 21:03:14
вам поможет то что описано в начале темы При обновлении оно само добавится или нужно в ручную процедуры менять? С другой стороны, почему бы не применить новые процедуры, которые работают лучше чем предыдущие ? Совершенно верно ;) Смотрю там измененная процедура get_ip. А если у меня используется get_ip_by_tag? ::)
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Warlock от 05 Февраля 2018, 21:33:15
вам поможет то что описано в начале темы При обновлении оно само добавится или нужно в ручную процедуры менять? С другой стороны, почему бы не применить новые процедуры, которые работают лучше чем предыдущие ? Совершенно верно ;) Смотрю там измененная процедура get_ip. А если у меня используется get_ip_by_tag? ::) В процедуре только время увеличнно с 300 до 3600, хотя ее можно и не менее ять. А функцию руками создать.. perl install.pl -x тебе напомнит об этом
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: NoDeny support от 05 Февраля 2018, 21:38:16
вам поможет то что описано в начале темы При обновлении оно само добавится или нужно в ручную процедуры менять? С другой стороны, почему бы не применить новые процедуры, которые работают лучше чем предыдущие ? Совершенно верно ;) Смотрю там измененная процедура get_ip. А если у меня используется get_ip_by_tag? ::) то вам сюда http://nodeny.com.ua/wiki/index.php/%D0%92%D1%8B%D0%B4%D0%B0%D1%87%D0%B0_ip_%D0%B2_%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8%D0%BC%D0%BE%D1%81%D1%82%D0%B8_%D0%BE%D1%82_%D1%82%D0%BE%D0%B3%D0%BE,_%D0%BA_%D0%BA%D0%B0%D0%BA%D0%BE%D0%BC%D1%83_NAS_%D0%BF%D0%BE%D0%B4%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD_%D0%B0%D0%B1%D0%BE%D0%BD%D0%B5%D0%BD%D1%82
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Sidius от 14 Февраля 2018, 17:11:17
Время от времени я вижу жалобы на то, что бывают разного рода глюки с выдачей динамических ip. Я тут хорошо покрутил все и кажется понял в чем проблема. На самом деле основные проблемы 2:
Правда чтоле? ))))) А когда я несколько лет назад писал что есть проблемы с динамической выдачей ИП меня все называли рукожопым оленем.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 26 Февраля 2018, 12:23:25
Стас помоги разобраться. На новом брасе ловлю дубликаты ip, все изменения наложены из данной темы. Для выдачи используется get_ip_by_tag из wiki.
На брасе есть dhcp и pppoe, соответственно есть две radreply, radupdate, radcheck в которых вызывается get_ip_by_tag.
Так вот есть проблема, звонит клиент по pppoe говорит не работает, смотрю его ip, который светится в его учетке, пробиваю кому он еще может выдан и вижу что выдан по dhcp пока непривязанному клиенту, может быть и другие есть варианты когда выдается дубликат, но пока только такой увидел.
Или когда по dhcp выдает ip не привязанному клиенту, ip не фиксируется как занятый и выдается повторно? Как правильно тогда организовать выдачу ip по логике системы?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 26 Февраля 2018, 17:09:22
Стас помоги разобраться. На новом брасе ловлю дубликаты ip, все изменения наложены из данной темы. Для выдачи используется get_ip_by_tag из wiki.
На брасе есть dhcp и pppoe, соответственно есть две radreply, radupdate, radcheck в которых вызывается get_ip_by_tag.
Так вот есть проблема, звонит клиент по pppoe говорит не работает, смотрю его ip, который светится в его учетке, пробиваю кому он еще может выдан и вижу что выдан по dhcp пока непривязанному клиенту, может быть и другие есть варианты когда выдается дубликат, но пока только такой увидел.
Или когда по dhcp выдает ip не привязанному клиенту, ip не фиксируется как занятый и выдается повторно? Как правильно тогда организовать выдачу ip по логике системы?
У тебя пулы с тегами созданы в биллинге ? И лучше создай свою тему, чтоб эту не захламлять, у тебя вероятней всего частный случай. Процедуры у тебя какие ? Те что Стас указал в соседней теме или твои ? PS: И это у тебя не дубликаты, а левые айпи выдаются абонентам. Дубликаты - это когда один айпи выдан двоим абонентам.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 26 Февраля 2018, 17:24:41
Да у меня один большой динамический пул с тегом под данный брас.
Процедуры по выдаче ip у меня стандартные, с поставки и вики.
Как это не дубликаты? Есть две разные сессии на брасе у которых один ip. Биллинг их же выдал не я самостоятельно присвоил.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 26 Февраля 2018, 18:28:31
Да у меня один большой динамический пул с тегом под данный брас.
Процедуры по выдаче ip у меня стандартные, с поставки и вики.
Как это не дубликаты? Есть две разные сессии на брасе у которых один ip. Биллинг их же выдал не я самостоятельно присвоил.
Уточняю, когда двум пппое абонентам выдан один айпи. Создай разные пулы, для пппое и дхцп абонентов. Покажи какие процедуры используешь.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 26 Февраля 2018, 18:35:23
Какую именно показать тебе?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 26 Февраля 2018, 18:44:25
Какую именно показать тебе?
Все. И это не только мне. У меня теги тоже есть, но еще на третем не обкатывал.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 26 Февраля 2018, 19:04:14
DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `radcheck_ipoe`(IN login VARCHAR(64))
BEGIN
SELECT Null, login, 'Cleartext-Password' AS Attribute, '' AS Value,':=';
END$$
DELIMITER ; DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `radcheck_pppoe`(IN login VARCHAR(64))
BEGIN
SELECT id,name,'Cleartext-Password' AS Attribute,AES_DECRYPT(passwd,'LroCmnvGELVXn2Vj') AS Value,':='
FROM users WHERE name=login;
END$$
DELIMITER ; DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `radreply_ipoe`(IN `login` VARCHAR(64), IN `tag` VARCHAR(64))
BEGIN
DECLARE rad_mac VARCHAR(12);
DECLARE rad_dev_mac VARCHAR(12);
DECLARE rad_port VARCHAR(12);
DECLARE usr_id INT;
DECLARE usr_ip VARCHAR(15);
DECLARE usr_onecon INT;
DECLARE usr_onedev INT;
SELECT SUBSTRING_INDEX(login, '-', 1) INTO rad_mac;
SELECT SUBSTRING_INDEX(login, '-', -1) INTO rad_port;
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(login, '-', 2), '-', -1) INTO rad_dev_mac;
SELECT uid, oneconnect, onedevice INTO usr_id, usr_onecon, usr_onedev FROM mac_uid
WHERE device_mac=rad_dev_mac
AND (device_port=rad_port OR (onedevice>0 AND device_mac<>''))
AND (mac=rad_mac OR (oneconnect>0 AND device_mac<>''))
LIMIT 1;
IF usr_id IS NOT NULL AND usr_id > 0 THEN
SELECT get_ip_by_tag(usr_id, tag) INTO usr_ip;
UPDATE mac_uid SET ip=0 WHERE ip=INET_ATON(usr_ip) AND uid<>usr_id;
UPDATE mac_uid SET ip=INET_ATON(usr_ip), time=UNIX_TIMESTAMP() WHERE uid=usr_id;
IF usr_onecon > 0 OR usr_onedev > 0 THEN
UPDATE mac_uid SET mac=NULL WHERE mac=rad_mac AND (oneconnect=0 OR onedevice=0);
UPDATE mac_uid SET mac=rad_mac, device_port=rad_port WHERE device_mac=rad_dev_mac
AND (onedevice>0 OR (device_port=rad_port AND oneconnect>0));
END IF;
ELSE
UPDATE mac_uid SET ip=0 WHERE uid=0 AND time<(UNIX_TIMESTAMP()-3600);
UPDATE mac_uid SET mac=NULL WHERE mac=rad_mac AND (oneconnect>0 OR onedevice>0);
START TRANSACTION;
SELECT INET_NTOA(ip) INTO usr_ip FROM ip_pool p WHERE uid=0 AND type='dynamic'
AND tags LIKE CONCAT('%,', tag ,',%')
AND NOT EXISTS (SELECT ip FROM mac_uid WHERE ip=p.ip)
ORDER BY RAND() LIMIT 1 FOR UPDATE;
INSERT INTO mac_uid VALUES(
NULL, rad_mac, INET_ATON(usr_ip), 0, UNIX_TIMESTAMP(), rad_dev_mac, rad_port, 0, 0)
ON DUPLICATE KEY
UPDATE ip=IF(ip>0 AND device_mac=rad_dev_mac AND device_port=rad_port, ip, INET_ATON(usr_ip)),
uid=0, device_mac=rad_dev_mac, device_port=rad_port, time=UNIX_TIMESTAMP();
COMMIT;
SELECT INET_NTOA(ip) INTO usr_ip FROM mac_uid
WHERE mac=rad_mac AND device_mac=rad_dev_mac AND device_port=rad_port;
END IF;
SELECT NULL, login, 'Framed-IP-Address', usr_ip, '=';
END$$
DELIMITER ; DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `radreply_pppoe`(IN `login` VARCHAR(64), IN `tag` VARCHAR(64))
BEGIN
DECLARE usr_id INT;
DECLARE usr_ip VARCHAR(15) DEFAULT NULL;
SELECT id INTO usr_id FROM users WHERE name=login LIMIT 1;
SELECT get_ip_by_tag(usr_id, tag) INTO usr_ip;
SELECT NULL,login,'Framed-IP-Address',usr_ip,'=';
SELECT NULL,login,'Framed-IP-Netmask','255.255.255.255','=';
SELECT NULL,login,'Framed-Protocol','PPP','=';
END$$
DELIMITER ; DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `radupdate_ipoe`(IN `login` VARCHAR(64), IN `ipa` VARCHAR(16),
IN `properties` VARCHAR(255), IN `tag` VARCHAR(64), IN `ses` VARCHAR(64))
BEGIN
DECLARE rad_mac VARCHAR(12);
DECLARE rad_dev_mac VARCHAR(12);
DECLARE rad_port VARCHAR(12);
DECLARE usr_id INT;
DECLARE usr_ip VARCHAR(15);
SELECT SUBSTRING_INDEX(login, '-', 1) INTO rad_mac;
SELECT SUBSTRING_INDEX(login, '-', -1) INTO rad_port;
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(login, '-', 2), '-', -1) INTO rad_dev_mac;
SELECT uid INTO usr_id FROM mac_uid WHERE device_mac=rad_dev_mac
AND (device_port=rad_port OR (onedevice>0 AND device_mac<>''))
AND (mac=rad_mac OR (oneconnect>0 AND device_mac<>''))
LIMIT 1;
IF usr_id IS NULL THEN
SELECT ipa INTO usr_ip;
ELSE
SELECT get_ip_by_tag(usr_id, tag) INTO usr_ip;
END IF;
CALL set_auth(usr_ip, CONCAT('mod=dhcp;user=', rad_mac, ';', 'dev=', rad_dev_mac, ';', 'port=', rad_port, ';',
'ses=', ses, ';', REPLACE(properties,':','')));
UPDATE mac_uid SET time=UNIX_TIMESTAMP() WHERE ip=INET_ATON(ipa) LIMIT 1;
END$$
DELIMITER ; DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `radupdate_pppoe`(IN `login` VARCHAR(64), IN `ip` VARCHAR(16), IN `properties` VARCHAR(255), IN `tag` VARCHAR(64), IN `ses` VARCHAR(64))
BEGIN
DECLARE usr_id INT;
DECLARE usr_ip VARCHAR(15) DEFAULT NULL;
SELECT id INTO usr_id FROM users WHERE name=login LIMIT 1;
SELECT get_ip_by_tag(usr_id, tag) INTO usr_ip;
CALL set_auth(usr_ip, CONCAT('mod=pppoe;','ses=',ses,';',REPLACE(properties,':','')));
END$$
DELIMITER ; DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `set_auth`(IN `usr_ip` VARCHAR(15), IN `auth_properties` VARCHAR(255))
BEGIN
DECLARE usr_id INT;
SELECT uid INTO usr_id FROM ip_pool WHERE INET_ATON(usr_ip) = ip LIMIT 1;
IF( usr_id > 0 ) THEN
INSERT INTO auth_now SET
ip = usr_ip,
properties = auth_properties,
start = UNIX_TIMESTAMP(),
last = UNIX_TIMESTAMP()
ON DUPLICATE KEY UPDATE
properties = IF(auth_properties!='',auth_properties,properties),
last = UNIX_TIMESTAMP();
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
WHERE ip = INET_ATON(usr_ip) LIMIT 1;
END IF;
END$$
DELIMITER ; DELIMITER $$
CREATE DEFINER=`nodeny`@`%` FUNCTION `get_ip_by_tag`( user_id INTEGER UNSIGNED, tag VARCHAR(64) ) RETURNS varchar(15) CHARSET utf8
NO SQL
BEGIN
DECLARE user_ip VARCHAR(15);
DECLARE real_ip VARCHAR(15) DEFAULT 0;
DECLARE row_cnt INTEGER;
DECLARE ip_id INTEGER;
DECLARE tries INTEGER DEFAULT 30;
DECLARE id_min INTEGER;
DECLARE id_max INTEGER;
SELECT INET_NTOA(ip) INTO user_ip FROM ip_pool
WHERE uid = user_id AND type='static' LIMIT 1;
IF( user_ip IS NOT NULL ) THEN RETURN user_ip; END IF;
SELECT 1 INTO real_ip FROM users_services WHERE uid = user_id AND tags LIKE '%,realip,%';
SELECT id, INET_NTOA(ip) INTO ip_id, user_ip FROM ip_pool
WHERE uid = user_id AND type = 'dynamic' AND realip = IF(real_ip>0,1,0)
AND tags LIKE CONCAT('%,', tag, ',%')
LIMIT 1;
IF( ip_id IS NOT NULL) THEN
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
WHERE id = ip_id AND uid = user_id;
SELECT ROW_COUNT() INTO row_cnt;
IF( row_cnt > 0 ) THEN RETURN user_ip; END IF;
END IF;
SELECT MAX(id), MIN(id) INTO id_max, id_min
FROM ip_pool
WHERE type = 'dynamic' AND realip = IF(real_ip>0,1,0)
AND tags LIKE CONCAT('%,', tag, ',%');
sel_ip: WHILE tries > 0 DO
SELECT id, INET_NTOA(ip) INTO ip_id, user_ip
FROM ip_pool
WHERE uid = 0
AND id >= (CEIL(RAND() * (id_max - id_min)) + id_min)
AND id <= id_max
LIMIT 1;
IF( user_ip IS NOT NULL) THEN
UPDATE ip_pool SET uid = user_id, `release` = UNIX_TIMESTAMP() + 3600
WHERE id = ip_id AND uid = 0;
SELECT ROW_COUNT() INTO row_cnt;
IF( row_cnt > 0 ) THEN RETURN user_ip; END IF;
SET tries = tries - 5;
END IF;
SET tries = tries - 1;
END WHILE;
END$$
DELIMITER ; DELIMITER $$
CREATE DEFINER=`nodeny`@`%` FUNCTION `normalize_ippool`() RETURNS tinyint(4)
NO SQL
BEGIN
DECLARE mid INTEGER UNSIGNED;
CREATE TEMPORARY TABLE temp_ip_pool(
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
ip_id BIGINT UNSIGNED NOT NULL,
PRIMARY KEY (id)
);
SELECT MAX(id) into mid FROM ip_pool;
UPDATE ip_pool SET id = id + mid;
INSERT temp_ip_pool (SELECT NULL, id FROM ip_pool ORDER BY realip, type, tags);
UPDATE ip_pool i JOIN temp_ip_pool t ON i.id = t.ip_id SET i.id = t.id;
DROP TEMPORARY TABLE IF EXISTS temp_ip_pool;
RETURN 1;
END$$
DELIMITER ;
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 26 Февраля 2018, 21:29:08
Трудно так сразу сказать где проблема. Тебе нужно сделать предварительное расследование. Взять конкретный случай и проанализировать ситуацию по логам и биллинга и радуиуса и т.д.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 26 Февраля 2018, 21:55:02
в процедурах у меня мало опыта, но вижу что похоже ты пошел своим путем с процедурами. По крайней мере с `radupdate_pppoe` как советовал Стас, ты не сделал, а решил другим путем. В соседней теме, после удаления одного параметра, у меня выдавался левый айпи абоненту, хотя в админке показывало онлайн и статику. Какие еще могут быть глюки, учитывая что у тебя достаточно навернуто, неизвестно. Сделал бы на стенде, процедуры из документации без тегов, с добавлением параметра для корректной работы "статики" пппое. Добавил тег, дальше пошагово изменяя под себя процедуры. И смотреть на чем начинаются глюки. Можно конечно и с текущими пытаться разбираться, если абонов не жалко. :)
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 27 Февраля 2018, 13:23:39
Кажется я понял в чем проблема. Судя по логике биллинга, при выдаче ip, get_ip_by_tag и не только ориентируется на занятость ip по uid=0, если равно 0 то Ip свободен и это работало и работает с pppoe и другими тоннелями когда ip выдается исключительно клиенту в базе. И тут приходит dhcp через radius. Создавая логику авторизации клиента по dhcp мы понимаем что теперь нужно всем отвечать ACCEPT и выдавать ip с пула, чтобы в дальнейшем клиент мог авторизовать свое подключение и привязаться к учетной записи самостоятельно. И тут всплывает один нюанс. Вызывая radreply_ipoe IF usr_id IS NOT NULL AND usr_id > 0 ELSE Мы тупо берем и выдаем ip у кого uid=0 и даже не помечаем, никак что мы его выдали. SELECT INET_NTOA(ip) INTO usr_ip FROM ip_pool p WHERE uid=0 AND type='dynamic'
AND tags LIKE CONCAT('%,', tag ,',%')
AND NOT EXISTS (SELECT ip FROM mac_uid WHERE ip=p.ip)
ORDER BY RAND() LIMIT 1 FOR UPDATE; В get_ip_by_Tag примерно так же происходит выборка по uid=0 Это не создаст больших проблем, если клиент следом авторизует свое подключение но имеется много случаев когда ip выдается просто на устройство которое не авторизуется долгое время и тупо весит, допустим на сетевую карту компьютера на котором пока используется pppoe. И даже если создать отдельный пул в биллинге для вот таких гостевых подключений, они все так же не будут фиксироваться что выдавались какому-то устройству и будет вероятность что уже выданный Ip снова кто-то получит. Как по мне, то нужно менять логику выдачи ip и фиксировать выданные как-то по другому но не uid<>0, в связи с тем что ppp на сегодняшний день становится не единственным типом подключения. Так оно и получается у меня на сегодняшний момент, я фиксирую дубликаты как раз у не авторизованных устройств и клиентов. Дубликатов у двух клиентов я не встречал пока. По крайней мере с `radupdate_pppoe` как советовал Стас, ты не сделал, а решил другим путем. Напомни как он советовал.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 27 Февраля 2018, 15:34:57
Напомни как он советовал.
Взять процедуры дхцп и пппое из мануала и добавить в пппое строку UPDATE users SET id=usr_id WHERE id=usr_id LIMIT 1;DROP PROCEDURE IF EXISTS `radupdate`;
DELIMITER $$
CREATE PROCEDURE `radupdate`(IN login VARCHAR(64), IN ip VARCHAR(16), IN properties VARCHAR(255))
BEGIN
DECLARE usr_id INT;
DECLARE usr_ip VARCHAR(15) DEFAULT NULL;
SELECT id INTO usr_id FROM users WHERE name=login LIMIT 1;
SELECT get_ip(usr_id) INTO usr_ip;
CALL set_auth(usr_ip, CONCAT('mod=pppoe;',REPLACE(properties,':','')));
UPDATE users SET id=usr_id WHERE id=usr_id LIMIT 1;
END$$
DELIMITER ; Так оно и получается у меня на сегодняшний момент, я фиксирую дубликаты как раз у не авторизованных устройств и клиентов. Дубликатов у двух клиентов я не встречал пока. Вот, поэтому у тебя и не "дубли". :) У меня у авторизованных абонентов дубли были, до решения описанного в первых постах в теме. У меня пулы, для дхцп и пппое разные, описанных тобой проблем, пока не наблюдал. Как по мне, то нужно менять логику выдачи ip и фиксировать выданные как-то по другому но не uid<>0, в связи с тем что ppp на сегодняшний день становится не единственным типом подключения. Может не менять логику а просто сделать два разных пула ? И тогда дхцп сервер, не сможет выдать айпи который уже выдан пппое или не авторизованному абоненту. Не припомню такого, чтоб дхцп сервер, выдавал одинаковые айпи двум разным абонентам. Не твой вариант ? h t t p://forum.nodeny.com.ua/index.php?topic=2441.msg24632#msg24632 Суть в чем - апдейтим авторизацию по фактическому ip-адресу сессии клиента, а не по выборке из get_ip
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 27 Февраля 2018, 19:37:07
UPDATE users SET id=usr_id WHERE id=usr_id LIMIT 1; это бессмысленный запрос, я по другому поступил. У меня пулы, для дхцп и пппое разные, описанных тобой проблем, пока не наблюдал. dhcp у тебя надеюсь через radius? Может не менять логику а просто сделать два разных пула ? И тогда дхцп сервер, не сможет выдать айпи который уже выдан пппое или не авторизованному абоненту. Ты пойми дело не в пулах, даже если создам отдельный для dhcp пул все равно будет вероятность что ip получит кто-то другой с этого же пула, так как когда ip выдается гостю, то в ip_pool это никак не фиксируется.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 28 Февраля 2018, 06:43:00
Не фиксируется в ip_pool, зато фиксируется в mac_uid, что данная комбинация параметров авторизации уже связана с таким-то ip. Но при беглом вгляде, ты этот код просто выкинул из процедуры
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 28 Февраля 2018, 12:33:12
Ничего не выкинуто. Я так понимаю ты об этом говоришь? это есть в radreply SELECT INET_NTOA(ip) INTO usr_ip FROM ip_pool p WHERE uid=0 AND type='dynamic'
AND tags LIKE CONCAT('%,', tag ,',%')
AND NOT EXISTS (SELECT ip FROM mac_uid WHERE ip=p.ip)
ORDER BY RAND() LIMIT 1 FOR UPDATE; AND NOT EXISTS (SELECT ip FROM mac_uid WHERE ip=p.ip) это выполняется если usr_id = 0 если uid > 0 вызывается get_ip_by_tag в которой скорей всего так же нужно добавить эту проверку, что-то типа sel_ip: WHILE tries > 0 DO
SELECT id, INET_NTOA(ip) INTO ip_id, user_ip
FROM ip_pool
WHERE uid = 0
AND id >= (CEIL(RAND() * (id_max - id_min)) + id_min)
AND id <= id_max
AND NOT EXISTS (SELECT ip FROM mac_uid WHERE ip=p.ip)
LIMIT 1; Но тут возникает другой вопрос, кто очищает ip в mac_uid по истечению авторизации и срока аренды?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 28 Февраля 2018, 13:40:26
Но тут возникает другой вопрос, кто очищает ip в mac_uid по истечению авторизации и срока аренды?
В radreply: UPDATE mac_uid SET ip=0 WHERE uid=0 AND time<(UNIX_TIMESTAMP()-3600); Кстати, в этом может и быть проблема ибо при аккаунтинге вызывает только set_auth и там не модифицируется время в mac_uid, ну или это делать в radreply непосредственно
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 28 Февраля 2018, 13:59:15
Так что добавлять
AND NOT EXISTS (SELECT ip FROM mac_uid WHERE ip=p.ip)
В get_ip_by_tag?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 28 Февраля 2018, 15:19:25
Невнимательно читаешь. У нас есть таблица mac_uid, которая выполняет 2 функции: 1) хранит связки мак = id абона (в данном случае проблема не в этом варианте) 2) хранит связки ip = время, когда мы последний раз проверяли, что данный ip был кому-то выдан Т.е. работает так: неизвестный абон подсоединился, мы выдали ему любой свободный ip, при этом запомнили в mac_uid, что данный ip уже выдан. При этом установили время. Теперь следующий неизвестный абон подконнектился и мы выбираем свободный ip из ip_pool, но при этом проверяем, что в mac_uid нет этого ip. Схема рабочая? Нет. Потому, что у нас рано или поздно закончатся все ip, потому что они все попадут в mac_uid. Поэтому в процедуре radreply у нас проиcходит удаление таких ip: UPDATE mac_uid SET ip=0 WHERE uid=0 AND time<(UNIX_TIMESTAMP()-3600) Другими словами мы стерли ip (вместо него записали 0) у которого время попадания в таблицу mac_uid было больше часа назад. А если неизвестный абон висит не час, а сутки? Хреново: ибо ip через час исчезнет из mac_uid, а по сути им занят. Поэтому не хватает малости: при каждом аккаунтинге неизвестного абона нужно поле time устанавливать в текущее время
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 28 Февраля 2018, 19:10:04
Стас! Со всем последним тобою сказанным согласен! И обновление time так же происходит в radupdate DELIMITER $$
CREATE DEFINER=`nodeny`@`%` PROCEDURE `radupdate_ipoe`(IN `login` VARCHAR(64), IN `ipa` VARCHAR(16),
IN `properties` VARCHAR(255), IN `tag` VARCHAR(64), IN `ses` VARCHAR(64))
BEGIN
DECLARE rad_mac VARCHAR(12);
DECLARE rad_dev_mac VARCHAR(12);
DECLARE rad_port VARCHAR(12);
DECLARE usr_id INT;
DECLARE usr_ip VARCHAR(15);
SELECT SUBSTRING_INDEX(login, '-', 1) INTO rad_mac;
SELECT SUBSTRING_INDEX(login, '-', -1) INTO rad_port;
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(login, '-', 2), '-', -1) INTO rad_dev_mac;
SELECT uid INTO usr_id FROM mac_uid WHERE device_mac=rad_dev_mac
AND (device_port=rad_port OR (onedevice>0 AND device_mac<>''))
AND (mac=rad_mac OR (oneconnect>0 AND device_mac<>''))
LIMIT 1;
IF usr_id IS NULL THEN
SELECT ipa INTO usr_ip;
ELSE
SELECT get_ip_by_tag(usr_id, tag) INTO usr_ip;
END IF;
CALL set_auth(usr_ip, CONCAT('mod=dhcp;user=', rad_mac, ';', 'dev=', rad_dev_mac, ';', 'port=', rad_port, ';',
'ses=', ses, ';', REPLACE(properties,':','')));
UPDATE mac_uid SET time=UNIX_TIMESTAMP() WHERE ip=INET_ATON(ipa) LIMIT 1;
END$$
DELIMITER ; НОПодключается наш клиент, не гость и у него динамика и ip уже его освободился который был в предыдущей сессии и тут он запрашивает новый ip с пула. Что происходит? Вызывается get_ip_by_tag в котором происходит выборка свободного ip, без проверки что в mac_uid нет этого ip и тут появляется вероятность что вполне законный клиент может получить ip который есть уже в mac_uid у гостя и при выдаче гостю этот ip никак не по метился в ip_pools Потом, запросов radreply от гостей в какой-то момент может не быть, следовательно Ip по таймауту не сброситься, как по мне правильней бы, этот вызов вынести допустим в модуль ядра dhcp UPDATE mac_uid SET ip=0 WHERE uid=0 AND time<(UNIX_TIMESTAMP()-3600);
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 28 Февраля 2018, 22:47:41
Возможно ты прав, надо глянуть учел ли я это в предыдущих версиях процедур. А насчет обнуления ip в mac_uid. Тут смысл не в том, чтоб он был освобожден четко во время, а смысл в том, чтобы всегда хватало свободных ip перед тем как ip запросит подключившийся
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: elite от 28 Февраля 2018, 23:52:13
Кажется я понял в чем проблема.
Судя по логике биллинга, при выдаче ip, get_ip_by_tag и не только ориентируется на занятость ip по uid=0, если равно 0 то Ip свободен и это работало и работает с pppoe и другими тоннелями когда ip выдается исключительно клиенту в базе.
И тут приходит dhcp через radius. Создавая логику авторизации клиента по dhcp мы понимаем что теперь нужно всем отвечать ACCEPT и выдавать ip с пула, чтобы в дальнейшем клиент мог авторизовать свое подключение и привязаться к учетной записи самостоятельно. И тут всплывает один нюанс.
если клиента нет в бд, отвечает accept, но вместо framed ip выдавай framed pool, чтобы accel выдавал сам гостевой ип из своего пула
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 01 Марта 2018, 10:06:01
Не. Тогда нужен будет реконнект после того как абон зарегается. Я думаю, можно будет подправить процедуры, чтобы у выданного гостю ip в пуле устанавливалось поле release. Сегодня потестирую и напишу.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 01 Марта 2018, 10:16:31
если клиента нет в бд, отвечает accept, но вместо framed ip выдавай framed pool, чтобы accel выдавал сам гостевой ип из своего пула Да почитал вики accel можно сгородить гостевой пул у него по Framed-Pool. Но хотелось бы рулить ip с биллинга. Тут смысл не в том, чтоб он был освобожден четко во время, а смысл в том, чтобы всегда хватало свободных ip перед тем как ip запросит подключившийся А ну да, т.е. возможно не сразу они очистятся главное что бы был запас но с этим проблем нет, у меня выдаются в динамике серые. Не. Тогда нужен будет реконнект после того как абон зарегается. Я думаю, можно будет подправить процедуры, чтобы у выданного гостю ip в пуле устанавливалось поле release. Сегодня потестирую и напишу. Из-за реконнекта и не хочется городить отдельный пул для гостей, это доп нагрузка сразу вылезет по звонкам тп. Жду Стас.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 01 Марта 2018, 14:20:43
DROP FUNCTION IF EXISTS `get_ip_by_tag`;
DELIMITER $$
CREATE FUNCTION `get_ip_by_tag`( user_id INTEGER UNSIGNED, tag VARCHAR(64) )
RETURNS VARCHAR(15) NO SQL
BEGIN
DECLARE user_ip VARCHAR(15);
DECLARE real_ip VARCHAR(15) DEFAULT 0;
DECLARE row_cnt INTEGER;
DECLARE ip_id INTEGER;
DECLARE tries INTEGER DEFAULT 30;
DECLARE id_min INTEGER;
DECLARE id_max INTEGER;
SELECT INET_NTOA(ip) INTO user_ip FROM ip_pool
WHERE uid = user_id AND type='static' LIMIT 1;
IF( user_ip IS NOT NULL ) THEN RETURN user_ip; END IF;
SELECT 1 INTO real_ip FROM users_services WHERE uid = user_id AND tags LIKE '%,realip,%';
SELECT id, INET_NTOA(ip) INTO ip_id, user_ip FROM ip_pool
WHERE uid = user_id AND type = 'dynamic' AND realip = IF(real_ip>0,1,0)
AND tags LIKE CONCAT('%,', tag, ',%')
LIMIT 1;
IF( ip_id IS NOT NULL) THEN
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
WHERE id = ip_id AND uid = user_id;
SELECT ROW_COUNT() INTO row_cnt;
IF( row_cnt > 0 ) THEN RETURN user_ip; END IF;
END IF;
SELECT MAX(id), MIN(id) INTO id_max, id_min
FROM ip_pool
WHERE type = 'dynamic' AND realip = IF(real_ip>0,1,0)
AND tags LIKE CONCAT('%,', tag, ',%');
sel_ip: WHILE tries > 0 DO
SELECT id, INET_NTOA(ip) INTO ip_id, user_ip
FROM ip_pool
WHERE uid = 0
AND id >= (CEIL(RAND() * (id_max - id_min)) + id_min)
AND id <= id_max
AND `release` < UNIX_TIMESTAMP()
AND tags LIKE CONCAT('%,', tag, ',%')
LIMIT 1;
IF( user_ip IS NOT NULL) THEN
UPDATE ip_pool SET uid = user_id, `release` = UNIX_TIMESTAMP() + 3600
WHERE id = ip_id AND uid = 0 AND `release` < UNIX_TIMESTAMP();
SELECT ROW_COUNT() INTO row_cnt;
IF( row_cnt > 0 ) THEN RETURN user_ip; END IF;
SET tries = tries - 5;
END IF;
SET tries = tries - 1;
END WHILE;
END$$
DELIMITER ;
DROP PROCEDURE IF EXISTS `radreply_ipoe`;
DELIMITER $$
CREATE PROCEDURE `radreply_ipoe`(IN `login` VARCHAR(64), IN `tag` VARCHAR(64))
BEGIN
DECLARE rad_mac VARCHAR(12);
DECLARE rad_dev_mac VARCHAR(12);
DECLARE rad_port VARCHAR(12);
DECLARE usr_id INT;
DECLARE usr_ip VARCHAR(15);
DECLARE usr_onecon INT;
DECLARE usr_onedev INT;
SELECT SUBSTRING_INDEX(login, '-', 1) INTO rad_mac;
SELECT SUBSTRING_INDEX(login, '-', -1) INTO rad_port;
SELECT SUBSTRING_INDEX(SUBSTRING_INDEX(login, '-', 2), '-', -1) INTO rad_dev_mac;
SELECT uid, oneconnect INTO usr_id, usr_onecon FROM mac_uid
WHERE device_mac=rad_dev_mac
AND device_port=rad_port
AND (mac=rad_mac OR (oneconnect>0 AND device_mac<>''))
LIMIT 1;
IF usr_id IS NOT NULL AND usr_id > 0 THEN
SELECT get_ip_by_tag(usr_id, tag) INTO usr_ip;
UPDATE mac_uid SET ip=0 WHERE ip=INET_ATON(usr_ip) AND uid<>usr_id;
UPDATE mac_uid SET ip=INET_ATON(usr_ip), time=UNIX_TIMESTAMP() WHERE uid=usr_id;
IF usr_onecon > 0 OR usr_onedev > 0 THEN
UPDATE mac_uid SET mac=NULL WHERE mac=rad_mac AND oneconnect=0;
UPDATE mac_uid SET mac=rad_mac, device_port=rad_port WHERE device_mac=rad_dev_mac
AND (device_port=rad_port AND oneconnect>0);
END IF;
ELSE
UPDATE mac_uid SET mac=NULL WHERE mac=rad_mac AND oneconnect>0;
START TRANSACTION;
SELECT INET_NTOA(ip) INTO usr_ip FROM ip_pool
WHERE uid=0 AND type='dynamic'
AND tags LIKE CONCAT('%,', tag ,',%')
AND `release` < UNIX_TIMESTAMP()
ORDER BY RAND() LIMIT 1 FOR UPDATE;
INSERT INTO mac_uid VALUES(
NULL, rad_mac, INET_ATON(usr_ip), 0, UNIX_TIMESTAMP(), rad_dev_mac, rad_port, 0)
ON DUPLICATE KEY
UPDATE ip=IF(ip>0 AND device_mac=rad_dev_mac AND device_port=rad_port, ip, INET_ATON(usr_ip)),
uid=0, device_mac=rad_dev_mac, device_port=rad_port, time=UNIX_TIMESTAMP();
COMMIT;
SELECT INET_NTOA(ip) INTO usr_ip FROM mac_uid
WHERE mac=rad_mac AND device_mac=rad_dev_mac AND device_port=rad_port;
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
WHERE ip = INET_ATON(usr_ip);
END IF;
SELECT NULL, login, 'Framed-IP-Address', usr_ip, '=';
END$$
DELIMITER ; - В get_ip_by_tag я сделал так, чтобы не захватывал свободные ip, в которых время релиза еще не настало
- В radreply_ipoe я выкинул onedevice, потому что не понимаю что это. Давай избавляться от него ибо логика итак пиздец какая получается. Расскажи, что оно означает, может реализуем как-нибудь иначе
- Обрати внимание, что я не проверяю выдан ли данный ip кому-то по таблице mac_uid - логику перенес на поле release в таблице ip_pool
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 01 Марта 2018, 15:58:56
Ну и в radupdate наверно нужно тоже добавить, дабы не вышел срок годности ip? UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
WHERE ip = INET_ATON(usr_ip); onedevice это тоже что и oneconnect, за исключение того что проверятся только устройствоОбрати внимание, что я не проверяю выдан ли данный ip кому-то по таблице mac_uid - логику перенес на поле release в таблице ip_pool годная логика, если uid = 0 AND `release` < UNIX_TIMESTAMP() считаем что ip свободен.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 01 Марта 2018, 16:12:08
Только апдейтить надо в случае если user_id is null т.к в set_auth есть уже такой апдейт
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: fet4 от 01 Марта 2018, 16:16:19
Только апдейтить надо в случае если user_id is null т.к в set_auth есть уже такой апдейт
Нуда или вынести его от туда в radupdate
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: Efendy от 01 Марта 2018, 18:12:23
Только апдейтить надо в случае если user_id is null т.к в set_auth есть уже такой апдейт
Нуда или вынести его от туда в radupdate Не, выносить не надо. Пусть get_ip и set_auth будут у всех одинаковыми. Хоть какая-то стабильность
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: NodenY45 от 14 Ноября 2018, 20:37:07
Время от времени я вижу жалобы на то, что бывают разного рода глюки с выдачей динамических ip. Я тут хорошо покрутил все и кажется понял в чем проблема. На самом деле основные проблемы 2: 1) deadlock-и в mysql - это когда некоторые запросы блокируют друг-друга и из-за этого не дают выполняться другим 2) бывает, что ip на nas-е не соответствует ip, которое светится в биллинге Насчет deadlock-ов. Причин тут несколько: 1) сука тупой mysql. Вот реально гадина, я тебя всегда защищал, но ты впадаешь в лок на запросах, которые ну никак логически не должны приводить к такому 2) большая нагрузка Начнем с нагрузки. Старайтесь выносить такие модули ядра как сбор трафика и заглушка на другой сервер. Особенно заглушка ибо на нее бывает льется столько трафика, что отжирает 100% проца. Если нет возможности вынести - хотя бы ограничьте количество сессий с одного ip на заглушку. Что касается mysql. Мне пришлось кординально переделать процедуру get_ip. Я сделал такие 2 серьезных изменения: 1) сделал код примитивным и очень избыточным, что бы все sql были максимально нежными. Процедура стала выглядеть тупо, не показывайте ее профи)) 2) основной затык был в выборе незанятого динамического ip. Дело в том, что mysql при большом количестве запросов выдавало одну и туже свободную запись, в этом проблемы нет, это разруливалось, но из-за такой коллизии сильно росла нагрузка. Я бы мог сделать выборку и из нее выбрать случайную строку, но mysql в этом случае создает временную таблицу, а это тоже плохо. Поэтому я поступил хитро: в таблице ip (ip_pool) я физически перегруппировую записи по типу, тегам и т.д. Для этого я создал процедуру normalize_ippool: DROP FUNCTION IF EXISTS `normalize_ippool`;
DELIMITER $$
CREATE FUNCTION `normalize_ippool` ( )
RETURNS TINYINT NO SQL
BEGIN
DECLARE mid INTEGER UNSIGNED;
CREATE TEMPORARY TABLE temp_ip_pool(
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
ip_id BIGINT UNSIGNED NOT NULL,
PRIMARY KEY (id)
);
SELECT MAX(id) into mid FROM ip_pool;
UPDATE ip_pool SET id = id + mid;
INSERT temp_ip_pool (SELECT NULL, id FROM ip_pool ORDER BY realip, type, tags);
UPDATE ip_pool i JOIN temp_ip_pool t ON i.id = t.ip_id SET i.id = t.id;
DROP TEMPORARY TABLE IF EXISTS temp_ip_pool;
RETURN 1;
END$$
DELIMITER ; Вызов этой функции я добавлю в админку при изменении любого ip/пула. Благодаря этому в get_ip я сразу беру рандомную строку без предварительной выборки, зная только начальный и конечный id нужной группы. Конечно, вам эта инфа особо не интересна, это я так для себя чтоб сохранилось в истории, ну и может теоретически кому-то понадобится. Насчет дубликатов ip. Имеется ввиду такая ситуация: есть nas и есть сервер с биллингом. Сервер перезагружается, загружается больше 6 минут, запускает модуль ядра auth, который сразу освобождает все ip по таймауту. Он-то думает, что раз 6 минут не было аккаунтинга по данным ip - значит все сессии на насе кильнулись. Он же не знает, что просто небыло коннекта с nas. А на nas сесси-то висят, а биллинг считает ip свободными и выдает другим абонам. Когда я давно придумал схему с освобождением ip, я подумал, что сервер стартанет за пару минут. Кроме того, я не предусмотрел, что может быть разрыв канала больше чем 6 минут. Поэтому сейчас я установил таймаут в час (3600 секунд) в get_ip и set_auth: DROP PROCEDURE IF EXISTS `set_auth`;
DELIMITER $$
CREATE PROCEDURE `set_auth` (IN usr_ip VARCHAR(15), IN auth_properties VARCHAR(255))
BEGIN
DECLARE usr_id INT;
SELECT uid INTO usr_id FROM ip_pool WHERE INET_ATON(usr_ip) = ip LIMIT 1;
IF( usr_id > 0 ) THEN
INSERT INTO auth_now SET
ip = usr_ip,
properties = auth_properties,
start = UNIX_TIMESTAMP(),
last = UNIX_TIMESTAMP()
ON DUPLICATE KEY UPDATE
properties = IF(auth_properties!='',auth_properties,properties),
last = UNIX_TIMESTAMP();
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
WHERE ip = INET_ATON(usr_ip) AND type = 'dynamic' LIMIT 1;
END IF;
END$$
DELIMITER ;
DROP FUNCTION IF EXISTS `get_ip`;
DELIMITER $$
CREATE FUNCTION `get_ip` ( user_id INTEGER UNSIGNED )
RETURNS VARCHAR(15) NO SQL
BEGIN
DECLARE user_ip VARCHAR(15);
DECLARE real_ip VARCHAR(15) DEFAULT 0;
DECLARE row_cnt INTEGER;
DECLARE ip_id INTEGER;
DECLARE tries INTEGER DEFAULT 30;
DECLARE id_min INTEGER;
DECLARE id_max INTEGER;
SELECT INET_NTOA(ip) INTO user_ip FROM ip_pool
WHERE uid = user_id AND type='static' LIMIT 1;
IF( user_ip IS NOT NULL ) THEN RETURN user_ip; END IF;
SELECT 1 INTO real_ip FROM users_services WHERE uid = user_id AND tags LIKE '%,realip,%';
SELECT id, INET_NTOA(ip) INTO ip_id, user_ip FROM ip_pool
WHERE uid = user_id AND type = 'dynamic' AND realip = IF(real_ip>0,1,0)
LIMIT 1;
IF( ip_id IS NOT NULL) THEN
UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
WHERE id = ip_id AND uid = user_id;
SELECT ROW_COUNT() INTO row_cnt;
IF( row_cnt > 0 ) THEN RETURN user_ip; END IF;
END IF;
SELECT MAX(id), MIN(id) INTO id_max, id_min
FROM ip_pool
WHERE type = 'dynamic' AND realip = IF(real_ip>0,1,0);
sel_ip: WHILE tries > 0 DO
SELECT id, INET_NTOA(ip) INTO ip_id, user_ip
FROM ip_pool
WHERE uid = 0
AND id >= (CEIL(RAND() * (id_max - id_min)) + id_min)
AND id <= id_max
LIMIT 1;
IF( user_ip IS NOT NULL) THEN
UPDATE ip_pool SET uid = user_id, `release` = UNIX_TIMESTAMP() + 3600
WHERE id = ip_id AND uid = 0;
SELECT ROW_COUNT() INTO row_cnt;
IF( row_cnt > 0 ) THEN RETURN user_ip; END IF;
SET tries = tries - 5;
END IF;
SET tries = tries - 1;
END WHILE;
END$$
DELIMITER ; Нужно ли после изменений ребутать ядро или модуль дхцп?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: NodenY45 от 15 Ноября 2018, 04:32:11
После применения процедур айпи выдается в течении двух минут..... при выводе tail -f /usr/local/nodeny/logs/dhcp.events.log в логи сыпется куча дублей по две по три одинаковых строки с коммитами, и не останавливается. уже не знаю что смотреть.... что это может быть? версия биллинга и дхцп модуля последние. в dhcpd.log шлет много такого флуда: Nov 15 04:37:11 localhost dhcpd: reuse_lease: lease age 39 (secs) under 25% threshold, reply with unaltered, existing lease for 10.10.20.18 прописал в дхцп конфиг пока что вот это Наблюдаю, дубли пропали. Не знаю правильно ли это, поправьте, если что.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: NodenY45 от 15 Ноября 2018, 10:25:40
Сейчас перестали освобождаться айпи.
Может ли это быть связано с dhcp-cache-threshold 0; ?
И можно ли чистить файл /var/db/dhcpd/dhcpd.leases ?
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 15 Ноября 2018, 13:13:26
Сейчас перестали освобождаться айпи. Так они сейчас через 3600 секунд освобождаются.
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: NodenY45 от 15 Ноября 2018, 15:43:16
Сейчас перестали освобождаться айпи. Так они сейчас через 3600 секунд освобождаются. Вот вырубил с порта клиента. Уже более 3600сек, авторизация не пропадает... ???
Название: Re: Deadlock-и, дубликаты ip и прочая хрень
Отправлено: kosmich от 16 Ноября 2018, 12:42:49
Сейчас перестали освобождаться айпи. Так они сейчас через 3600 секунд освобождаются. Вот вырубил с порта клиента. Уже более 3600сек, авторизация не пропадает... ??? ip клиента освобождается через 3600сек после того как закончилась авторизация. Вы не правильно выразились. Не завершается авторизация. Биллинг считает что клиент "жив". Ясное дело что ip не освобождается. Возможно процедуры, возможно аккаунтинг. Не приходит сигнал что клиент завершил авторизацию, там если не ошибаюсь, несколько вариантов.
|