1Um comentário

• Eduardo Santos(usuário não autenticado)

  8 de Agosto de 2012, 11:48

   

  Olá Cinthia,

  Primeiro precisamos entender a forma com a qual as requisições são tratadas. O tuning ou ajuste fino do servidor nunca é uma operação que depende somente de um fator, assim como envolve o conhecimento do ambiente operacional e dos softwares envolvidos.

  Digo isso para me ater a uma parte de seu comentário:

  O servidor tem alguns milhares de acessos por dia e estes acessos estão todos sendo salvos em memória.

  Dizer que os acessos são "salvos" em memória talvez não seja o mais correto. Quando uma requisição chega ao AOLServer, por trabalhar com a arquitetura multithread, ele naturalmente despacha uma thread para lidar com a conexão. Quando subimos o servidor, todo o espaço de memória necessário para lidar com as threads é alocado em um único processo chamado nsd. Esse processo "dispara" threads para lidar com as conexões à medida que elas chegam.

  Aí estão as configurações importantes de conexão. A quantidade de memória utilizada pelo servidor será sempre número de threads vezes o tamanho de cada uma. As configurações são feitas através do arquivo config.tcl do servidor, onde vale observar os seguintes parâmetros:

  ns_param   stacksize          [expr 1 * 8192 * 256] 

  ns_param   maxthreads         10       ;# Tune this to scale your server

  ns_param   minthreads         0        ;# Tune this to scale your server 

   

  O parâmetro stacksize diz qual é o tamanho de cada thread. Os outros (maxthreads e minthreads) dizem qual os valores máximos e mínimos que pode-se ter.

  Vamos entender como isso funciona através de um exemplo: chegaram 1000 conexões ao mesmo tempo em um servidor com os parâmetros acima. O servidor vai despachar uma thread para cada conexão até atingir o máximo que ele pode servir ao mesmo tempo (no caso 10). Após atingir o limite, as conexões entram em fila, que também é configurada através de um parâmetro.

  ns_param   maxconnections     100       ;# Max connections to put on queue

  No caso, quando o limite da fila também for atingido, o servidor passa a rejeitar as conexões e os usuários não conseguem acessar o sistema. O que ele precisa fazer então é liberar a thread da conexão o mais rápido possível, para que ela esteja disponível para o próximo usuário. No caso, quando a fila fica grande demais, o servidor começa a apresentar problemas de I/O, identificado mais facilmente por um baixo consumo de memória e processador, mas um load average alto no servidor.

  No caso de utilização do swap, significa que as threads estão solicitando mais memória que o servidor pode disponibilizar. É preciso então reduzir a quantidade de threads que o servidor utiliza, mas tentando não reduzir muito para que usuários não enfrentem problemas de conexão.

  Enfim, é um processo de administração trabalhoso e contínuo, e encontrar a melhor relação entre número de threads e performance é sempre uma tarefa árdua. O fato de milhares de usuários acessarem o sistema ao mesmo tempo não deve ser um problema em qualquer instalação básica do OpenACS, pois o processo de liberar a thread para o próximo é, normalmente, muito rápido. Milhões de conexões simultâneas poderiam ser um problema, mas também configurável.

  É o máximo que posso dizer sem conhecer bem a sua estrutura de produção.

  Espero ter ajudado.

  Abraços