[FUG-BR] squid -k reconfigure demorando muito
E ae galera. Estou usando o squid 3.1 (Squid Cache: Version 3.1.10) em um FreeBSD amd64 (FreeBSD proxy4.copanet.copasa 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64), Com 8GB de RAM e um hw.model: Intel(R) Xeon(R) CPU 5130 @ 2.00GHZ quadcore. Meu squie é autenticado com o AD através do ntlm_smb_lm_auth. Antigamente eu tinha nesse mesmo Hardware, além do Squid 3.1 autenticado com o AD da mesma forma que hoje, um FreeBSD 8.2 só que 32 bits(mudei para amd64 para poder aproveitar melhor os recursos ). Quando eu executava um squid - k reconfigure demorava certa de 10 segundos para o proxy voltar a funcionar e o povo a navegar. Hoje, quando executo o mesmo squid -k reconfigure demora quase 7 minutos para voltar o squid e a navegação. Tem demorado muito mesmo e a unica coisa que mudou foi a arquitetura do sistema operacional. Alguém sabe me dizer se é algum problema da arquitetura? Tem alguma coisa que eu possa fazer para diminuir esse tempo ? Obritado desde já! -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
alessandro@proxy:/home/alessandro squid -v Squid Cache: Version 3.1.12 olha o tamanho do cache ou cache_mem. Em 26 de abril de 2012 09:12, Saul Figueiredo saulfelip...@gmail.com escreveu: E ae galera. Estou usando o squid 3.1 (Squid Cache: Version 3.1.10) em um FreeBSD amd64 (FreeBSD proxy4.copanet.copasa 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64), Com 8GB de RAM e um hw.model: Intel(R) Xeon(R) CPU 5130 @ 2.00GHZ quadcore. Meu squie é autenticado com o AD através do ntlm_smb_lm_auth. Antigamente eu tinha nesse mesmo Hardware, além do Squid 3.1 autenticado com o AD da mesma forma que hoje, um FreeBSD 8.2 só que 32 bits(mudei para amd64 para poder aproveitar melhor os recursos ). Quando eu executava um squid - k reconfigure demorava certa de 10 segundos para o proxy voltar a funcionar e o povo a navegar. Hoje, quando executo o mesmo squid -k reconfigure demora quase 7 minutos para voltar o squid e a navegação. Tem demorado muito mesmo e a unica coisa que mudou foi a arquitetura do sistema operacional. Alguém sabe me dizer se é algum problema da arquitetura? Tem alguma coisa que eu possa fazer para diminuir esse tempo ? Obritado desde já! -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Alessandro de Souza Rocha Administrador de Redes e Sistemas FreeBSD-BR User #117 Long live FreeBSD Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Em 26 de abril de 2012 10:01, Alessandro de Souza Rocha etherlin...@gmail.com escreveu: alessandro@proxy:/home/alessandro squid -v Squid Cache: Version 3.1.12 olha o tamanho do cache ou cache_mem. Em 26 de abril de 2012 09:12, Saul Figueiredo saulfelip...@gmail.com escreveu: E ae galera. Estou usando o squid 3.1 (Squid Cache: Version 3.1.10) em um FreeBSD amd64 (FreeBSD proxy4.copanet.copasa 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64), Com 8GB de RAM e um hw.model: Intel(R) Xeon(R) CPU 5130 @ 2.00GHZ quadcore. Meu squie é autenticado com o AD através do ntlm_smb_lm_auth. Antigamente eu tinha nesse mesmo Hardware, além do Squid 3.1 autenticado com o AD da mesma forma que hoje, um FreeBSD 8.2 só que 32 bits(mudei para amd64 para poder aproveitar melhor os recursos ). Quando eu executava um squid - k reconfigure demorava certa de 10 segundos para o proxy voltar a funcionar e o povo a navegar. Hoje, quando executo o mesmo squid -k reconfigure demora quase 7 minutos para voltar o squid e a navegação. Tem demorado muito mesmo e a unica coisa que mudou foi a arquitetura do sistema operacional. Alguém sabe me dizer se é algum problema da arquitetura? Tem alguma coisa que eu possa fazer para diminuir esse tempo ? Obritado desde já! -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Alessandro de Souza Rocha Administrador de Redes e Sistemas FreeBSD-BR User #117 Long live FreeBSD Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB Creio que não esteja errado, o que você acha? é o mesmo arquivo de configuração de quando eu usava Free 32btis e era rapidão. -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
tem um historico seu na lista, falando justamente sobre squid em 64 bits vc deveria da uma olhada porque seu cache_mem pode esta com memoria a mais. How much memory do I need in my Squid server? As a rule of thumb on Squid uses approximately 10 MB of RAM per GB of the total of all cache_dirs (more on 64 bit servers such as Alpha), plus your cache_mem setting and about an additional 10-20MB. It is recommended to have at least twice this amount of physical RAM available on your Squid server. For a more detailed discussion on Squid's memory usage see the sections above. The recommended extra RAM besides what is used by Squid is used by the operating system to improve disk I/O performance and by other applications or services running on the server. This will be true even of a server which runs Squid as the only tcp service, since there is a minimum level of memory needed for process management, logging, and other OS level routines. If you have a low memory server, and a large disk, then you will not necessarily be able to use all the disk space, since as the cache fills the memory available will be insufficient, forcing Squid to swap out memory and affecting performance. A very large cache_dir total and insufficient physical RAM + Swap could cause Squid to stop functioning completely. The solution for larger caches is to get more physical RAM; allocating more to Squid via cache_mem will not help. Ex: vamos dizer que você tenha no cache_dirs definido 100G de espaço. Logo em sistemas 32bits squid usa uns 10Mb por giga em 64bits uns 16Mb por giga. Vamos dizer que no seu cache_mem esteja com 256M logo a fórmula seria algo assim: - 100Gb de espaço no cache_dirs - 10Mb por cada giga dos 100Gb do cache_dirs em sistemas 32bits, em 64bits eu colocaria 16Mb por cada giga. - 256Mb de cache_mem - 20Mb adicional sugerido para o cálculo. Conta: 100 * 10 = 1000Mb + 256M + 20M = 1276Mb onde vc deveria ter de ram pelo menos o dobro desse valor, ou seja, você teria que ter na máquina 2552Mb. Repare que se você aumenta um valor o outro também é ajustado e eles são interligados. Em 26 de abril de 2012 10:04, Saul Figueiredo saulfelip...@gmail.com escreveu: Em 26 de abril de 2012 10:01, Alessandro de Souza Rocha etherlin...@gmail.com escreveu: alessandro@proxy:/home/alessandro squid -v Squid Cache: Version 3.1.12 olha o tamanho do cache ou cache_mem. Em 26 de abril de 2012 09:12, Saul Figueiredo saulfelip...@gmail.com escreveu: E ae galera. Estou usando o squid 3.1 (Squid Cache: Version 3.1.10) em um FreeBSD amd64 (FreeBSD proxy4.copanet.copasa 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64), Com 8GB de RAM e um hw.model: Intel(R) Xeon(R) CPU 5130 @ 2.00GHZ quadcore. Meu squie é autenticado com o AD através do ntlm_smb_lm_auth. Antigamente eu tinha nesse mesmo Hardware, além do Squid 3.1 autenticado com o AD da mesma forma que hoje, um FreeBSD 8.2 só que 32 bits(mudei para amd64 para poder aproveitar melhor os recursos ). Quando eu executava um squid - k reconfigure demorava certa de 10 segundos para o proxy voltar a funcionar e o povo a navegar. Hoje, quando executo o mesmo squid -k reconfigure demora quase 7 minutos para voltar o squid e a navegação. Tem demorado muito mesmo e a unica coisa que mudou foi a arquitetura do sistema operacional. Alguém sabe me dizer se é algum problema da arquitetura? Tem alguma coisa que eu possa fazer para diminuir esse tempo ? Obritado desde já! -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Alessandro de Souza Rocha Administrador de Redes e Sistemas FreeBSD-BR User #117 Long live FreeBSD Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB Creio que não esteja errado, o que você acha? é o mesmo arquivo de configuração de quando eu usava Free 32btis e era rapidão. -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com
Re: [FUG-BR] squid -k reconfigure demorando muito
Em 26 de abril de 2012 10:08, Alessandro de Souza Rocha etherlin...@gmail.com escreveu: tem um historico seu na lista, falando justamente sobre squid em 64 bits vc deveria da uma olhada porque seu cache_mem pode esta com memoria a mais. How much memory do I need in my Squid server? As a rule of thumb on Squid uses approximately 10 MB of RAM per GB of the total of all cache_dirs (more on 64 bit servers such as Alpha), plus your cache_mem setting and about an additional 10-20MB. It is recommended to have at least twice this amount of physical RAM available on your Squid server. For a more detailed discussion on Squid's memory usage see the sections above. The recommended extra RAM besides what is used by Squid is used by the operating system to improve disk I/O performance and by other applications or services running on the server. This will be true even of a server which runs Squid as the only tcp service, since there is a minimum level of memory needed for process management, logging, and other OS level routines. If you have a low memory server, and a large disk, then you will not necessarily be able to use all the disk space, since as the cache fills the memory available will be insufficient, forcing Squid to swap out memory and affecting performance. A very large cache_dir total and insufficient physical RAM + Swap could cause Squid to stop functioning completely. The solution for larger caches is to get more physical RAM; allocating more to Squid via cache_mem will not help. Ex: vamos dizer que você tenha no cache_dirs definido 100G de espaço. Logo em sistemas 32bits squid usa uns 10Mb por giga em 64bits uns 16Mb por giga. Vamos dizer que no seu cache_mem esteja com 256M logo a fórmula seria algo assim: - 100Gb de espaço no cache_dirs - 10Mb por cada giga dos 100Gb do cache_dirs em sistemas 32bits, em 64bits eu colocaria 16Mb por cada giga. - 256Mb de cache_mem - 20Mb adicional sugerido para o cálculo. Conta: 100 * 10 = 1000Mb + 256M + 20M = 1276Mb onde vc deveria ter de ram pelo menos o dobro desse valor, ou seja, você teria que ter na máquina 2552Mb. Repare que se você aumenta um valor o outro também é ajustado e eles são interligados. Em 26 de abril de 2012 10:04, Saul Figueiredo saulfelip...@gmail.com escreveu: Em 26 de abril de 2012 10:01, Alessandro de Souza Rocha etherlin...@gmail.com escreveu: alessandro@proxy:/home/alessandro squid -v Squid Cache: Version 3.1.12 olha o tamanho do cache ou cache_mem. Em 26 de abril de 2012 09:12, Saul Figueiredo saulfelip...@gmail.com escreveu: E ae galera. Estou usando o squid 3.1 (Squid Cache: Version 3.1.10) em um FreeBSD amd64 (FreeBSD proxy4.copanet.copasa 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64), Com 8GB de RAM e um hw.model: Intel(R) Xeon(R) CPU 5130 @ 2.00GHZ quadcore. Meu squie é autenticado com o AD através do ntlm_smb_lm_auth. Antigamente eu tinha nesse mesmo Hardware, além do Squid 3.1 autenticado com o AD da mesma forma que hoje, um FreeBSD 8.2 só que 32 bits(mudei para amd64 para poder aproveitar melhor os recursos ). Quando eu executava um squid - k reconfigure demorava certa de 10 segundos para o proxy voltar a funcionar e o povo a navegar. Hoje, quando executo o mesmo squid -k reconfigure demora quase 7 minutos para voltar o squid e a navegação. Tem demorado muito mesmo e a unica coisa que mudou foi a arquitetura do sistema operacional. Alguém sabe me dizer se é algum problema da arquitetura? Tem alguma coisa que eu possa fazer para diminuir esse tempo ? Obritado desde já! -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- Alessandro de Souza Rocha Administrador de Redes e Sistemas FreeBSD-BR User #117 Long live FreeBSD Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB Creio que não esteja errado, o que você acha? é o mesmo arquivo de configuração de quando eu usava Free 32btis e era
Re: [FUG-BR] squid -k reconfigure demorando muito
Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe -- João Martins Eng. Resp. Suporte Técnico Construimos Wireless Networks desde '97 Serviços para ISP desde '93 http://info.matik.com.br signature.asc Description: OpenPGP digital signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Em 26 de abril de 2012 15:37, Asstec ass...@matik.com.br escreveu: Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe -- João Martins Eng. Resp. Suporte Técnico Construimos Wireless Networks desde '97 Serviços para ISP desde '93 http://info.matik.com.br Boa tarde. Fiz o que o Asstec falou e basicamente acontece isso: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) 2012/04/26 15:36:26| Starting Squid Cache version 3.1.10 for amd64-portbld-freebsd8.2... 2012/04/26 15:36:26| Process ID 8735 2012/04/26 15:36:26| With 65536 file descriptors available 2012/04/26 15:36:26| Initializing IP Cache... 2012/04/26 15:36:26| DNS Socket created at [::], FD 7 2012/04/26 15:36:26| DNS Socket created at 0.0.0.0, FD 8 2012/04/26 15:36:26| Adding domain copanet.copasa from /etc/resolv.conf 2012/04/26 15:36:26| Adding nameserver 10.1.1.4 from /etc/resolv.conf 2012/04/26 15:36:26| Adding nameserver 10.1.1.5 from /etc/resolv.conf 2012/04/26 15:36:26| Adding nameserver 200.216.236.33 from /etc/resolv.conf 2012/04/26 15:36:26| helperOpenServers: Starting 100/100 'ntlm_smb_lm_auth' processes 2012/04/26 15:36:26| helperOpenServers: Starting 2/2 'ntlm_smb_lm_auth' processes 2012/04/26 15:36:26| Unlinkd pipe opened on FD 217 2012/04/26 15:36:26| Store logging disabled 2012/04/26 15:36:26| Swap maxSize 19456000 + 593920 KB, estimated 1542301 objects 2012/04/26 15:36:26| Target number of buckets: 77115 2012/04/26 15:36:26| Using 131072 Store buckets 2012/04/26 15:36:26| Max Mem size: 593920 KB 2012/04/26 15:36:26| Max Swap size: 19456000 KB 2012/04/26 15:36:26| Version 1 of swap file with LFS support detected... 2012/04/26 15:36:26| Rebuilding storage in /sarg/cache/ (DIRTY) 2012/04/26 15:36:26| Using Least Load store dir selection 2012/04/26 15:36:26| Set Current Directory to /sarg 2012/04/26 15:36:26| Loaded Icons. 2012/04/26 15:36:26| Accepting HTTP connections at [::]:3128, FD 220. 2012/04/26 15:36:26| HTCP Disabled. 2012/04/26 15:36:26| Configuring Parent 200.216.236.2/8080/0 2012/04/26 15:36:26| Configuring Parent 200.216.236.36/8080/0 2012/04/26 15:36:26| Ready to serve requests. 2012/04/26 15:36:26| Store rebuilding is 0.37% complete 2012/04/26 15:36:34| Done reading /sarg/cache/ swaplog (1115763 entries) 2012/04/26 15:36:34| Finished rebuilding storage from disk. 2012/04/26 15:36:34| 1026071 Entries scanned 2012/04/26 15:36:34| 0 Invalid entries. 2012/04/26 15:36:34| 0 With invalid flags. 2012/04/26 15:36:34|936950 Objects loaded. 2012/04/26 15:36:34| 0 Objects expired. 2012/04/26 15:36:34| 89121 Objects cancelled. 2012/04/26 15:36:34| 0 Duplicate URLs purged. 2012/04/26 15:36:34| 0 Swapfile clashes avoided. 2012/04/26 15:36:34| Took 7.16 seconds (130813.63 objects/sec). 2012/04/26 15:36:34| Beginning Validation Procedure 2012/04/26 15:36:34| 262144 Entries Validated so far. 2012/04/26 15:36:34| 1048576 Entries Validated so far. 2012/04/26 15:36:34| Completed Validation Procedure 2012/04/26 15:36:34| Validated 1873915 Entries 2012/04/26 15:36:34| store_swap_size = 17512134 2012/04/26 15:36:34| storeLateRelease: released 0 objects 2012/04/26 15:36:34| comm_old_accept: FD 220: (53) Software caused connection abort 2012/04/26 15:36:34| httpAccept: FD 220: accept failure: (53) Software caused connection abort Creio que esse fget error seja normal, afinal no meu outro proxy aqui, que é 32bits acontece o mesmo e faz o -k reconfigure rapidão. Acontece isso no seu também ? -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Em 26/04/2012 15:37, Asstec escreveu: Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas Só pra constar aquele cálculo que sugeriram é desse cara aqui que misturou as bolas: http://wiki.squid-cache.org/SquidFaq/SquidMemory#how-much-ram Agora você dizer que os devs do squid confundiram o cálculo é complicado. rsrsrsr Outra coisa esse cálculo faz muta diferença e se fizer à bangú vai ter muitos problemas, sei porque já tive. Posso te dizer porque meu cache segurava link de 300Mbps e não é pouca coisa não. Hoje temos link de 1TBps. Não estou dizendo que esse possa ser o problema do nosso amigo, mesmo porque concordo com você em 2 coisas: ele precisa checar nos logs porque pode ter a dica lá e realmente ser i386 ou amd64 não teria nada à ver. Outra coisa dá uma olhada em todos os logs não só os squid, checa inclusive os discos pra ver se não está tendo problema com eles. Se puder dá um boot entra em single e passa um fsck nas partições também. Bem são algumas idéias. aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe - 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] squid -k reconfigure demorando muito
Em 26/04/2012 15:59, Marcelo Gondim escreveu: Em 26/04/2012 15:37, Asstec escreveu: Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas Só pra constar aquele cálculo que sugeriram é desse cara aqui que misturou as bolas: http://wiki.squid-cache.org/SquidFaq/SquidMemory#how-much-ram Agora você dizer que os devs do squid confundiram o cálculo é complicado. rsrsrsr Outra coisa esse cálculo faz muta diferença e se fizer à bangú vai ter muitos problemas, sei porque já tive. Posso te dizer porque meu cache segurava link de 300Mbps e não é pouca coisa não. Hoje temos link de 1TBps. Não estou dizendo que esse possa ser o problema do nosso Correção: 1Gpbs e não 1Tbps rsrsr um dia quem sabe. Esse tipo de demora que ele está dizendo ainda acho que pode ser algo relacionado com discos, filesystem. amigo, mesmo porque concordo com você em 2 coisas: ele precisa checar nos logs porque pode ter a dica lá e realmente ser i386 ou amd64 não teria nada à ver. Outra coisa dá uma olhada em todos os logs não só os squid, checa inclusive os discos pra ver se não está tendo problema com eles. Se puder dá um boot entra em single e passa um fsck nas partições também. Bem são algumas idéias. aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Em 26 de abril de 2012 16:36, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 26/04/2012 15:59, Marcelo Gondim escreveu: Em 26/04/2012 15:37, Asstec escreveu: Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas Só pra constar aquele cálculo que sugeriram é desse cara aqui que misturou as bolas: http://wiki.squid-cache.org/SquidFaq/SquidMemory#how-much-ram Agora você dizer que os devs do squid confundiram o cálculo é complicado. rsrsrsr Outra coisa esse cálculo faz muta diferença e se fizer à bangú vai ter muitos problemas, sei porque já tive. Posso te dizer porque meu cache segurava link de 300Mbps e não é pouca coisa não. Hoje temos link de 1TBps. Não estou dizendo que esse possa ser o problema do nosso Correção: 1Gpbs e não 1Tbps rsrsr um dia quem sabe. Esse tipo de demora que ele está dizendo ainda acho que pode ser algo relacionado com discos, filesystem. amigo, mesmo porque concordo com você em 2 coisas: ele precisa checar nos logs porque pode ter a dica lá e realmente ser i386 ou amd64 não teria nada à ver. Outra coisa dá uma olhada em todos os logs não só os squid, checa inclusive os discos pra ver se não está tendo problema com eles. Se puder dá um boot entra em single e passa um fsck nas partições também. Bem são algumas idéias. aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo valew pela dica, mas não creio que seja. Fiz um teste com o iops, veja o resultado: proxy4# ./iops -n 8 -t 2 /dev/mfid0 /dev/mfid0, 299.44 GB, 8 threads: 512 B blocks: 76.3 IO/s, 38.1 KiB/s (312.4 kbit/s) 1 KiB blocks: 189.0 IO/s, 189.0 KiB/s ( 1.5 Mbit/s) 2 KiB blocks: 191.5 IO/s, 383.0 KiB/s ( 3.1 Mbit/s) 4 KiB blocks: 205.1 IO/s, 820.4 KiB/s ( 6.7 Mbit/s) 8 KiB blocks: 99.9 IO/s, 799.1 KiB/s ( 6.5 Mbit/s) 16 KiB blocks: 50.9 IO/s, 814.5 KiB/s ( 6.7 Mbit/s) 32 KiB blocks: 16.9 IO/s, 540.6 KiB/s ( 4.4 Mbit/s) 64 KiB blocks: 13.9 IO/s, 890.9 KiB/s ( 7.3 Mbit/s) 128 KiB blocks:8.4 IO/s, 1.0 MiB/s ( 8.8 Mbit/s) 256 KiB blocks:3.5 IO/s, 883.5 KiB/s ( 7.2 Mbit/s) -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
2012/04/26 15:36:26| Rebuilding storage in /sarg/cache/ (DIRTY) seu processo nao foi finalizado corretamente, entao ele vai fazer a leitura novamente da estrutura do cache_dir e sincronizar com o que ele tem no squid.swap (algo assim) ... 2012/4/26 Saul Figueiredo saulfelip...@gmail.com: Em 26 de abril de 2012 16:36, Marcelo Gondim gon...@bsdinfo.com.brescreveu: Em 26/04/2012 15:59, Marcelo Gondim escreveu: Em 26/04/2012 15:37, Asstec escreveu: Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas Só pra constar aquele cálculo que sugeriram é desse cara aqui que misturou as bolas: http://wiki.squid-cache.org/SquidFaq/SquidMemory#how-much-ram Agora você dizer que os devs do squid confundiram o cálculo é complicado. rsrsrsr Outra coisa esse cálculo faz muta diferença e se fizer à bangú vai ter muitos problemas, sei porque já tive. Posso te dizer porque meu cache segurava link de 300Mbps e não é pouca coisa não. Hoje temos link de 1TBps. Não estou dizendo que esse possa ser o problema do nosso Correção: 1Gpbs e não 1Tbps rsrsr um dia quem sabe. Esse tipo de demora que ele está dizendo ainda acho que pode ser algo relacionado com discos, filesystem. amigo, mesmo porque concordo com você em 2 coisas: ele precisa checar nos logs porque pode ter a dica lá e realmente ser i386 ou amd64 não teria nada à ver. Outra coisa dá uma olhada em todos os logs não só os squid, checa inclusive os discos pra ver se não está tendo problema com eles. Se puder dá um boot entra em single e passa um fsck nas partições também. Bem são algumas idéias. aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo valew pela dica, mas não creio que seja. Fiz um teste com o iops, veja o resultado: proxy4# ./iops -n 8 -t 2 /dev/mfid0 /dev/mfid0, 299.44 GB, 8 threads: 512 B blocks: 76.3 IO/s, 38.1 KiB/s (312.4 kbit/s) 1 KiB blocks: 189.0 IO/s, 189.0 KiB/s ( 1.5 Mbit/s) 2 KiB blocks: 191.5 IO/s, 383.0 KiB/s ( 3.1 Mbit/s) 4 KiB blocks: 205.1 IO/s, 820.4 KiB/s ( 6.7 Mbit/s) 8 KiB blocks: 99.9 IO/s, 799.1 KiB/s ( 6.5 Mbit/s) 16 KiB blocks: 50.9 IO/s, 814.5 KiB/s ( 6.7 Mbit/s) 32 KiB blocks: 16.9 IO/s, 540.6 KiB/s ( 4.4 Mbit/s) 64 KiB blocks: 13.9 IO/s, 890.9 KiB/s ( 7.3 Mbit/s) 128 KiB blocks: 8.4 IO/s, 1.0 MiB/s ( 8.8 Mbit/s) 256 KiB blocks: 3.5 IO/s, 883.5 KiB/s ( 7.2 Mbit/s) -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - 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
Re: [FUG-BR] squid -k reconfigure demorando muito
Em 26 de abril de 2012 17:03, Alexandre Correa ajcor...@gmail.comescreveu: 2012/04/26 15:36:26| Rebuilding storage in /sarg/cache/ (DIRTY) seu processo nao foi finalizado corretamente, entao ele vai fazer a leitura novamente da estrutura do cache_dir e sincronizar com o que ele tem no squid.swap (algo assim) ... 2012/4/26 Saul Figueiredo saulfelip...@gmail.com: Em 26 de abril de 2012 16:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 26/04/2012 15:59, Marcelo Gondim escreveu: Em 26/04/2012 15:37, Asstec escreveu: Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas Só pra constar aquele cálculo que sugeriram é desse cara aqui que misturou as bolas: http://wiki.squid-cache.org/SquidFaq/SquidMemory#how-much-ram Agora você dizer que os devs do squid confundiram o cálculo é complicado. rsrsrsr Outra coisa esse cálculo faz muta diferença e se fizer à bangú vai ter muitos problemas, sei porque já tive. Posso te dizer porque meu cache segurava link de 300Mbps e não é pouca coisa não. Hoje temos link de 1TBps. Não estou dizendo que esse possa ser o problema do nosso Correção: 1Gpbs e não 1Tbps rsrsr um dia quem sabe. Esse tipo de demora que ele está dizendo ainda acho que pode ser algo relacionado com discos, filesystem. amigo, mesmo porque concordo com você em 2 coisas: ele precisa checar nos logs porque pode ter a dica lá e realmente ser i386 ou amd64 não teria nada à ver. Outra coisa dá uma olhada em todos os logs não só os squid, checa inclusive os discos pra ver se não está tendo problema com eles. Se puder dá um boot entra em single e passa um fsck nas partições também. Bem são algumas idéias. aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo valew pela dica, mas não creio que seja. Fiz um teste com o iops, veja o resultado: proxy4# ./iops -n 8 -t 2 /dev/mfid0 /dev/mfid0, 299.44 GB, 8 threads: 512 B blocks: 76.3 IO/s, 38.1 KiB/s (312.4 kbit/s) 1 KiB blocks: 189.0 IO/s, 189.0 KiB/s ( 1.5 Mbit/s) 2 KiB blocks: 191.5 IO/s, 383.0 KiB/s ( 3.1 Mbit/s) 4 KiB blocks: 205.1 IO/s, 820.4 KiB/s ( 6.7 Mbit/s) 8 KiB blocks: 99.9 IO/s, 799.1 KiB/s ( 6.5 Mbit/s) 16 KiB blocks: 50.9 IO/s, 814.5 KiB/s ( 6.7 Mbit/s) 32 KiB blocks: 16.9 IO/s, 540.6 KiB/s ( 4.4 Mbit/s) 64 KiB blocks: 13.9 IO/s, 890.9 KiB/s ( 7.3 Mbit/s) 128 KiB blocks:8.4 IO/s, 1.0 MiB/s ( 8.8 Mbit/s) 256 KiB blocks:3.5 IO/s, 883.5 KiB/s ( 7.2 Mbit/s) -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - 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 Mas isso foi o que saiu do meu squid -k reconfigure. seria um problema ? -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
sim, pode estar demorando porque ele esta fazendo o rebuild do storage ... 2012/4/26 Saul Figueiredo saulfelip...@gmail.com: Em 26 de abril de 2012 17:03, Alexandre Correa ajcor...@gmail.comescreveu: 2012/04/26 15:36:26| Rebuilding storage in /sarg/cache/ (DIRTY) seu processo nao foi finalizado corretamente, entao ele vai fazer a leitura novamente da estrutura do cache_dir e sincronizar com o que ele tem no squid.swap (algo assim) ... 2012/4/26 Saul Figueiredo saulfelip...@gmail.com: Em 26 de abril de 2012 16:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 26/04/2012 15:59, Marcelo Gondim escreveu: Em 26/04/2012 15:37, Asstec escreveu: Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas Só pra constar aquele cálculo que sugeriram é desse cara aqui que misturou as bolas: http://wiki.squid-cache.org/SquidFaq/SquidMemory#how-much-ram Agora você dizer que os devs do squid confundiram o cálculo é complicado. rsrsrsr Outra coisa esse cálculo faz muta diferença e se fizer à bangú vai ter muitos problemas, sei porque já tive. Posso te dizer porque meu cache segurava link de 300Mbps e não é pouca coisa não. Hoje temos link de 1TBps. Não estou dizendo que esse possa ser o problema do nosso Correção: 1Gpbs e não 1Tbps rsrsr um dia quem sabe. Esse tipo de demora que ele está dizendo ainda acho que pode ser algo relacionado com discos, filesystem. amigo, mesmo porque concordo com você em 2 coisas: ele precisa checar nos logs porque pode ter a dica lá e realmente ser i386 ou amd64 não teria nada à ver. Outra coisa dá uma olhada em todos os logs não só os squid, checa inclusive os discos pra ver se não está tendo problema com eles. Se puder dá um boot entra em single e passa um fsck nas partições também. Bem são algumas idéias. aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo valew pela dica, mas não creio que seja. Fiz um teste com o iops, veja o resultado: proxy4# ./iops -n 8 -t 2 /dev/mfid0 /dev/mfid0, 299.44 GB, 8 threads: 512 B blocks: 76.3 IO/s, 38.1 KiB/s (312.4 kbit/s) 1 KiB blocks: 189.0 IO/s, 189.0 KiB/s ( 1.5 Mbit/s) 2 KiB blocks: 191.5 IO/s, 383.0 KiB/s ( 3.1 Mbit/s) 4 KiB blocks: 205.1 IO/s, 820.4 KiB/s ( 6.7 Mbit/s) 8 KiB blocks: 99.9 IO/s, 799.1 KiB/s ( 6.5 Mbit/s) 16 KiB blocks: 50.9 IO/s, 814.5 KiB/s ( 6.7 Mbit/s) 32 KiB blocks: 16.9 IO/s, 540.6 KiB/s ( 4.4 Mbit/s) 64 KiB blocks: 13.9 IO/s, 890.9 KiB/s ( 7.3 Mbit/s) 128 KiB blocks: 8.4 IO/s, 1.0 MiB/s ( 8.8 Mbit/s) 256 KiB blocks: 3.5 IO/s, 883.5 KiB/s ( 7.2 Mbit/s) -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - 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 Mas isso foi o que saiu do meu squid -k reconfigure. seria um problema ? -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - 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
Re: [FUG-BR] squid -k reconfigure demorando muito
Em 26 de abril de 2012 17:39, Alexandre Correa ajcor...@gmail.comescreveu: sim, pode estar demorando porque ele esta fazendo o rebuild do storage ... 2012/4/26 Saul Figueiredo saulfelip...@gmail.com: Em 26 de abril de 2012 17:03, Alexandre Correa ajcor...@gmail.com escreveu: 2012/04/26 15:36:26| Rebuilding storage in /sarg/cache/ (DIRTY) seu processo nao foi finalizado corretamente, entao ele vai fazer a leitura novamente da estrutura do cache_dir e sincronizar com o que ele tem no squid.swap (algo assim) ... 2012/4/26 Saul Figueiredo saulfelip...@gmail.com: Em 26 de abril de 2012 16:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 26/04/2012 15:59, Marcelo Gondim escreveu: Em 26/04/2012 15:37, Asstec escreveu: Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas Só pra constar aquele cálculo que sugeriram é desse cara aqui que misturou as bolas: http://wiki.squid-cache.org/SquidFaq/SquidMemory#how-much-ram Agora você dizer que os devs do squid confundiram o cálculo é complicado. rsrsrsr Outra coisa esse cálculo faz muta diferença e se fizer à bangú vai ter muitos problemas, sei porque já tive. Posso te dizer porque meu cache segurava link de 300Mbps e não é pouca coisa não. Hoje temos link de 1TBps. Não estou dizendo que esse possa ser o problema do nosso Correção: 1Gpbs e não 1Tbps rsrsr um dia quem sabe. Esse tipo de demora que ele está dizendo ainda acho que pode ser algo relacionado com discos, filesystem. amigo, mesmo porque concordo com você em 2 coisas: ele precisa checar nos logs porque pode ter a dica lá e realmente ser i386 ou amd64 não teria nada à ver. Outra coisa dá uma olhada em todos os logs não só os squid, checa inclusive os discos pra ver se não está tendo problema com eles. Se puder dá um boot entra em single e passa um fsck nas partições também. Bem são algumas idéias. aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo valew pela dica, mas não creio que seja. Fiz um teste com o iops, veja o resultado: proxy4# ./iops -n 8 -t 2 /dev/mfid0 /dev/mfid0, 299.44 GB, 8 threads: 512 B blocks: 76.3 IO/s, 38.1 KiB/s (312.4 kbit/s) 1 KiB blocks: 189.0 IO/s, 189.0 KiB/s ( 1.5 Mbit/s) 2 KiB blocks: 191.5 IO/s, 383.0 KiB/s ( 3.1 Mbit/s) 4 KiB blocks: 205.1 IO/s, 820.4 KiB/s ( 6.7 Mbit/s) 8 KiB blocks: 99.9 IO/s, 799.1 KiB/s ( 6.5 Mbit/s) 16 KiB blocks: 50.9 IO/s, 814.5 KiB/s ( 6.7 Mbit/s) 32 KiB blocks: 16.9 IO/s, 540.6 KiB/s ( 4.4 Mbit/s) 64 KiB blocks: 13.9 IO/s, 890.9 KiB/s ( 7.3 Mbit/s) 128 KiB blocks:8.4 IO/s, 1.0 MiB/s ( 8.8 Mbit/s) 256 KiB blocks:3.5 IO/s, 883.5 KiB/s ( 7.2 Mbit/s) -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - 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 Mas isso foi o que saiu do meu squid -k reconfigure. seria um problema ? -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com
Re: [FUG-BR] squid -k reconfigure demorando muito
quando ele terminar de fazer o rebuild... e voce precisar desligar o cache.. tente pelo squid -k shutdown e aguarde ele morrer ... qualquer outro metodo (kill) .. vai causar esse 'DIRTY' ai .. 2012/4/26 Saul Figueiredo saulfelip...@gmail.com: Em 26 de abril de 2012 17:39, Alexandre Correa ajcor...@gmail.comescreveu: sim, pode estar demorando porque ele esta fazendo o rebuild do storage ... 2012/4/26 Saul Figueiredo saulfelip...@gmail.com: Em 26 de abril de 2012 17:03, Alexandre Correa ajcor...@gmail.com escreveu: 2012/04/26 15:36:26| Rebuilding storage in /sarg/cache/ (DIRTY) seu processo nao foi finalizado corretamente, entao ele vai fazer a leitura novamente da estrutura do cache_dir e sincronizar com o que ele tem no squid.swap (algo assim) ... 2012/4/26 Saul Figueiredo saulfelip...@gmail.com: Em 26 de abril de 2012 16:36, Marcelo Gondim gon...@bsdinfo.com.br escreveu: Em 26/04/2012 15:59, Marcelo Gondim escreveu: Em 26/04/2012 15:37, Asstec escreveu: Saul Figueiredo wrote: Minhas configurações de cache_dir e cache_men: cache_dir ufs /sarg/cache/ 19000 16 256 cache_mem 1024 MB essas configurações não influenciam em nada na exec do reconf, tanto faz se é i386 ou amd64 esquece aquele cálculo que alguém te sugeriu, que o cara está confundindo e misturando as bolas Só pra constar aquele cálculo que sugeriram é desse cara aqui que misturou as bolas: http://wiki.squid-cache.org/SquidFaq/SquidMemory#how-much-ram Agora você dizer que os devs do squid confundiram o cálculo é complicado. rsrsrsr Outra coisa esse cálculo faz muta diferença e se fizer à bangú vai ter muitos problemas, sei porque já tive. Posso te dizer porque meu cache segurava link de 300Mbps e não é pouca coisa não. Hoje temos link de 1TBps. Não estou dizendo que esse possa ser o problema do nosso Correção: 1Gpbs e não 1Tbps rsrsr um dia quem sabe. Esse tipo de demora que ele está dizendo ainda acho que pode ser algo relacionado com discos, filesystem. amigo, mesmo porque concordo com você em 2 coisas: ele precisa checar nos logs porque pode ter a dica lá e realmente ser i386 ou amd64 não teria nada à ver. Outra coisa dá uma olhada em todos os logs não só os squid, checa inclusive os discos pra ver se não está tendo problema com eles. Se puder dá um boot entra em single e passa um fsck nas partições também. Bem são algumas idéias. aquele cálculo pode estar certo mas emn relação a RAM da máquina e não aos parametros cache_dir e/ou cache_mem esses 19G de cache_dir é nada e um servidor de 8G de RAM com cache_mem 1024 até é muito pouco seu problema de demora está em outro lugar, facilmente descobre dando um tail no squid.log enquanto executa o reconfigure caso não encontra, aumente o debug level e observe - 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Marcelo valew pela dica, mas não creio que seja. Fiz um teste com o iops, veja o resultado: proxy4# ./iops -n 8 -t 2 /dev/mfid0 /dev/mfid0, 299.44 GB, 8 threads: 512 B blocks: 76.3 IO/s, 38.1 KiB/s (312.4 kbit/s) 1 KiB blocks: 189.0 IO/s, 189.0 KiB/s ( 1.5 Mbit/s) 2 KiB blocks: 191.5 IO/s, 383.0 KiB/s ( 3.1 Mbit/s) 4 KiB blocks: 205.1 IO/s, 820.4 KiB/s ( 6.7 Mbit/s) 8 KiB blocks: 99.9 IO/s, 799.1 KiB/s ( 6.5 Mbit/s) 16 KiB blocks: 50.9 IO/s, 814.5 KiB/s ( 6.7 Mbit/s) 32 KiB blocks: 16.9 IO/s, 540.6 KiB/s ( 4.4 Mbit/s) 64 KiB blocks: 13.9 IO/s, 890.9 KiB/s ( 7.3 Mbit/s) 128 KiB blocks: 8.4 IO/s, 1.0 MiB/s ( 8.8 Mbit/s) 256 KiB blocks: 3.5 IO/s, 883.5 KiB/s ( 7.2 Mbit/s) -- Deve-se aprender sempre, até mesmo com um inimigo. (Isaac Newton) Atenciosamente, Saul Figueiredo Analista FreeBSD/Linux Linux Professional Institute Certification Level 2 saulfelip...@gmail.com saul-fel...@hotmail.com - 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 Mas isso foi o que saiu do meu squid -k reconfigure. seria um problema
Re: [FUG-BR] squid -k reconfigure demorando muito
Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) 2012/04/26 15:36:26| Starting Squid Cache version 3.1.10 for amd64-portbld-freebsd8.2... o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? para saber exatamente o que ocorre deve aumentar o debug_level e vê se não me chama pelo meu email e sim pelo meu nome -- João Martins Eng. Resp. Suporte Técnico Construimos Wireless Networks desde '97 Serviços para ISP desde '93 http://www.matik.com.br signature.asc Description: OpenPGP digital signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Em 26 de abril de 2012 18:21, AT Matik TI ass...@matik.com.br escreveu: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) 2012/04/26 15:36:26| Starting Squid Cache version 3.1.10 for amd64-portbld-freebsd8.2... o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? Você não está com bad clusters no seu hd ? -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
On Thursday 26 April 2012 18:21:17 AT Matik TI wrote: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) 2012/04/26 15:36:26| Starting Squid Cache version 3.1.10 for amd64-portbld-freebsd8.2... o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? para saber exatamente o que ocorre deve aumentar o debug_level e vê se não me chama pelo meu email e sim pelo meu nome Saul; Não sei voce ja tentou isso mas voce já experimentou detonar o cache_dir e recriar (squid -z)? A propósito eu uso o lusca. Achei mais estável e rapido. Compilei com suporte a aio. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito (complemento)
On Thursday 26 April 2012 18:21:17 AT Matik TI wrote: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) 2012/04/26 15:36:26| Starting Squid Cache version 3.1.10 for amd64-portbld-freebsd8.2... o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? para saber exatamente o que ocorre deve aumentar o debug_level e vê se não me chama pelo meu email e sim pelo meu nome Saul; Não sei voce ja tentou isso mas voce já experimentou detonar o cache_dir e recriar (squid -z)? A propósito eu uso o lusca. Achei mais estável e rapido. Compilei com suporte a aio. Complemento: Uma coisa que ajuda é dividir o cache dir em secções de 10 giga. Ajuda o squid a fazer o transversing da tree. Ex, cache_dir aufs /squid/1 1 128 512 cache_dir aufs /squid/2 1 128 512 cache_dir aufs /squid/3 1 128 512 cache_dir aufs /squid/4 1 128 512 cache_dir aufs /squid/5 1 128 512 -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Eduardo Schoedler wrote: Em 26 de abril de 2012 18:21, AT Matik TI ass...@matik.com.br escreveu: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) 2012/04/26 15:36:26| Starting Squid Cache version 3.1.10 for amd64-portbld-freebsd8.2... o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? Você não está com bad clusters no seu hd ? engraçadinho vc ... já tem o log na frente mas ainda fica adivinhando sabia que todos os HDs tem bad cluster inclusive os novos? -- João Martins Eng. Resp. Suporte Técnico Construimos Wireless Networks desde '97 Serviços para ISP desde '93 http://www.matik.com.br signature.asc Description: OpenPGP digital signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Mario Lobo wrote: On Thursday 26 April 2012 18:21:17 AT Matik TI wrote: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) 2012/04/26 15:36:26| Starting Squid Cache version 3.1.10 for amd64-portbld-freebsd8.2... o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? para saber exatamente o que ocorre deve aumentar o debug_level e vê se não me chama pelo meu email e sim pelo meu nome Saul; Não sei voce ja tentou isso mas voce já experimentou detonar o cache_dir e recriar (squid -z)? mais um ... mas bem que já disse tudo tentar como que pode dar sugestões estranhas mesmo tendo o problema nítido na frente? -- João Martins Eng. Resp. Suporte Técnico Construimos Wireless Networks desde '97 Serviços para ISP desde '93 http://www.matik.com.br signature.asc Description: OpenPGP digital signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Em 26 de abril de 2012 18:41, AT Matik TI ass...@matik.com.br escreveu: Mario Lobo wrote: On Thursday 26 April 2012 18:21:17 AT Matik TI wrote: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? para saber exatamente o que ocorre deve aumentar o debug_level e vê se não me chama pelo meu email e sim pelo meu nome Saul; Não sei voce ja tentou isso mas voce já experimentou detonar o cache_dir e recriar (squid -z)? mais um ... mas bem que já disse tudo tentar como que pode dar sugestões estranhas mesmo tendo o problema nítido na frente? Tu tá com algum problema? Cara, não tô te entendendo... o pessoal aqui está querendo ajudar por livre e espontânea vontade e tu fica fazendo piadinha ? Te vira aí sozinho com o Google. -- Eduardo Schoedler - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Eduardo Schoedler wrote: Em 26 de abril de 2012 18:41, AT Matik TI ass...@matik.com.br escreveu: Mario Lobo wrote: On Thursday 26 April 2012 18:21:17 AT Matik TI wrote: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? para saber exatamente o que ocorre deve aumentar o debug_level e vê se não me chama pelo meu email e sim pelo meu nome Saul; Não sei voce ja tentou isso mas voce já experimentou detonar o cache_dir e recriar (squid -z)? mais um ... mas bem que já disse tudo tentar como que pode dar sugestões estranhas mesmo tendo o problema nítido na frente? Tu tá com algum problema? Cara, não tô te entendendo... o pessoal aqui está querendo ajudar por livre e espontânea vontade e tu fica fazendo piadinha ? ajudar? enviando pro caminho errado não é ajuda. alias, piadinha é dar sugestões quais nada tem a ver com o problema -- João Martins Eng. Resp. Suporte Técnico Construimos Wireless Networks desde '97 Serviços para ISP desde '93 http://www.matik.com.br signature.asc Description: OpenPGP digital signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
On Thu, 26 Apr 2012 18:21:17 -0300 AT Matik TI ass...@matik.com.br wrote: e vê se não me chama pelo meu email e sim pelo meu nome Bicho, acho que você tá com algum problema mesmo ?!?! --- Luiz Gustavo Costa (Powered by BSD) *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+ mundoUnix - Consultoria em Software Livre http://www.mundounix.com.br ICQ: 2890831 / MSN: cont...@mundounix.com.br Tel: 55 (21) 4063-7110 / 8194-1905 / (11) 4063-0407 Blog: http://www.luizgustavo.pro.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
On Thursday 26 April 2012 18:58:03 AT Matik TI wrote: Eduardo Schoedler wrote: Em 26 de abril de 2012 18:41, AT Matik TI ass...@matik.com.br escreveu: Mario Lobo wrote: On Thursday 26 April 2012 18:21:17 AT Matik TI wrote: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? para saber exatamente o que ocorre deve aumentar o debug_level e vê se não me chama pelo meu email e sim pelo meu nome Saul; Não sei voce ja tentou isso mas voce já experimentou detonar o cache_dir e recriar (squid -z)? mais um ... mas bem que já disse tudo tentar como que pode dar sugestões estranhas mesmo tendo o problema nítido na frente? Tu tá com algum problema? Cara, não tô te entendendo... o pessoal aqui está querendo ajudar por livre e espontânea vontade e tu fica fazendo piadinha ? ajudar? enviando pro caminho errado não é ajuda. alias, piadinha é dar sugestões quais nada tem a ver com o problema Ô microtik, acho que passou da hora do seu rivotril ... E essa sugestão tem tudo a ver com teu problema. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Mario Lobo wrote: On Thursday 26 April 2012 18:58:03 AT Matik TI wrote: Eduardo Schoedler wrote: Em 26 de abril de 2012 18:41, AT Matik TI ass...@matik.com.br escreveu: Mario Lobo wrote: On Thursday 26 April 2012 18:21:17 AT Matik TI wrote: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? para saber exatamente o que ocorre deve aumentar o debug_level e vê se não me chama pelo meu email e sim pelo meu nome Saul; Não sei voce ja tentou isso mas voce já experimentou detonar o cache_dir e recriar (squid -z)? mais um ... mas bem que já disse tudo tentar como que pode dar sugestões estranhas mesmo tendo o problema nítido na frente? Tu tá com algum problema? Cara, não tô te entendendo... o pessoal aqui está querendo ajudar por livre e espontânea vontade e tu fica fazendo piadinha ? ajudar? enviando pro caminho errado não é ajuda. alias, piadinha é dar sugestões quais nada tem a ver com o problema Ô microtik, acho que passou da hora do seu rivotril ... E essa sugestão tem tudo a ver com teu problema. so o tipo da sua resposta já demonstra o tamanho de noção que vc tem do assunto 0 -- João Martins Eng. Resp. Suporte Técnico Construimos Wireless Networks desde '97 Serviços para ISP desde '93 http://www.matik.com.br signature.asc Description: OpenPGP digital signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Moderação de participante (era: squid -k reconfigure demorando muito)
Solicito aos moderadores dar jeito nesse participante da lista. -- Eduardo Schoedler -- Mensagem encaminhada -- De: AT Matik TI ass...@matik.com.br Data: 26 de abril de 2012 19:11 Assunto: Re: [FUG-BR] squid -k reconfigure demorando muito Para: \Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)\ freebsd@fug.com.br Mario Lobo wrote: On Thursday 26 April 2012 18:58:03 AT Matik TI wrote: Eduardo Schoedler wrote: Em 26 de abril de 2012 18:41, AT Matik TI ass...@matik.com.br escreveu: Mario Lobo wrote: On Thursday 26 April 2012 18:21:17 AT Matik TI wrote: Saul Figueiredo wrote: fgets() failed! dying. errno=22 (Unknown error: 0) Repete essa mensagem aqui umas 100 vezes fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=2 (No such file or directory) fgets() failed! dying. errno=22 (Unknown error: 0) fgets() failed! dying. errno=22 (Unknown error: 0) o seu problema ocorre antes dessas linhas, de qq forma um problema conhecido com o squid qd usa ntlm authentication, usa samba tb? para saber exatamente o que ocorre deve aumentar o debug_level e vê se não me chama pelo meu email e sim pelo meu nome Saul; Não sei voce ja tentou isso mas voce já experimentou detonar o cache_dir e recriar (squid -z)? mais um ... mas bem que já disse tudo tentar como que pode dar sugestões estranhas mesmo tendo o problema nítido na frente? Tu tá com algum problema? Cara, não tô te entendendo... o pessoal aqui está querendo ajudar por livre e espontânea vontade e tu fica fazendo piadinha ? ajudar? enviando pro caminho errado não é ajuda. alias, piadinha é dar sugestões quais nada tem a ver com o problema Ô microtik, acho que passou da hora do seu rivotril ... E essa sugestão tem tudo a ver com teu problema. so o tipo da sua resposta já demonstra o tamanho de noção que vc tem do assunto 0 -- João Martins Eng. Resp. Suporte Técnico Construimos Wireless Networks desde '97 Serviços para ISP desde '93 http://www.matik.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Moderação de participante (era: squid -k reconfigure demorando muito)
Eduardo Schoedler wrote: Solicito aos moderadores dar jeito nesse participante da lista. argumento técnico não teve falando besteira não serviu tb não agora chora pro papai? vc é muito competente meu -- João Martins Eng. Resp. Suporte Técnico Construimos Wireless Networks desde '97 Serviços para ISP desde '93 http://www.matik.com.br signature.asc Description: OpenPGP digital signature - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Moderação de participante (era: squid -k reconfigure demorando muito)
On Thursday 26 April 2012 19:20:21 AT Matik TI wrote: Eduardo Schoedler wrote: Solicito aos moderadores dar jeito nesse participante da lista. argumento técnico não teve falando besteira não serviu tb não agora chora pro papai? vc é muito competente meu Rapaz ... doido é melhor agente deixar quieto. É só fazer de conta que ele não tá aqui que ele procura outro lugar pra perturbar. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Meus $0,05. Quando estava acontecendo algo semelhante comigo, detonei o cache, depois squid -z e pronto! Ficou tão rápido quanto uma bala. Mikrotik hahaha! -- Att, Alexandre Silva Nano Tecnólogo em Gestão de Redes de Computadores, UNIFACS Enterasys Security Systems Engineer - IPS/SIEM Enterasys Certified Specialist - NAC www.ideiadigital.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
On Thursday 26 April 2012 20:10:51 Alexandre Silva Nano wrote: Meus $0,05. Quando estava acontecendo algo semelhante comigo, detonei o cache, depois squid -z e pronto! Ficou tão rápido quanto uma bala. Mikrotik hahaha! Que alívio, Alexandre ! Pensei que eu fosse só mais um ... -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since 2.2.8 [not Pro-Audio YET!!] (99% winblows FREE) - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] squid -k reconfigure demorando muito
Vamos ver, vou tentar denotar mais de um cache dir pra ver se melhora. Ja ja eu retorno falando o resultado Em 26/04/2012 20:10, Alexandre Silva Nano alexna...@gmail.com escreveu: Meus $0,05. Quando estava acontecendo algo semelhante comigo, detonei o cache, depois squid -z e pronto! Ficou tão rápido quanto uma bala. Mikrotik hahaha! -- Att, Alexandre Silva Nano Tecnólogo em Gestão de Redes de Computadores, UNIFACS Enterasys Security Systems Engineer - IPS/SIEM Enterasys Certified Specialist - NAC www.ideiadigital.com.br - 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
