Первое число каждого месяца

[MorS 0]

Здравствуйте! 1-го числа каждого месяца, видимо, из-за процесса закрытия учетного периода "падает" радиус сервер:

 

May  1 00:00:15 billing kernel: [466821.810836] freeradius[15947]: segfault at 2012 ip 00007f7a9586f5da sp 00007f7a427fac60 error 4

May  1 00:00:15 billing kernel: [466821.810849] freeradius[15991]: segfault at 2012 ip 00007f7a9586f5da sp 00007f7a1a7f2c60 error 4 in rlm_perl-2.2.6.so[7f7a9586c000+6000]

May  1 00:00:15 billing kernel: [466821.811111]  in rlm_perl-2.2.6.so[7f7a9586c000+6000]

May  1 00:00:15 billing kernel: [466821.812848]  in rlm_perl-2.2.6.so[7f7a9586c000+6000] in rlm_perl-2.2.6.so[7f7a9586c000+6000]

 

Информация о системе:

-  OC Debian-7.11.0 Linux  2.6.32-3-amd64

- Версия биллинга ABillS 0.56b/20140807

- freeradius: FreeRADIUS Version 2.2.6

- mysqld  Ver 5.1.47-1

- сервера доступа Mikrotik (12 шт.)

- абонентов on-line на 1.05.2019 00:00:00 - 5570

Большинство тарифных планов с помесячной абонентской платой, с распределением абонплаты, макс. время сессии - 65535 сек.

 

Перезапуск радиуса вручную толку дает мало,система "приходит в себя" через несколько часов. Помогут ли следующее варианты решения проблемы:

1 вариант 

- выставить в параметрах сервера доступа !Session-Timeout=0,  макс. время сессии - 0 сек, отключить  в crontab (1    0  *  *  *  root   /usr/abills/libexec/periodic daily

1    1  *  *  *  root   /usr/abills/libexec/periodic monthly)

- 1-го числа каждого месяца (или каждые сутки?) воспользоваться программой autozh.pl и по очереди по одному насу переинициализировать сессии для сбора статистики.

 

2 вариант

В дополнении к первому пересобрать радиус на более свежий из второй ветки - 2.2.10. Возможно. проблема в нем. Плюс доработать скрипт, что следит за состоянием радиус-сервера (типа if [ -z "$(ps x | grep free[rad])" ]; then date >> /root/die.log;rm -f /var/run/freeradius/freeradius.pid;/etc/init.d/freeradius stop;/etc/init.d/freeradius start; fi)

 

3 вариант

В тарифных планах отказаться от месячной абонплаты  и настроить дневную абонентскую плату. В crontab оставить только periodic daily. Возможно это сделает нагрузку на биллинг более равномерной.

 

4 вариант 

Апгрейд биллинга до последней версии  - возможно модуль rlm_perl будет работать стабильнее. Интересует целесообразность и цена обновления.

 

Возможно, у есть другие варианты, с удовольствием с ними ознакомлюсь.

P.S. Может у кого есть autozh.pl для 0.5x версии биллинга? Скиньте, пожалуйста!

Відредаговано 2019-05-02 14:42:48 MorS

[KaYot 3 730]

Я бы сказал что падает он от криво настроенного log rotate, а не от роста нагрузки.

Проверяйте как он hup отрабатывает.

[zulu_Radist 856]

а раньше не падал?

[foreverok 95]

  В 02.05.2019 в 14:42, MorS сказав:

OC Debian-7.11.0 Linux  2.6.32-3-amd64

Expand  

Не пора ли обновить? Debian 7 протух год назад.

 

Правильно выше про logrotate. Добавлю, проверьте еще задания cron которые выполняются в это время.

Відредаговано 2019-05-02 17:51:48 foreverok

[MorS 0]

  В 02.05.2019 в 16:11, zulu_Radist сказав:

а раньше не падал?

Expand  

Раньше не падал, пользователей в начале месяца выкидывало, но не так чтобы уж очень долго продолжался этот процесс.

[zulu_Radist 856]

