Bom dia!
Para minha surpresa migrei os usuário hoje pela manhã e a lentidão
voltou a dar sua cara.
Como essa thread já está se tornando bastante extensa vou resumir o
que foi feito até o momento para que possamos recapitular:
Compilei um kernel novinho no dia 29. Com as opções passadas pelo
Flavio Alexsandro, que foram essas:
Configurações no Kernel:
- Comentar options SCHED_4BSD # 4BSD scheduler
- Adicionar options SCHED_ULE # ULE scheduler
- Comentar options INET6 # IPv6
communications protocols
- Incluir:
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores
- Incluir conf para SMP:
options SMP # Symmetric
MultiProcessor Kernel
- Incluir conf para HZ e Polling:
options HZ=2000
options DEVICE_POLLING # Soft intrrupt's
- Incluir conf para I/O assincrono;
options VFS_AIO
- Incluir conf de shared memory e msg segments:
#
options MAXDSIZ=(4096UL*1024*1024) # Conf para 4Gb
options MAXSSIZ=(256UL*1024*1024) # E aqui vai pra 128
options DFLDSIZ=(4096UL*1024*1024) # 4096 tb!
##
# Message Queues [Based on Squid FAQ]
##
option MSGMNB=262144 # Number of bytes in a queue
option MSGMNI=128 # Need to be at least 2 times
the number of
cache_dir entries in the squid
option MSGSSZ=256 # Size of the message segment
in a queue
option MSGTQL=16384 # Number of max queue
identifiers versus 128
messages per queue (is the high mark of performance of messages per queue)
option MSGSEG=2048 # Number of messages segments
#
##
##
# Shared Memory [Based on Squid FAQ]
##
options SHMMNI=256 # The half of the message
queues at least [1 for
each cache_dir]
options SHMALL=65536 #
options SHMMAX=(128UL*1024*1024) #
options SHMSEG=128
E para encerar no meu squid tenho configurado/sugiro:
- Cache Dir
cache_dir diskd /usr/local/squid/cache/cache1
5120 16 256 Q1=128 Q2=100
cache_dir diskd /usr/local/squid/cache/cache2
5120 16 256 Q1=128 Q2=100
- Sendo que utilizo como cache replacement:
cache_replacement_policy heap LFUDA
- E para memory replacement:
memory_replacement_policy heap GDSF
- Para memory in transit, usaria:
cache_mem 1536 MB
- Sugiro como Low and High mark memory swap:
cache_swap_low 65
cache_swap_high 80
- Sugestao de configuracao de memoria:
maximum_object_size 64 MB
minimum_object_size 0 KB
maximum_object_size_in_memory 2560 Kb
A única coisa que não funcionou foi o ULE scheduler. Tive que deixar o 4BSD.
Aproveitei pra comentar suporte a hardwares que eu nunca vou usar como
firewire, impressora USB, mp3.. enfim.
Além disso ativei o soft-updates na partição /cache. Que melhorou o
desempenho de escrita no disco amplamente. Medido usando systat -v
Pensei ser problema no disco, mas como dito no e-mail anterior, falei
com o pessoal da lista freebsd-scsi e me reportaram que a velocidade,
de 55MB/s medida, é decente.
Então acredito que possamos descartar problemas no disco.
Bom. é assim que eu tenho o meu sistema rodando hoje.
Hoje pela manhã, cheguei cedo, sem sono, já havia tomado café!! ;-)
Mudei o IP do registro PROXY para apontar para meu servidor BSD. Em
questão de segundos já chegavam os primeiros usuários. Passados cerca
de 15 minutos. A lentidão começou a mostrar sua horrenda face. 5
minutos depois o google demorava.
squidclient mgr:info
Infelizmente perdi a saída dele com ctrl+c e ctrl+v da vida. Mas
lembro que me retorno 70 clientes.
Isso já é motivo de alegria pra mim. Como eu havia constatado logo no
início do problema esse número era em torno de 55.
Infelizmente não sei mais o que pode ser feito. Vou montar o cache com
noatime, mas já não to conseguindo acreditar em milagres hehe. A
propósito, alguém tem o contato de um bom pai de santo?! vou expulsar
os encostos desse servidor heuahua brincandeira a parte to perdido.
Se pelo menos conseguirmos constatar que o problema não é relacionado
com o Free e sim única e exclusivamente com o SQUID eu parto pra lista
deles e encerro aqui.
--
Att.
Lutieri G. B.
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
