[FUG-BR] RES: Problemas com cache usando Lusca e freebsd 8.0 64bts
Bom dia, Quanto de memoria tem essa maquina? João Luiz Pedrosa Viana http://www.vespanet.com.br http://www.jviana.eti.br MSN: jvi...@bsdmail.com Skype: jviana (31)8661-4232 Esta mensagem, incluindo seus anexos, pode conter informações privilegiadas e/ou de caráter confidencial e seu conteúdo é para conhecimento exclusivo do destinatário. O seu uso, divulgação, reprodução e/ou cópia são proibidos. This message is intended only for the individual or organization to which it is addressed and contains confidential and privileged information. Any retransmission, dissemination or other use of this information by anyone other than the intended recipient is prohibited. -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Joao Pedro Paula Pannain Souza Enviada em: terça-feira, 4 de maio de 2010 21:23 Para: freebsd@fug.com.br Assunto: [FUG-BR] Problemas com cache usando Lusca e freebsd 8.0 64bts Boa noite, por favor me ajudem. instalei e configurei um servidor de cache. Durante o dia quando a carga de trabolho é pequena ele funciona muito bem. Porém quando muitos usuarios fazem requisiçoes ele vem demostrando um comportamento anormal gerando muita lentidao na rede. Acompanhando o trafego na placa de rede percebemos q ele vai de 30 mb a 1 mb e vouta a subir em menos de 5 segundos. Segue minha configuraçao = squid.conf acl all src all acl manager proto cache_object acl localhost src 127.0.0.1/32 acl to_localhost dst 127.0.0.0/8 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl provedor src 192.168.0.0/16 acl provedor src 10.0.0.0/8 acl provedor src 127.0.0.1/32 http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow provedor http_access deny all icp_access allow provedor icp_access deny all # htcp_access allow provedor # htcp_access deny all # miss_access allow all http_port 3128 transparent zph_mode tos zph_local 0x10 # zph_sibling 0 # zph_parent 0 cache_mem 3072 MB maximum_object_size_in_memory 150 KB cache_replacement_policy heap LFUDA cache_dir aufs /cache/hd1 10 16 256 cache_dir aufs /cache/hd2 10 16 256 cache_dir aufs /cache/hd3 10 16 256 cache_dir aufs /cache/hd4 10 16 256 cache_dir aufs /cache/hd5 10 16 256 cache_dir aufs /cache/hd6 10 16 256 maximum_object_size 700 MB access_log none logfile_daemon /usr/local/lusca/libexec/logfile-daemon cache_log /var/log/squid/cache.log cache_store_log none logfile_rotate 10 pid_filename /usr/local/lusca/squid.pid debug_options ALL,1 log_fqdn off client_netmask 255.255.255.255 netdb_filename /usr/local/lusca/netdb/netdb.state refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 acl shoutcast rep_header X-HTTP09-First-Line ^ICY\s[0-9] upgrade_http0.9 deny shoutcast acl apache rep_header Server ^Apache broken_vary_encoding allow apache cache_effective_user squid cache_effective_group squid httpd_suppress_version_string on coredump_dir /usr/local/lusca visible_hostname xx icp_port 0 htcp_port 0 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Problemas com cache usando Lusca e freebsd 8.0 64bts
Oi Pessoal, Bom dia. Ela tem 8Gb de Ram, mas estamos subindo ela para 12Gb. É um Servidor DELL Xeon Dual 3000 GHz, com 2 hd sata de 1 tera e 1 hd scsi com o BSD, nos satas estamos usando ZFS, porem ainda dividindo 1T para cache e 1T pra video. Eu acho que descobri o problema, aumentei os FDs no sysctl para um valor absurdo e testei com o polygraph e parece que deu um bom resultado. Uma coisa que percebi tb, que quando deixo ativo o cachevideo e quando fiz o teste sem ele com o polygraph consegui trafego de 100Mbps e quando habilitava ele punha o lusca a 100% na cpu e passava 40Mbps, depois da alteração do FD, testando com um indice REQ de 500/seg Estou aguardando chegar a hora fatídica para ver se resolveu realmente, pois o problema só dá quando o volume de usuários aumenta, no fim do dia e dura esse sofrimento durante uma hora +/- e depois volta ao normal. Agradeço a atenção de todos, Att., João Pedro Em 5 de maio de 2010 09:27, João Luiz Pedrosa Viana jvi...@vespanet.com.brescreveu: Bom dia, Quanto de memoria tem essa maquina? João Luiz Pedrosa Viana http://www.vespanet.com.br http://www.jviana.eti.br MSN: jvi...@bsdmail.com Skype: jviana (31)8661-4232 Esta mensagem, incluindo seus anexos, pode conter informações privilegiadas e/ou de caráter confidencial e seu conteúdo é para conhecimento exclusivo do destinatário. O seu uso, divulgação, reprodução e/ou cópia são proibidos. This message is intended only for the individual or organization to which it is addressed and contains confidential and privileged information. Any retransmission, dissemination or other use of this information by anyone other than the intended recipient is prohibited. -Mensagem original- De: freebsd-boun...@fug.com.br [mailto:freebsd-boun...@fug.com.br] Em nome de Joao Pedro Paula Pannain Souza Enviada em: terça-feira, 4 de maio de 2010 21:23 Para: freebsd@fug.com.br Assunto: [FUG-BR] Problemas com cache usando Lusca e freebsd 8.0 64bts Boa noite, por favor me ajudem. instalei e configurei um servidor de cache. Durante o dia quando a carga de trabolho é pequena ele funciona muito bem. Porém quando muitos usuarios fazem requisiçoes ele vem demostrando um comportamento anormal gerando muita lentidao na rede. Acompanhando o trafego na placa de rede percebemos q ele vai de 30 mb a 1 mb e vouta a subir em menos de 5 segundos. Segue minha configuraçao = squid.conf acl all src all acl manager proto cache_object acl localhost src 127.0.0.1/32 acl to_localhost dst 127.0.0.0/8 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT acl provedor src 192.168.0.0/16 acl provedor src 10.0.0.0/8 acl provedor src 127.0.0.1/32 http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow provedor http_access deny all icp_access allow provedor icp_access deny all # htcp_access allow provedor # htcp_access deny all # miss_access allow all http_port 3128 transparent zph_mode tos zph_local 0x10 # zph_sibling 0 # zph_parent 0 cache_mem 3072 MB maximum_object_size_in_memory 150 KB cache_replacement_policy heap LFUDA cache_dir aufs /cache/hd1 10 16 256 cache_dir aufs /cache/hd2 10 16 256 cache_dir aufs /cache/hd3 10 16 256 cache_dir aufs /cache/hd4 10 16 256 cache_dir aufs /cache/hd5 10 16 256 cache_dir aufs /cache/hd6 10 16 256 maximum_object_size 700 MB access_log none logfile_daemon /usr/local/lusca/libexec/logfile-daemon cache_log /var/log/squid/cache.log cache_store_log none logfile_rotate 10 pid_filename /usr/local/lusca/squid.pid debug_options ALL,1 log_fqdn off client_netmask 255.255.255.255 netdb_filename /usr/local/lusca/netdb/netdb.state refresh_pattern ^ftp: 144020% 10080 refresh_pattern ^gopher:14400% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern . 0 20% 4320 acl shoutcast rep_header X-HTTP09-First-Line ^ICY\s[0-9] upgrade_http0.9 deny shoutcast acl apache rep_header Server ^Apache broken_vary_encoding allow apache cache_effective_user squid cache_effective_group squid httpd_suppress_version_string on coredump_dir /usr/local/lusca visible_hostname xx icp_port 0 htcp_port 0 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico:
Re: [FUG-BR] RES: Problemas com cache usando Lusca e freebsd 8.0 64bts
Em 5 de maio de 2010 14:41, Joao Pedro Paula Pannain Souza jp.pann...@gmail.com escreveu: Oi Pessoal, Bom dia. Ela tem 8Gb de Ram, mas estamos subindo ela para 12Gb. É um Servidor DELL Xeon Dual 3000 GHz, com 2 hd sata de 1 tera e 1 hd scsi com o BSD, nos satas estamos usando ZFS, porem ainda dividindo 1T para cache e 1T pra video. A máquina me parece bastante superior para essa tarefa, que mal lhe pergunte, qual é o seu link atual e qual o máximo de clientes trafegando ao mesmo tempo que você tem visto? Quanto ao ZFS, eu o considero uma má escolha para essa finalidade, pois com essa quantidade de discos (apenas 2) ele será bem mais lento que um GEOM. Você ganha velocidade com ZFS tendo muitos HDs, muita RAM pra caches, dispositivos intermediarios de cache, por ai vai, e ganhas tranquilidade com a segurança dos teus dados usando um raidz2 pois é muito seguro e a manipulação dos pools de discos é um mumu. No seu caso de usar um simples stripping (concatenar os 2 discos), vc nao lucra nem com performance no ZFS (pois ele tem todo uma parafernalha de features pra checkar e se preocupar), nem ganhas em segurança dos dados pois isso não é importante (por tratar-se de caches de paginas), por isso posso te afirmar que trocando pra GEOM ou simplesmente deixando os HDs isoladamente (cada um com a sua particao de 1GB) será mais rapido que com o ZFS. Eu acho que descobri o problema, aumentei os FDs no sysctl para um valor absurdo e testei com o polygraph e parece que deu um bom resultado. Com a tua quantidade de RAM pode abusar de FDs a vontade... heheheh Ajustasse também o kern.maxfilesperproc? Ele é quem vai limitar o máximo do squid. Uma coisa que percebi tb, que quando deixo ativo o cachevideo e quando fiz o teste sem ele com o polygraph consegui trafego de 100Mbps e quando habilitava ele punha o lusca a 100% na cpu e passava 40Mbps, depois da alteração do FD, testando com um indice REQ de 500/seg Estou aguardando chegar a hora fatídica para ver se resolveu realmente, pois o problema só dá quando o volume de usuários aumenta, no fim do dia e dura esse sofrimento durante uma hora +/- e depois volta ao normal. Apesar de eu ter falando um monte sobre ZFS, com os dados que vc forneceu, eu acredito que o problema não se encontra em disco, pois até minha pendrive paraguation consegue bater esses apenas 40Mbps (5MB/s). É muito pouco. Meu chute é interrupções em placa de rede. Pra resolver esse seu problema de performance você tem que mitigar o comportamento do sistema e identificar o gargalo. Genericamente falando podem ser 3 coisas: disco, cpu ou interrupcoes. Sugiro que você comece brincando com 2 utilitarios básicos do sistema: top -S -C systat -vmstat Tente descobrir qual deles está comendo mais recursos. []s Nilson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: Problemas com cache usando Lusca e freebsd 8.0 64bts
abaixar esse cache mem ai pra 512mb ... que resolve ! 2010/5/6 Nilson nil...@forge.com.br: Em 5 de maio de 2010 14:41, Joao Pedro Paula Pannain Souza jp.pann...@gmail.com escreveu: Oi Pessoal, Bom dia. Ela tem 8Gb de Ram, mas estamos subindo ela para 12Gb. É um Servidor DELL Xeon Dual 3000 GHz, com 2 hd sata de 1 tera e 1 hd scsi com o BSD, nos satas estamos usando ZFS, porem ainda dividindo 1T para cache e 1T pra video. A máquina me parece bastante superior para essa tarefa, que mal lhe pergunte, qual é o seu link atual e qual o máximo de clientes trafegando ao mesmo tempo que você tem visto? Quanto ao ZFS, eu o considero uma má escolha para essa finalidade, pois com essa quantidade de discos (apenas 2) ele será bem mais lento que um GEOM. Você ganha velocidade com ZFS tendo muitos HDs, muita RAM pra caches, dispositivos intermediarios de cache, por ai vai, e ganhas tranquilidade com a segurança dos teus dados usando um raidz2 pois é muito seguro e a manipulação dos pools de discos é um mumu. No seu caso de usar um simples stripping (concatenar os 2 discos), vc nao lucra nem com performance no ZFS (pois ele tem todo uma parafernalha de features pra checkar e se preocupar), nem ganhas em segurança dos dados pois isso não é importante (por tratar-se de caches de paginas), por isso posso te afirmar que trocando pra GEOM ou simplesmente deixando os HDs isoladamente (cada um com a sua particao de 1GB) será mais rapido que com o ZFS. Eu acho que descobri o problema, aumentei os FDs no sysctl para um valor absurdo e testei com o polygraph e parece que deu um bom resultado. Com a tua quantidade de RAM pode abusar de FDs a vontade... heheheh Ajustasse também o kern.maxfilesperproc? Ele é quem vai limitar o máximo do squid. Uma coisa que percebi tb, que quando deixo ativo o cachevideo e quando fiz o teste sem ele com o polygraph consegui trafego de 100Mbps e quando habilitava ele punha o lusca a 100% na cpu e passava 40Mbps, depois da alteração do FD, testando com um indice REQ de 500/seg Estou aguardando chegar a hora fatídica para ver se resolveu realmente, pois o problema só dá quando o volume de usuários aumenta, no fim do dia e dura esse sofrimento durante uma hora +/- e depois volta ao normal. Apesar de eu ter falando um monte sobre ZFS, com os dados que vc forneceu, eu acredito que o problema não se encontra em disco, pois até minha pendrive paraguation consegue bater esses apenas 40Mbps (5MB/s). É muito pouco. Meu chute é interrupções em placa de rede. Pra resolver esse seu problema de performance você tem que mitigar o comportamento do sistema e identificar o gargalo. Genericamente falando podem ser 3 coisas: disco, cpu ou interrupcoes. Sugiro que você comece brincando com 2 utilitarios básicos do sistema: top -S -C systat -vmstat Tente descobrir qual deles está comendo mais recursos. []s Nilson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Sds. Alexandre J. Correa Onda Internet http://www.onda.net.br IPV6 Ready !!! http://ipv6.onda.net.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