перейти на посуточное снятие абонки снимет нагрузку,  однозначно.  но я бы еще собрал параллельно биллинг на свежем дебиан,  обновился до 0.59, хуже не будет. и сегфолтиться радиус может как следствие проблем с бд

Відредаговано 2019-05-03 17:30:27 zulu_Radist

[MorS 0]

  В 03.05.2019 в 17:26, zulu_Radist сказав:

перейти на посуточное снятие абонки снимет нагрузку,  однозначно.  но я бы еще собрал параллельно биллинг на свежем дебиан,  обновился до 0.59, хуже не будет. и сегфолтиться радиус может как следствие проблем с бд

Expand  

То есть вариант перейти на последнюю версию биллинга не рассматривается, как ненужный? B 0.5x уже не поддерживается разработчиками с 2018 года.

Відредаговано 2019-05-04 10:33:30 MorS

[Digital_storm 68]

  В 04.05.2019 в 10:32, MorS сказав:

B 0.5x уже не поддерживается разработчиками с 2018 года.

Expand  

Да ладно!!!??? Рілі? 

 

[kvirtu 315]

  В 04.05.2019 в 10:32, MorS сказав:

То есть вариант перейти на последнюю версию биллинга не рассматривается, как ненужный? B 0.5x уже не поддерживается разработчиками с 2018 года.

Expand  

можете конечно, только на выходе можете получить вполне себе НЕрабочий биллинг

[Digital_storm 68]

  В 03.05.2019 в 17:26, zulu_Radist сказав:

перейти на посуточное снятие абонки снимет нагрузку,  однозначно.  но я бы еще собрал параллельно биллинг на свежем дебиан,  обновился до 0.59, хуже не будет. и сегфолтиться радиус может как следствие проблем с бд

Expand  

У нас два мікротіка Х86 на серверах. Для них радіус відпрацьовує добре. Розвернув Ацель. При авторизації на Ацелі (1000+ абонів) Радіус падає до рестарта. Аббілс 0.59

[Dimkers 1 606]

В ацеле без проблем лимит делается. И ничего не падает.

Відредаговано 2019-05-04 14:32:16 Dimkers

[zulu_Radist 856]

  В 04.05.2019 в 12:10, Digital_storm сказав:

У нас два мікротіка Х86 на серверах. Для них радіус відпрацьовує добре. Розвернув Ацель. При авторизації на Ацелі (1000+ абонів) Радіус падає до рестарта. Аббілс 0.59

Expand  

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

[mixtery 123]

  В 04.05.2019 в 10:32, MorS сказав:

То есть вариант перейти на последнюю версию биллинга не рассматривается, как ненужный? B 0.5x уже не поддерживается разработчиками с 2018 года.

Expand  

поправочка: 0.59 - 2016 год
Насколько помню у абиллса всегда политика поддержки = обновитесь до последней и тогда уже поехали по багам.
Работать-то оно будет, но "разбирайтесь сами". Подсмотреть в новые версии публичные никто никогда не мешает.

 

[Romeshik 144]

  В 03.05.2019 в 17:26, zulu_Radist сказав:

перейти на посуточное снятие абонки снимет нагрузку,  однозначно.  но я бы еще собрал параллельно биллинг на свежем дебиан,  обновился до 0.59, хуже не будет. и сегфолтиться радиус может как следствие проблем с бд

Expand  

Зулу я с этим посуточным мучаюсь уже лет 8. Есть две сети, разные места. Везде биллинг стг, так вот тариф допустим 150-170 грн. Хорошо когда месяц 30 дней и тариф 150 грн - снимается по 5 грн в сутки абонки и все. А вот когда 31 день и тариф 150-170, вот тогда ничинаются фокусы. стг делит 150 на 31 и естественно сутки не целое число. И в последний день месяца вылазят какие минимальные копейки в минусе и абона отключает не 1 числа а 31го числа. Делали фокус-скрипт, который в конце месяца сравнивает абонплату за месяц и смотрит остаток в последний день, а потом обнуляет минус. Но он вроде как работает только если абонент вовремя пополнил счет (до конца месяца заплатил за следующий). Если же абонент завтыкал и платит 1-2-3 числа, абонка уже в минусе + месячная абонка и в конце этого нового месяца у него уже копейки в минусе. Уточню что абонов приучил, что месяц у нас с 1 числа по 31 и вариант с 4го по 4 не катит. Может есть у кого идеи как победить мою беду? а то у меня 31-1 число каждый месяц танцы с бубном

