NiTr0

С какой это радости - не должно быть? Т.е. однопоточная обработка запросов в порядке очереди - это хорошая, годная практика? Обычно есть поток-менеджер, и потоки-воркеры, на которые менеджер раскидывает задания...

Ну и куда его, с егойными 16к маршрутов? В 16к даже Украина не влезет ЕМНИП... Как балансировать-то трафик по двум каналам на нем? А главное - нафига строить ядро сети на свиче, максимум годном на агрегацию? А по сабжу - первый признак того, что где-то затык - низкая скорость одиночной tcp сессии (к примеру - низкие показатели спидтеста). И да, эти показатели в принципе нормальны для такого онлайна.

Ну так и сохраняются. И статус оттуда же подчитывается. А вот операция считывания статуса, его обработка и сохранение - должна быть атомарной. Потому и лок. Обычный такой фрирадиус, ессно асинхронный. Ну альтернатива ессно строить карту адресов и держать ее в памяти общей для всех потоков... но опять же - надо гарантировать монопольный доступ к ней (семафоры всякие, которые не факт что будут нормально работать если потоки вызываются из фрирадиуса) и прочие заморочки.

А с чего вы взяли, что логика в СУБД? В СУБД только хранилище активных сессий и собссно пулов. Логика вся в перле (составление карты адресов для пулов, исключение из карты адресов уже занятых сессиями, и соответственно занесение в БД новой сессии). Из-за чего и локи таблиц Ну и да, в той же гидре логика в СУБД вся. Из-за чего она и применяется при больших нагрузках...

Из файловой системы Прекрасно, пилим свою нескучную СУБД, которая будет вести таблицу выделенных адресов в файле... Так вот, auth.pm - это и есть плагин радиус-сервера, который выдает адреса

Прекрасно. Сервис падает (OOM, глюк железа, плановый перезапуск - неважно), и поднимается немного погодя. Где брать актуальную инфу о выданных адресах? Лезть в БД, от использования которой якобы ушли? И ничего, что таковым сервисом по всем правилам должен являться радиус-сервер (ибо это, наряду с авторизацией - его основная задача)? Не, можно конечно и к примеру memcached использовать в качестве хранилища временной "таблицы" адресов, и свой нескучный велосипед напилить, но все же проблм с этим огрести можно больше, чем получить профита.

Что под этим имелось ввиду?

Не совсем корректно. Приоритет пулов нечеткий получается...

Что интересно - образовываться ему там не с чего, транзакций явных нет...

Вообщем-то локи в целом плохо, лучше когда без них, но без них навряд получится нормально...

Альтернативы? Ну кроме заведения отдельной таблицы для всех адресов пулов, и апдейта записей в ней (что чревато)? А с чего бы ему образовываться? Как еще гарантировать атомарность выделения ип адреса? SQL процедурой, выполняющей идентичные действия в которой тоже будет использоваться лок таблицы? Ну и да, 2к онлайна без особого напряга тянет тазик 5-летней давности с 2-головым атлоном...

Не интересовался как сейчас с покупкой PI.

К слову китайцы типа таких http://www.dx.com/p/rj45-network-cable-crimp-with-cable-cutter-2-set-toolkit-3530 по отзывам монтажников, вполне нормально жмут, и не рассыпаются на глазах.

В дебиане все как раз вполне хорошо. Прецеденты были из-за глобальных переменных БД, которые несовместимы с многопоточным перлом. Из-за чего и собирался радиус без потоков вручную. Почему? Почему бы не внести сессию в БД, со статусом "в процессе"? А теперь ситуация - клиент начинает долбить авторизацию в 100500 потоков, но не согласовывается с сервером и режектится. В случае с записями таблице сессий - в худшем варианте займется N адресов по кол-ву брасов (при реконнекте на брас клиента с тем же CID/логином ему выдается старый ип), в твоем случае - засирается временный пул адресов. А чтобы их не было - и используется лок.

Ну сессия создается при авторизации, занимая ип. Если аккаунтинг не пришел - сессия умирает. Если я ничего не попутал в алгоритме (давно ковырял код).

Угу, активные сессии. 2-3к записей для БД - пшик... Даже если бы вообще индексов не было. То не фикс. А обеспечение атомарности операции выдачи адреса из пула (для чего - блокируется доступ к таблице на время поиска ип и внесения его в таблицу сессий). Ну чтобы не выдавался один и тот же адрес клиентам, выполняющим одновременно авторизацию...

Эм... Вторичный вы что, на той же машине что и первичный поднимаете? Или с чего вас смущает удаление старого конфига?

dv_calls не наполняется... dv_log - да, но туда записи попадают уже сильно опосля... Давно появился сброс клиентов с дублирующимися адресами? Я что-то не замечал такого в коде... CentOS - все прекрасно работает искаропки. Debian - тоже все завелось искаропки в более-менее актуальной версии (в старых типа 0.51 - там да, радиус крашился по причине того что используются глобальные переменные типа $db, в то время как $db должна быть уникальной для каждого потока).

Мы завели новое поле, добавили туда авто-генерацию идентификатора при создании или скриптом (ид + цифра контрольной суммы по Верхоффу). С возможностью правки в будущем вручную. Сугубо ради того, чтобы юзвери не вбивали ошибочные идентификаоры в платежной системе.

А не факт что битая/мертвая. 600Вт - это ампер 60-70 от батареи, в идеале годная батарея при таком токе за час просядет до 10В согласно типичным кривым разряда. Прибавить еще падение напряжения на проводах и контактах (что повысит порог отключения упса), прибавить рост тока с просадкой напряжения батареи (с ростом потерь)...

Никуда они не уходят, а попадают в зап при N пропущенных алайвах Да и опенсорс это умеет (во всяком случае срез годичной давности). Только тут вот какое дело - биллинг отпал, сессии попридивались как истекшие, ип адреса повыдавались новым клиентам при коннекте. А сессии-то живые... Итог - нифига не работает нормально, надо по факту полностью рестартовать демоны на брасах или прибивать старые/новые сесии...

Только с полноценным эзернетом на борту. Ну или возможно юсб, но с полноценным юсб хостом, а не отг костыликом. Хотя сомневаюсь. Сколько там малинка вытягивает? 15 мбит? Или целых 20? Ну и да, проще нетбука ничего не придумать ИМХО. Можно - с никсами и простым гуем к айперфу.

Транзит иногда стоит немногим дешевле микса, а иногда (к примеру если только ЕТТ без конкурентов), транзит и не поиметь. Остальное - затраты на железо и так и так самому тащить (ну разве что тазик биллинга-браса не нужен будет - но это копейки в общей цене), админ и так и так нужен - либо самому админить, либо брать удаленного админа (будь то только л2, или с биллингобрасом полноценная сеть). Стоило бы конечно еще свою AS прикупить, чтобы не натить... С PI/24 хотя бы. Но на первое время и так хватит.

При 2 батареях к слову можете у Микроватта взять балансировщик. Хуже не будет, а так - может помочь избежать перезаряда и выкипания если емкости батарей сильно отличаются... Стоит недорого.

Только выиграете. Меньше потери на контактах/проводах.