NiTr0

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

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

Альтернативы? Ну кроме заведения отдельной таблицы для всех адресов пулов, и апдейта записей в ней (что чревато)? А с чего бы ему образовываться? Как еще гарантировать атомарность выделения ип адреса? 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 батареях к слову можете у Микроватта взять балансировщик. Хуже не будет, а так - может помочь избежать перезаряда и выкипания если емкости батарей сильно отличаются... Стоит недорого.

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

Если это сервера на паре лга771 зионов, то 200-250Вт каждый в простое легко скушают... Если биллинг на 6-головом фене или чем-то подобном, то Вт 150 тоже легко. У меня на днях бордюр на 6-головом фене встал (дефект БП), судя по показометру АРСшного упса - оказалось, нагрузка упала в 2 раза; пара серверов на 4-головых фенах (второй бордюр и брас) + пара коммутаторов жрут столько же, сколько этот феном...

Ну в общем-то я говорил о камнях одного семейства (микроархитектуры). sandy bridge от haswell к примеру тоже отличаются существенно. Но вот зионы на SB ядрах от десктопных SB - отличаются незначительно.

А если точнее - отдельные блоки будут идентичными, но их кол-во на кристалле может изменяться. К примеру, на некоторых зионах Е3 нет встроенной видяшки (и скорее всего - даже на кристалле ее нет, а не просто отключена), на целеронах - видяха с меньшим кол-вом блоков и кеша чем на пнях и т.п... Если выпуск кристаллов массовый - то готовится урезанный кристалл, если сегмент небольшой (или экономия кремния незначительна) - то отключаются (или отжигаются лазером) "лишние" блоки у старшей модели.

Как это - не отпускает? Как только сессия попадает в зап - все, юзер может коннектиться снова. В зап она попадает после N потерянных алайвов. Один минус - удаляется из запа целиком она всего после 2*N алайвов, я прикрутил себе патчик чтобы в запе она висела Y алайвов (доп.переменная конфига), на случай прерывания связи между биллингом и насами/остановки биллинга на профилактику...

Ну в dv_log тут ничего не попадает (разве что при единомоментном дисконнекте всех юзеров). Но в целом - да, до идеала далеко...

Что вы с ними делаете-то? Тут либо подбор с самых дешевых комплектующих (эссроки с кодегенами), либо жуткое надругательство над железом (хотя даже эксплуатация на душном чердаке на такое не способна). Более-менее вменяемые железки (выбранные по внешним признакам типа годного радиатора, кошерных конденсаторов и т.п.) живут долго и счастливо.

А кто мастеру доложит, что это свичок умер, а не слэйв? Или кто слэйву доложит, что мастер - жив, а умер свич? Пушкин что ли? Рвется связь между нодами - и вот вам 2 мастера.

Живут. У меня в эксплуатации есть тазики и 2008 года сборки (более старый хлам уже поубирали - и совсем не по причине отказов). Работают и не пыхтят. И винты по 50 тыс. часов нааботки, обычные десктопные - тоже имеются. И типа серверные винты, сородичи десктопных, мрут ничуть не хуже десктопов.