Em 2013-09-10 17:59, Marcelo Gondim escreveu:
> Em 10/09/13 17:40, vic escreveu:
>> Em 2013-09-10 15:26, Marcelo Gondim escreveu:
>>> Em 10/09/13 10:16, vic escreveu:
>>>> Em 2013-09-10 9:23, Marcelo Gondim escreveu:
>>>>> Pessoal,
>>>>>
>>>>> Sei que muitos aqui conhecem o mod_evasive pro apache que no
>>>>> FreeBSD
>>>>> é
>>>>> o
>>>>> pacote ap22-mod_evasive.
>>>>> Ele vem com um script de teste que sempre utilizei pra checar se o
>>>>> mod_evasive tá legal:
>>>>>
>>>>> test.pl:
>>>>>
>>>>> #!/usr/bin/perl
>>>>> # test.pl: small script to test mod_dosevasive's effectiveness
>>>>> use IO::Socket;
>>>>> use strict;
>>>>> for(0..100) {
>>>>> my($response);
>>>>> my($SOCKET) = new IO::Socket::INET( Proto => "tcp",
>>>>> PeerAddr=>
>>>>> "127.0.0.1:80");
>>>>> if (! defined $SOCKET) { die $!; }
>>>>> print $SOCKET "GET /?$_ HTTP/1.0\n\n";
>>>>> $response = <$SOCKET>;
>>>>> print $response;
>>>>> close($SOCKET);
>>>>> }
>>>>>
>>>>> Só que quando rodo numa VM com FreeBSD ele abre as conexões
>>>>> lentamente,
>>>>> fazendo com que o teste não funcione. Fiz o mesmo teste em um
>>>>> FreeBSD
>>>>> sem ser VM e rodou mais rápido e consegui fazer os testes. Fui
>>>>> comparar
>>>>> com uma outra máquina com Linux e rodou estupidamente mais rápido.
>>>>> Logicamente que diferenças de processamento podem ser uma das
>>>>> causas
>>>>> mas
>>>>> porque rodou tão lento numa VM é que não descobri ainda.
>>>>> Alguém tem alguma ideia?
>>>>>
>>>>> Grande abraço
>>>> Suponho que sua aquela sua VM em Xen. Por acaso você tem um firewall
>>>> PF
>>>> na VM? Se sim tente:
>>>>
>>>> ifconfig xn0 -tso
>>>> sysctl -w net.inet.tcp.tso=0
>>>>
>>>> Referências:
>>>>
>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=154428
>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=135178
>>>>
>>>> Além disso, se você não compilou o kernel XENHVM, faça um teste com
>>>> ele
>>>> e mude a configuração do xen na vif para usar o type=netfront
>>>>
>>> É vic compilei com o XENHVM fiz as mudanças de disco e interface de
>>> rede
>>> e mesmo assim continua lento as conexões localhost do test.pl:
>>>
>>> # df -h
>>> Filesystem Size Used Avail Capacity Mounted on
>>> /dev/xbd0p2 2G 190M 1.6G 10% /
>>> devfs 1.0k 1.0k 0B 100% /dev
>>> /dev/xbd0p4 58G 15G 37G 29% /var
>>> /dev/xbd0p5 31G 6.0G 22G 21% /usr
>>> /dev/xbd0p6 2G 16M 1.8G 1% /tmp
>>>
>>> xn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>>> 1500
>>> options=503<RXCSUM,TXCSUM,TSO4,LRO>
>>> ether 00:16:3e:02:9d:d6
>>> inet xx.xxx.xxx.xx netmask 0xfffffff8 broadcast 67.212.89.79
>>> inet6 fe80::216:3eff:fe02:9dd6%xn0 prefixlen 64 scopeid 0x6
>>> nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>>> media: Ethernet manual
>>> status: active
>>>
>>> # uname -a
>>> FreeBSD xxxx.xxx.xxx.xx 9.2-PRERELEASE FreeBSD 9.2-PRERELEASE #0
>>> r255410M: Tue Sep 10 14:58:33 BRT 2013
>>> r...@xxxx.xxx.xxx.xx:/usr/obj/usr/src/sys/XENHVM amd64
>>>
>>> Quem tiver a curiosidade de fazer esse teste nas mesmas condições que
>>> eu
>>> aqui, seria interessante. Abaixo os dados:
>>>
>>> No servidor Debian 7 amd64
>>> ii libxen-4.1 4.1.4-3+deb7u1 amd64
>>> Public libs for Xen
>>> ii libxenstore3.0 4.1.4-3+deb7u1 amd64
>>> Xenstore communications library for Xen
>>> ii xen-hypervisor-4.1-amd64 4.1.4-3+deb7u1 amd64
>>> Xen
>>> Hypervisor on AMD64
>>> ii xen-linux-system-3.2.0-4-amd64 3.2.46-1+deb7u1 amd64
>>> Xen
>>> system with Linux 3.2 on 64-bit PCs (meta-package)
>>> ii xen-linux-system-amd64 3.2+46 amd64 Xen system
>>> with Linux for 64-bit PCs (meta-package)
>>> ii xen-system-amd64 4.1.4-3+deb7u1 amd64
>>> Xen
>>> System on AMD64 (meta-package)
>>> ii xen-tools 4.3.1-1 all Tools to
>>> manage Xen virtual servers
>>> ii xen-utils-4.1 4.1.4-3+deb7u1 amd64
>>> XEN
>>> administrative tools
>>> ii xen-utils-common 4.1.4-3+deb7u1 all
>>> Xen
>>> administrative tools - common files
>>> ii xenstore-utils 4.1.4-3+deb7u1 amd64
>>> Xenstore utilities for Xen
>>>
>>> Arquivo conf da VM:
>>>
>>> kernel = '/usr/lib/xen-4.1/boot/hvmloader'
>>> builder = 'hvm'
>>> vcpus = 4
>>> memory = 2048
>>> shadow_memory = 8
>>> name = 'freeba'
>>> vif = [ 'type=netfront, model=e1000, bridge=xenbr0', ]
>>> #vif = [ 'type=ioemu, bridge=xenbr0, mac=00:00:00:ff:fe:01' ]
>>> disk = [
>>> 'file:/home/xen/domains/freeba/freeba.img,xvda,w',
>>> 'file:/home/xen/domains/freeba/FreeBSD-9.2-PRERELEASE-amd64-20130831-r255108-disc1.iso,xvdc:cdrom,r'
>>> ]
>>> device_model = '/usr/lib/xen-4.1/bin/qemu-dm'
>>> boot = 'cd'
>>> sdl=0
>>> vnc = '1'
>>> vncviewer = '1'
>>> vnclisten = "0.0.0.0"
>>> vncpasswd = 'songamonga'
>>> stdvga=0
>>> serial='pty'
>>> usbdevice='tablet'
>>> on_poweroff = 'destroy'
>>> on_reboot = 'restart'
>>> on_crash = 'restart'
>>>
>>> Pacote do mod_evasive no FreeBSD: www/mod_evasive -
>>> ap22-mod_evasive-1.10.1_1 An Apache module to try to protect the
>>> HTTP Server from DoS/DDoS attacks
>>>
>>> []'s
>>> Gondim
>> Eu instalei o www/apache22 num 9.1 XENVHM e rodei o test.pl e o ab -kc
>> 10 -t 30 http://IP_VM/ a partir do meu computador.
>>
>> Depois eu instalei e habilitei o mod_evasive e refiz os teste. Ambos
>> rodaram... claro que o test.pl teve uns 403 e o ab não teve todas as
>> requisições respondidas.. mas isso era esperado. Todos os testes
>> rodaram
>> rapidinho.
>>
>> Na minha conf do xen não tem setado
>>
>> shadow_memory
>> usbdevice
>> e o cdrom (afinal já instalei)
>> com 4Gb de memória
>> vcpus=2
>>
>> O host é um Scientific Linux 6 com linux 3.8.7-1.el6xen.x86_64
>>
> Oi vic mas você tem outras VMs rodando nesse servidor? Nesse aqui tem
> mais 2 VMs.
> Estranho mesmo. Tem como você me passar o seu kernel em anexo em pvt?
> Pra eu comparar e ver se tem algo habilitado demais aqui.
> Vou tentar também sem esses parâmetros acima.
>
> []'s
> Gondim
>
No servidor tem mais 2 VM, um FreeBSD 7.4 i386 (app legado), um
Slackware 13.1 i386 (outro app legado) e esse FreeBSD 9.1 rodando apps
em java.
Segue conf do kernel
include GENERIC
ident XENHVM
#
# Adaptive locks rely on a lock-free pointer read to determine the run
state
# of the thread holding a lock when under contention; under a
virtualisation
# system, the thread run state may not accurately reflect whether the
thread
# (or rather its host VCPU) is actually executing. As such, disable
this
# optimisation.
#
options NO_ADAPTIVE_MUTEXES
options NO_ADAPTIVE_RWLOCKS
options NO_ADAPTIVE_SX
# Xen HVM support
options XENHVM
device xenpci
cat /boot/loader.conf
# XEN console support
boot_multicons="YES"
boot_serial="YES"
comconsole_speed=9600
console="comconsole,vidconsole"
--
vic
choppnerd.com
donttrack.us | dontbubble.us
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
