[MASOCH-L] Server para RADIUS e DB

Paulo Henrique paulohenriquef at gmail.com
Tue Aug 29 18:41:23 BRT 2017


Concordo com os colegas e ainda acrescento mais uma dica quanto ao
"tunning" do banco, este é específico para o radius (freeradius na verdade).
Se puder, separe a tabela radacct em duas.
Vou explicar: O freeradius já vem com a configuração mastigada para usar
duas tabelas para o acct, basta você alterar uma linha se não me engano na
configuração do sql.conf e criar as duas tabelas no seu banco, eu costumo
chamar de radacct_open e radacct_closed.
Como os nomes sugerem, a tabela radacct_open guarda as informações das
conexões ativas e a radacct_closed guarda as informações das conexões
encerradas. Com isso, a tabela radacct_closed pode crescer volumosamente
que não vai impactar tanto no desempenho total da solução. Certamente
haverão poucos inserts e algumas operações de leitura e isso "não deve" ser
com muita frequência.
Já a tabela radacct_open, dependendo do cenário, pode sofrer inserts e
updates com bastante frequência, mas isso não vai impactar de forma
significativa porque haverão apenas apenas alguns registros nesta tabela
(talvez algo com 4 ou 5 dígitos no máximo).

Sugiro que dê uma olhada nisso também.

Em 29 de agosto de 2017 18:22, Eduardo Rigler <erigler at gmail.com> escreveu:

> Em 29 de agosto de 2017 18:04, Andre Almeida <andre at bnet.com.br> escreveu:
>
> > Beleza..... então ok, deixamos o SSD de lado.
> >
> > Pensando em custo X beneficio:
> > Qual hardware?
> >
>
> Como diria meu antigo chefe: "Seu dinheiro é o meu guia" :-)  Quanto tem
> pra gastar?
>
> Hoje acho que uma boa referência é o R630 + controladora Perc H730/P, mas
> dependendo do restante do hardware a brincadeira já começa nos 15~20k....
> pra rodar só 2 VMs é muito dinheiro.
>
> []´s
>
>
>
>
>
> >
> > Att,
> > Andre Almeida
> > Em 29 de agosto de 2017 17:52, Herlon Matos <herlon at lcimt.com.br>
> > escreveu:
> >
> > > Penso como o Leonardo, analisar o banco de dados e efetuar os ajustes
> de
> > > performance rotineiramente é o que vale no processo.
> > > Utilizaria como ele disse discos SAS.
> > >
> > > Herlon Alcantara Matos
> > > LCI Telecom
> > >
> > >
> > > Em 29/08/2017 16:38, Leonardo Rodrigues escreveu:
> > >
> > >> Em 29/08/17 16:14, Andre Almeida escreveu:
> > >>
> > >>> A principio preciso de algo que seja rápido para processar esse BD e
> > esse
> > >>> radius, pensei em algo com SSD, mas, não tenho ideia do que ir atrás.
> > >>>
> > >>>
> > >>     Não tem SSD que conserta a performance ruim de uma base de dados
> mal
> > >> feita. O que eu já peguei de banco de dados 'morrendo' porque as
> tabelas
> > >> não tinham índices nos campos consultados, você não faz idéia. Já
> ganhei
> > >> muito dinheiro, sem nenhuma vergonha de dizer isso, criando índice em
> > MySQL
> > >> porque o pessoal simplesmente esquece de criar índice em tabela com
> > 10-20
> > >> milhões de registros. E aí, vou te contar, não tem SSD nem outro
> > hardware
> > >> que faça isso ter performance !!!
> > >>
> > >>     Deixa SSD pra um segundo momento, um bom disco SAS tem ótima
> > >> performance e bem mais espaço.
> > >>
> > >>
> > >>
> > >
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > >
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>



-- 
Paulo Henrique Fonseca
paulohenriquef at gmail.com


More information about the masoch-l mailing list