Відредаговано 2019-05-04 20:22:37 Romeshik

[vop 370]

  В 04.05.2019 в 20:21, Romeshik сказав:

Зулу я с этим посуточным мучаюсь уже лет 8. Есть две сети, разные места. Везде биллинг стг, так вот тариф допустим 150-170 грн. Хорошо когда месяц 30 дней и тариф 150 грн - снимается по 5 грн в сутки абонки и все. А вот когда 31 день и тариф 150-170, вот тогда ничинаются фокусы. стг делит 150 на 31 и естественно сутки не целое число. И в последний день месяца вылазят какие минимальные копейки в минусе и абона отключает не 1 числа а 31го числа. Делали фокус-скрипт, который в конце месяца сравнивает абонплату за месяц и смотрит остаток в последний день, а потом обнуляет минус. Но он вроде как работает только если абонент вовремя пополнил счет (до конца месяца заплатил за следующий). Если же абонент завтыкал и платит 1-2-3 числа, абонка уже в минусе + месячная абонка и в конце этого нового месяца у него уже копейки в минусе. Уточню что абонов приучил, что месяц у нас с 1 числа по 31 и вариант с 4го по 4 не катит. Может есть у кого идеи как победить мою беду? а то у меня 31-1 число каждый месяц танцы с бубном

Expand  

 

Как правильно сделать расчет фиксированной абоненты при разной длине месяца я подробно объяснял автору стг еще... дай бог памяти, году эдак в 1997. Не сложилось. Видимо, никак это не исправить в стг.

[Romeshik 144]

  В 04.05.2019 в 20:47, vop сказав:

 

Как правильно сделать расчет фиксированной абоненты при разной длине месяца я подробно объяснял автору стг еще... дай бог памяти, году эдак в 1997. Не сложилось. Видимо, никак это не исправить в стг.

Expand  

Есть ли у вас возможность обьяснить и мне? У меня есть товарищ, которой смог бы мне прикрутить вашу идею к стг.

[a_n_h 593]

  В 04.05.2019 в 20:21, Romeshik сказав:

Зулу я с этим посуточным мучаюсь уже лет 8. Есть две сети, разные места. Везде биллинг стг, так вот тариф допустим 150-170 грн. Хорошо когда месяц 30 дней и тариф 150 грн - снимается по 5 грн в сутки абонки и все. А вот когда 31 день и тариф 150-170, вот тогда ничинаются фокусы. стг делит 150 на 31 и естественно сутки не целое число. И в последний день месяца вылазят какие минимальные копейки в минусе и абона отключает не 1 числа а 31го числа. Делали фокус-скрипт, который в конце месяца сравнивает абонплату за месяц и смотрит остаток в последний день, а потом обнуляет минус. Но он вроде как работает только если абонент вовремя пополнил счет (до конца месяца заплатил за следующий). Если же абонент завтыкал и платит 1-2-3 числа, абонка уже в минусе + месячная абонка и в конце этого нового месяца у него уже копейки в минусе. Уточню что абонов приучил, что месяц у нас с 1 числа по 31 и вариант с 4го по 4 не катит. Может есть у кого идеи как победить мою беду? а то у меня 31-1 число каждый месяц танцы с бубном

Expand  

это "размазанная" оплата, сделайте посуточную (т.е. к примеру 5 грн сутки, мес 30 д - 150 грн, 31 день - 155 грн), и проблем не будет.

[l1ght 377]

  В 06.05.2019 в 15:21, Romeshik сказав:

Есть ли у вас возможность обьяснить и мне? У меня есть товарищ, которой смог бы мне прикрутить вашу идею к стг.

