• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Adequação do servidor Proxy/Cache Squid a redes de extrema carga
 

Adequação do servidor Proxy/Cache Squid a redes de extrema carga

on

  • 4,381 views

Talk at FISL8 and 1st GITEC about performance customization on Squid Proxy/Server and Linux Kernel. In Brazilian Portuguese. The video was recorded at 1st GITEC at Interlegis (Brazilian Senate).

Talk at FISL8 and 1st GITEC about performance customization on Squid Proxy/Server and Linux Kernel. In Brazilian Portuguese. The video was recorded at 1st GITEC at Interlegis (Brazilian Senate).

Statistics

Views

Total Views
4,381
Views on SlideShare
4,381
Embed Views
0

Actions

Likes
2
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Adequação do servidor Proxy/Cache Squid a redes de extrema carga Adequação do servidor Proxy/Cache Squid a redes de extrema carga Presentation Transcript

    • Adequação do servidor  Proxy/Cache Squid a redes de  extrema carga.  Lucas Brasilino <lucas.brasilino@gmail.com> Procuradoria Geral da República ­ MPF   
    • Agenda ● O Squid; ● Tipos de otimizações; ● Dissecando a lula; ● Uso de descritores de arquivos; ● Loop principal; ● Modalidades de I/O para cache em disco;   
    • Agenda ● Substituição de objetos em cache; ● Uso de memória.   
    • O Squid ● É um servidor proxy/cache para HTTP/1.0; – Com extensões para HTTP/1.1: ● Headers: – Keep­alive – Host – Cache­Control ● Método CONNECT ● etc   
    • O Squid ● Projetado para ser um único processo – Porém algumas funcionalidades são realizadas por  processos externos. Exemplos: ● dnsserver ● ulinkd ● redirectors ● Externals ACL, etc. ● Pode utilizar threads   
    • Tipos de otimizações ● Opções (tags) no arquivo de configuração  squid.conf ● Opções definidas na configuração dos fontes  para compilação (./configure) ● Otimização do kernel do Linux (sysctl)   
    • Dissecando a lula memPools replacement policyHTTP HTTP client­side Storage Manager server­side FTP GOPHER storeclient replacement policy Store API comm_loop   
    • Uso de descritores de arquivos ● É um número inteiro com o qual é possível  acessar streams de I/O.  ● Arquivos, sockets (I/O em rede), pipes e FIFOs  (named pipes) são alguns tipos de stream. fdes = open(“arq.txt”,O_RDONLY,0600); len = read(fdes, buffer, 1024);   
    • Uso de descritores de arquivos sd = socket(...); bind(sd, ...);sd = socket (...); listen(sd, 30);connect (sd, .....); cl_sd = accept(sd,...);write(sd,”GET http://www...”,...); read(cl_sd, request,...); Socket TCP/IP    
    • Uso de descritores de arquivos ● Normalmente cada processo pode alocar no  máximo 1024 descritores # ulimit -n ● Este valor tende a ser insuficiente em redes de  extrema carga # squidclient mgr:info | grep “file desc” Maximum number of file descriptors: 8192 Largest file desc currently in use: 1430  Number of file desc currently in use:   1377
    • Parametrização: número de descritores disponíveis para o Squid ● Aumente o número de descritores – Configure os fontes: # ./configure --with-maxfd=8192 – Configure o ambiente (shell) que o squid será  executado: # ulimit -HSn 8192 && squid -DY   
    • Parametrização: número global de  descritores disponíveis ● Verifique o número de descritores disponíveis  no sistema operacional: # sysctl fs.file-max fs.file-max = 498073 # sysctl fs.file-nr fs.file-nr = 4224 0 498073   
    • Parametrização: número global de  descritores disponíveis ● Caso necessário aumente (e muito) o número  disponível de descritores: # sysctl -w fs.file-max=819200 Obs: Este último comando equivale a: # echo “819200” > /proc/sys/fs/file-max ● Não se esqueça de adicioná­lo ao arquivo  /etc/sysctl.conf   
    • Parametrização: pilha TCP/IP ● Aumente o número de portas locais disponíveis: # sysctl net.ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 61000 # sysctl -w net.ipv4.ip_local_port_range="1024 65000" net.ipv4.ip_local_port_range = 1024 65000 ● Aumente o backlog # sysctl net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_max_syn_backlog = 1024 # sysctl -w net.ipv4.tcp_max_syn_backlog=2048    net.ipv4.tcp_max_syn_backlog = 2048
    • Loop principal: comm_loop ● Todos descritores possíveis são setados como  assíncronos (non­blocking) ● É um loop chamando select(), ou similares: – São passados todos os descritores, exceto os  referentes a arquivos em disco; – O kernel define quais descritores estão prontos  para serem lidos ou escritos; – Retorna tais descritores pro Squid;   
    • Loop principal: comm_loop ● continuando... – Squid chama funções de leitura e escrita  previamente registradas; – Antes de novo loop, todas funções agendadas são  executadas, através da event API.   
    • Loop principal: comm_loop ● select() é conhecidamente lento ao  examinar um grande número de descritores. ● Uma alternativa plausível é utilizar poll() ● Caso o kernel seja 2.6, utilize epoll.   
    • Loop principal: comm_loop ● Performance do epoll   
    • Parametrização: comm_loop ● A chamada de sistema o loop irá utilizar é  definida na configuração dos fontes:  # ./configure --enable-epoll     
    • Modalidades de I/O para  cache em disco ● Implementado através da API storeclient ● Tipos: – UFS: Unix File System ● Modalidade padrão ● Utiliza as tradicionais chamadas de sistema open(), close(), read(), write(), etc ● Tais chamadas são síncronas (blocking) ● Baixa performance: 30 – 50 req/seg   
    • Modalidades de I/O para  cache em disco ● continuando... – AUFS: Asynchronous Unix File System ● Similar ao UFS; ● Utiliza threads para paralelizar o acesso a disco; ● Ideal em servidores SMP ● A nova biblioteca threads do Linux, NPTL, melhorou  muito a performance nesta modalidade; ● Boa performance: 150 – 200 req/seg;   
    • Modalidades de I/O para  cache em disco ● continuando... – Diskd: ● É um daemon externo ao Squid, apenas para enfileirar e  executar as chamadas de acesso a disco; ●  Squid repassa via message queues as operações a  serem realizadas; ● E através de shared memory são efetuadas a trocas de  dados. ● Boa performance: ~160 req/seg   
    • Modalidades de I/O para  cache em disco ● continuando... – COSS: Cyclic Object Storage System  ● É o primeiro esforço em se criar um sistema de arquivos  dedicados ao Squid; ● Segundo estudos iniciais, é a modalidade de melhor  performance ao cachear pequenos objetos; ● Armazena todos os objetos em um único arquivo; ● Recentemente desenvolvido portanto não tão estável.   
    • Parametrização: modalidades de I/O ● Recomendação: AUFS – Configure os fontes: # ./configure --enable-storeio=ufs,aufs – Configure o squid.conf: cache_dir aufs /var/cache 10240 32 256   
    • Políticas de substituição de objetos  em cache: replacement policy ● É o algorítmo que elege quais objetos deverão  ser removidos do cache para que outros sejam  armazenados; ● Tem relação direta com a performance total do  servidor;   
    • Políticas de substituição de objetos  em cache: replacement policy ● Quanto mais objetos requisitados estiverem no  cache: – menor será tempo de recebimento de uma página  Web; – menor será a utilização da largura de banda; – menor será a carga sobre o servidor Web de  origem;   
    • Políticas de substituição de objetos  em cache: replacement policy ● Algorítmos: – LRU: Least Recently Used ● É a política padrão; ● Os objetos mais antigos são eleitos para exclusão; ● É implementado através de uma lista encadeada onde os  objetos mais recentes encabeçam a lista; ● É ineficiente pois não leva em consideração o tamanho  do objeto nem tampouco a frequência ele                       foi requisitado.   
    • Políticas de substituição de objetos  em cache: replacement policy ● Algorítmos: – Heap ● Estrutura em árvore onde os objetos (nós) de maior  chave é sempre pai de um de menor chave; ● Os objetos no fim da árvore são eleitos para exclusão; 32 30 23    12 19
    • Políticas de substituição de objetos  em cache: replacement policy ● Heap: – LFU­DA: Least Frequently Used with Dynamic  Aging ● A chave do objeto é calculada levando em conta a  frequência de requisição e um fator de idade; ● Consegue alto byte hit rate    
    • Políticas de substituição de objetos  em cache: replacement policy ● Heap: – GDSF: Greedy Dual Size Frequency ● Similar ao LFU­DA, porém levando­se em conta um fator  proporcional ao tamanho do objeto; ● Os objetos menos requisitados e de maior tamanho são  eleitos para exclusão;  ● Consegue alto hit rate.   
    • Parametrização: replacement policy ● Habilitando o heap: – Configure os fontes: # ./configure --enable-removal-policies=heap – Configure o squid.conf: cache_replacement_policy heap LFUDA ou cache_replacement_policy heap GDSF   
    • Uso de memória ● Tem impacto decisivo na performance ● O Squid aloca memória para armazenar: –  in­transit objects; –  hot objects; –  metadados (incluindo tabela hash) do cache; –  buffers de I/O de disco e rede; – cache de resoluções DNS, etc.    
    • Uso de memória ● O Squid aloca o somatório de: – 10Mb de RAM a cada 1Gb em cache_dir; – Valor configurado em cache_mem; – Aproximadamente de 10 a 20Mb adicionais; ● Devemos evitar a todo custo que o sistema  operacional utilize o swap: # free -m   
    • Parametrização: uso de memória ● É realizada configurando a opção cache_mem no arquivo squid.conf; ● Recomenda­se alocar a metade da memória  RAM total do servidor para o Squid: RAM−TotalMb cachedirMb cachemem= − −20 2 102,4   
    • Obrigado !!! Lucas Brasilino <lucas.brasilino@gmail.com>   
    • Políticas de substituição de objetos  em cache: replacement policy ● Razão de acertos: – Hit rate ● É a razão entre a quantidade de objetos servidos pelo  cache pelo total de objetos requisitados; – Byte hit rate ● É a razão da quantidade de bytes servidos pelo cache  pelo total de bytes requisitados;