+ Responder ao Tópico



  1. #1
    eval
    Visitante

    Padrão PPPOE :: %CPU alto

    Olá pessoal, eu montei um servidor com PPPOE [radius + rp-pppoe].
    O radius em uma maquina e o pppoe-server em outra.
    No servidor pppoe, um P4 3.0, o uso da CPU é muito alto, cada processo do pppoe varia de 0.3% até 4% do CPU, e com 150 usuários conectados, a maquina começa a ficar lenta, e o Load Average girando em torno de 80.0.
    Eu vi pela net que um servidor desse aguenta tranquilo mais de mil usuários. Tem algum segredo para o pppoe não consumir tanto CPU?

    Desde já agradeço.
    Eric

  2. #2

    Padrão PPPOE :: %CPU alto

    eval,

    Boa pergunta. Eu estou testando ainda o PPPoE para ver se vou implementar ele em minha rede. Uma de minhas dúvidas é quanto ao processamento necessário e a memória que ele irá utilizar.

    Terei, com certeza, que segmentar a minha rede em vários servidores PPPoE, mas em média tenho 150 clientes por POP o que chegará a pelo menos 80 conexões PPPoE em cada um destes POPs. Minha dúvida chegou em que hardware usar.

    Nos testes que tenho feito o consumo de CPU e memória é mínimo:

    root 6988 0.0 0.0 2388 472 ? S 12:55 0:00 /usr/sbin/pppoe-server -C CNett -L 172.35.0.1 -p /etc/ppp/ips -
    root 6992 0.0 0.1 3468 996 ? Ss 12:56 0:00 pppd pty /usr/sbin/pppoe -n -I eth2 -e 1:00:XX:9f:XX:9a:75 -S '
    root 6993 0.0 0.0 2796 388 ? S 12:56 0:00 /usr/sbin/pppoe -n -I eth2 -e 1:00:XX:9f:XX:9a:75 -S
    Ai eu tenho uma conexão PPPoE estabelecida e a rotina de inicialização do servidor. Veja que não está usando nada do CPU e 0,1% da memória. Mesmo com trafego intenso sobre a interface ppp0 eu não vejo o uso do CPU passar de 1%.

    A máquina em que está rodando é uma gateway de minha rede que é um Pentium III, 1.13 Ghz com 512 MB de RAM.

    Att,

    Nataniel Klug

  3. #3
    eval
    Visitante

    Padrão PPPOE :: %CPU alto

    Nataniel, a principio a minha rede também aparentava usar pouco, dentro de 1% cada sessão do pppoe, mas a medida que o número de usuários vai crescendo, essa % de cada pppoe aumenta. Observei também que o uso do CPU é proporcional ao tempo que o usuário fica conectado. Tem clientes que passam dias conectados com algum programa de P2P ligado, e a % chega a ate 4% cada processo.

    Como medida provisoria eu estou reiniciando os processos pppoe de madrugada. Assim alivia o processador.

    Eu queria saber por que o pppoe gasta tanto processamento, eu ja tive servidores com muito mais clientes conectados, mas por roteamento direto, e o LA nao passava de 0.5. Acredito que é o calculo dos bytes que o pppoe monitora, que eleva tanto o uso do CPU. Mas não estou certo disso.

    Eric

  4. #4

    Padrão PPPOE :: %CPU alto

    Eric,

    Realmente eu não fiz testes de longo prazo com o PPPoE. Nem ao menos deixei conectado por bastante tempo. Fico preocupado com essa sua posição já que isso pode atrapalhar meu desenvolvimento com o PPPoE.

    Acho que da mesma forma terei que usar esse sistema, mas preciso ter certeza de que ele se manterá estável e sem consumir minha máquina pois um gateway PPPoE não terá tanto hardware para que consiga gerenciar 50 conexões de 4% de consumo (o que daria 200% do CPU e deixaria um LAG absurdo na rede).

    Vou procurar outra forma de login para ver se consigo alguma informação. Preciso de um modo de ticketar os acessos dos clientes por hora e também por transferência de dados e achei que o PPPoE me serviria.

    Att,

    Nataniel Klug

  5. #5

    Padrão PPPoE

    O PPPoE usa mais hardware porque é uma conexao PPP sobre Ethernet, as conexoes PPP usam um algoritmo de verificação bit a bit e nao por tamanhos fixos como nos quadros ethernet, como vc emcapsula o PPP dentro de um quadro ethernet, vc tem mais processamento que em um encapsulamento comum. Eu tenho PPPoE no meu software (www.myauth.com.br) e quando o desempenho é algo critico, a solução é colocar o PPPoE em modo kernel, precisa que seu kernel esteja compilado com esse suporte, adicione a opção -k no daemon pppoe-server.
    Isso deve deixar um pouco mais rápido e leve.

    Dividir entre servidores é uma boa opção também, como sugeriu o colega acima. Você ganha com disponibilidade e desempenho!

  6. #6

    Padrão PPPOE :: %CPU alto

    Patrick,

    Eu já anderi xeretando no seu sistema de autenticação/crm e achei que ele era baseado no MyCatAuth, não sabia que era baseado no PPPoE.

    Agora tu falou uma coisa que me interessou, como deixo o suporte ao PPPoE nativo no kernel? Podes indicar alguma fonte de pesquisa?

    Minha idéia de segmentar meus servidores não será tão util pois tenho dois POPs que terão servidores segmentados e cada um atende a um máximo de 60 clientes (o que não dá 30 simultâneos). Meu problema real está no POP principal que atualmente atende mais de 120 clientes e um único servidor para aguentar umas 80 conexões PPPoE terá que ser extremamente rápido.

    Att,

    Nataniel Klug

  7. #7

    Padrão pppoe em kernel

    No kernel 2.4 vá em:

    Network Device Suporte

    Coloque todas as opcoes PPP dentro do kernel (marcando com *) e recompile o kernel (não esqueça de marcar outras opcoes para dar suporte a placa de rede, sistema de arquivos, etc..)

    # make
    # make modules
    # make modules_install
    # make bzImage
    # cp arch/i386/boot/bzImage /boot/NOMEDOKERNEL

    Coloque o nome que vc escolheu como NOMEDOKERNEL no /etc/lilo.conf e execute o lilo:
    # lilo

    reboot!

    Isso deve melhorar as coisas um pouco!

  8. #8

    Padrão PPPOE :: %CPU alto

    Patrick,

    Ahhh bom... Eu uso o kernel 2.6 e já deixei todo acesso PPP nativo no kernel. Como disse ainda não fiz testes de grande porte, apenas em laboratório e se mostrou estável a utilização do CPU (entre 0,4~2% por conexão, sendo que coloquei um máximo de 10 conexões e ficaram online durante umas 3 horas).

    Att,

    Nataniel Klug

  9. #9
    eval
    Visitante

    Padrão PPPOE :: %CPU alto

    Olá Patrick, obrigado pela resposta, vou testar no modo kernel para ver a diferença. Eu ja dividi os servidores, mas mesmo assim eles estão no maximo, e não da para dividir mais. Estou tentando desenvolver um cluster para isso, pois deve ser a unica saida.

    Sobre o seu sistema Myauth, eu pensei em trocar o sistema pppoe, para o Chillispot, fiz algumas modificações no fonte, para atender algumas necessidades, mas deparei com a possibilidade dos micros que estiverem na rede, enxergarem uns aos outros, que no meu casso isso não poderia acontecer, e a unica forma de limitar isso seria nos AP's, que nos meus não tem esse recurso. No seu sistema isso acontece também, de um micro enxergar o outro?

    Eric

  10. #10

    Padrão clientes

    Olá Eval,

    o problema dos clientes se enxergarem é:

    imagine que vc está na rede 192.168.10.0 mascara 255.255.255.0
    o broadcast dessa rede é 192.168.10.255, as maquinas windows enviam broadcast udp (portas 137, 138, 139 e 445) e as estaçoes windows que tem como broadcast esse mesmo endereço irão responder e o ambiente de rede será formado.

    Logo, a solução para os clientes não se verem é muda-los de rede, ou seja, imagine:

    cliente 1: 192.168.10.2 mascara 255.255.255.0 (broadcast 192.168.10.255)

    cliente 2: 192.168.11.2 mascara 255.255.255.0 (broadcast 192.168.11.255)

    veja que os endereços de broadcast são diferentes pois eles estão em rede diferentes, logo, o cliente 2 não responderá aos broadcast do cliente 1 e vice versa. No seu gateway voce colocará endereços ips adicionais (alias por exemplo: eth0:1, eth0:2, ...) em cada rede, assim voce isolaria de certa forma os clientes (logicamente, nao fisicamente) e evitaria esse problema.

    Como em conexoes PPPoE o broadcast e o ARP são desabilitados depois do estabelecimento da conexao, os clientes não se enxergarão (pois nao ha broadcast, o windows nao achará ninguem).

    Mesmo assim é possivel os clientes se enxergaram, no exemplo acima, se o cliente 2 digitasse: \\192.168.10.2
    ele verá os compartilhamentos do cliente 1, mas nesse caso, os pacotes serão roteados (pois estão em redes diferentes) passando pelo gateway, bloquear o FORWARD das portas 137, 138, 139 e 445 resolveria isso.

    Outra solução mais comum é bloquear o relay entre clientes no Access Point, isso não envolve software de aplicação, o AP funcionaria como um swith gerenciavel onde o administrador proibiu o trafego entre portas.

  11. #11

    Padrão PPPOE :: %CPU alto

    Ola. Patrick

    Tudo o que vc. explicou esta certo. O interessante e que fosse possivel fazermos essas subredes nos CPE´s...como o ovislink, etc...
    Ou temos outra forma de fazer?

    Mauro

  12. #12
    eval
    Visitante

    Padrão PPPOE :: %CPU alto

    Eu pensei nessa possibilidade, de criar vários alias de rede, mas como eu preciso usar ips válidos, eu vou perder pelo menos 2 ip's para cada cliente, um para o gateway e outro para o broadcast, o que torna inviavel. Os meus AP's não possuem esse função de desabilitar o relay. Então vou tentar partir para o cluster mesmo...

    Eu compilei o kernel da forma que vc falou, mas mesmo assim quando tento subir o pppoe-server, ele da o erro:
    pppoe-server: invalid option -- k

    O camando que estou usando é o
    pppoe-server -C teste -L 192.168.10.1 -p /etc/ppp/ips -I eth1 -k

    Estou vendo na net, o porque desse erro, se descobrir eu posto aqui..

    Obrigado Patrick.

    Eric

  13. #13

    Padrão PPPOE :: %CPU alto

    eval,

    O meu ta compilado com todos as opções de PPP habilitadas diretamente no kernel (* ao inves de M) e rodou na boa o servidor PPPoE.

    Eu uso Fedora Core 3 com kernel 2.6.13-4

    Att,

    Nataniel Klug

  14. #14
    eval
    Visitante

    Padrão PPPOE :: %CPU alto

    Realmente aqui nao roda o pppoe-server no modo kernel
    segui os procedimentos passo-a-passo desde link:
    http://wrath.geoweb.ge/pppoe-server.html

    Estou subindo o serviço assim:
    pppoe-server -k -I eth0 -L 192.168.0.1
    mas o pppoe-server continua me retornando o erro:
    pppoe-server: invalid option -- k

    Uso o Slackware 10.0.0 com o kernel 2.4.30, com todas as opções do ppp com *
    <*> PPP (point-to-point protocol) support[*] PPP multilink support (EXPERIMENTAL)[*] PPP filtering
    <*> PPP support for async serial ports
    <*> PPP support for sync tty ports
    <*> PPP Deflate compression
    <*> PPP BSD-Compress compression
    <*> PPP over Ethernet (EXPERIMENTAL)


    Eric