Expand  

вся суть идеи vop простая

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

всё

 

  В 04.05.2019 в 18:15, mixtery сказав:

2016 год

Expand  

сегфолтится rlm_perl и этим всё сказано

либо бага в перловом колбеке либо в либе радиуса

без трейса вряд ли можно отловить кто из двух уиноват

[vop 370]

  В 06.05.2019 в 15:21, Romeshik сказав:

Есть ли у вас возможность обьяснить и мне? У меня есть товарищ, которой смог бы мне прикрутить вашу идею к стг.

Expand  

 

Попробую, хотя я уже давно занимаюсь другими вещами.

 

У вас есть абонплата - фиксированная цена за - один календарный месяц - период переменной длительности (31, 30,29 или 28  дней). Т.е. у вас есть расчетный период - один месяц. Независимо от его длительности. Это значит, что в лицевом счет должна появляться одна-единственная запись по окончанию расчетного периода - начисление за этот период.

 

С другой стороны, у вас услуга _непрерывного_ характера. Следовательно, самый естественный способ определения стоимости услуги тоже является непрерывным. Например, пропорционально доли абонплаты в зависимости времени предоставления услуги. Считать можно по-секндно, поминутно, по-часово. А проще - посуточно.

 

Вы же сможете двумя арифметическими операциями определить, сколько стоит услуга, предоставлявшаяся 1 день в месяц, 12, 23 или 30? Для любой длительности месяца? Эта стоимость является свойством продаваемой вам услуги. Точнее, свойством ресурса, который вы продаете. И это свойство попадет в лицевой счет, как выше писалось, только в конце расчетного периода.

 

А вот решение о состоянии абонента принимается по балансу, который состоит из остатка на лицевом счету, и сумме текущих затрат по всем услугам, продаваемым абоненту, которая увеличивается ежедневно.

 

Я не знаю, как это сделать в стг.

 

  В 06.05.2019 в 18:46, l1ght сказав:

вся суть идеи vop простая

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

всё

Expand  

 

Про два поля - интересно. Что вы имели в виду?

У меня - целочисленная арифметика вообще без каких-либо дробных частей. Учет ведется в единицах, в 10 раз меньших минимальной денежной единицы. Т.е. назовем условно деци-копейки. Использование арифметики с плавающей запятой для целочисленных величин, мягко говоря, совсем не разумно.

 

[l1ght 377]

  В 06.05.2019 в 19:48, vop сказав:

Про два поля - интересно. Что вы имели в виду?

Expand  

Очевидно для поля в РСУДБ. Бабло ж в надежной базе храним.

  В 06.05.2019 в 19:48, vop сказав:

Учет ведется в единицах, в 10 раз меньших минимальной денежной единицы

Expand  

Я помню просто был тема что нужно единицы хранить отдельно от "копеек" в двух разных целочисленных полях.

[vop 370]

  В 06.05.2019 в 20:25, l1ght сказав:

Очевидно для поля в РСУДБ. Бабло ж в надежной базе храним.

Expand  

 

Понятно. Бабло храним в надежной базе.

 

  1 hour ago, l1ght said:

Я помню просто был тема что нужно единицы хранить отдельно от "копеек" в двух разных целочисленных полях.

Expand  

 

Видимо, это было без меня.

[l1ght 377]

  В 06.05.2019 в 22:07, vop сказав:

Видимо, это было без меня.

Expand  

Ну может память подводит, придется тред поискать.

[vop 370]

  В 07.05.2019 в 05:32, l1ght сказав:

Ну может память подводит, придется тред поискать.

Expand  

 

Вопрос не столь принципиален, но если желание есть, было бы интересно почитать.

Відредаговано 2019-05-07 13:21:12 vop

[l1ght 377]

  В 07.05.2019 в 13:20, vop сказав:

 

Вопрос не столь принципиален, но если желание есть, было бы интересно почитать.

Expand  

Не смог найти.

Может это был плод моей подбитой фантазии.

[zulu_Radist 856]

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