Re: [FUG-BR] Acesso ao disco em vmware
Fiz um novo teste /extração usando freebsd 9 64bis, com disco pre-alocado, o resultado é de 14.20 min... Já com Freebsd 8 32bits, com disco não pre-alocado, ficou com tempo de 13.12 min. Alguém chegou a alguma conclusão para esta thread? Em 19 de maio de 2012 11:22, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Estou implementando um servidor HP proliant com 4gb, até amanhã posto aqui este resultado também.. Ari, qual foi o seu tempo para remoção? Em 19 de maio de 2012 11:18, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: É um notebook Dell XPS, i7 2630QM, 8GB ram, só para estudo básico. Em 19 de maio de 2012 09:19, Ari Arantes Filho a...@dd.com.br escreveu: 13minutos é muito tempo também. Qual a configuração da sua máquina? Em 19 de maio de 2012 02:26, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: e pra remover: 0.238 3.642s 3:44.30 1.7% Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Ari, fiz o teste aqui no meu e ficou o seguinte: 7.088u 19.307s 13:12.91 3.3% Em 18 de maio de 2012 18:37, Ari Arantes Filho a...@dd.com.br escreveu: Testei com o disco sem o thinprovisioning: # time tar xzf ports.tar.gz real16m8.904s mesma coisa, péssima performance. Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Beleza Ari, vamos ficar aguardando o resultado... Amanhã vou fazer o mesmo e posto aqui também o resultado. Em 18 de maio de 2012 17:08, Ari Arantes Filho a...@dd.com.br escreveu: Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: 2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista:
Re: [FUG-BR] Acesso ao disco em vmware
13minutos é muito tempo também. Qual a configuração da sua máquina? Em 19 de maio de 2012 02:26, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: e pra remover: 0.238 3.642s 3:44.30 1.7% Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Ari, fiz o teste aqui no meu e ficou o seguinte: 7.088u 19.307s 13:12.91 3.3% Em 18 de maio de 2012 18:37, Ari Arantes Filho a...@dd.com.br escreveu: Testei com o disco sem o thinprovisioning: # time tar xzf ports.tar.gz real 16m8.904s mesma coisa, péssima performance. Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Beleza Ari, vamos ficar aguardando o resultado... Amanhã vou fazer o mesmo e posto aqui também o resultado. Em 18 de maio de 2012 17:08, Ari Arantes Filho a...@dd.com.br escreveu: Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: 2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - 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] Acesso ao disco em vmware
É um notebook Dell XPS, i7 2630QM, 8GB ram, só para estudo básico. Em 19 de maio de 2012 09:19, Ari Arantes Filho a...@dd.com.br escreveu: 13minutos é muito tempo também. Qual a configuração da sua máquina? Em 19 de maio de 2012 02:26, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: e pra remover: 0.238 3.642s 3:44.30 1.7% Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Ari, fiz o teste aqui no meu e ficou o seguinte: 7.088u 19.307s 13:12.91 3.3% Em 18 de maio de 2012 18:37, Ari Arantes Filho a...@dd.com.br escreveu: Testei com o disco sem o thinprovisioning: # time tar xzf ports.tar.gz real16m8.904s mesma coisa, péssima performance. Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Beleza Ari, vamos ficar aguardando o resultado... Amanhã vou fazer o mesmo e posto aqui também o resultado. Em 18 de maio de 2012 17:08, Ari Arantes Filho a...@dd.com.br escreveu: Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: 2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı.
Re: [FUG-BR] Acesso ao disco em vmware
Estou implementando um servidor HP proliant com 4gb, até amanhã posto aqui este resultado também.. Ari, qual foi o seu tempo para remoção? Em 19 de maio de 2012 11:18, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: É um notebook Dell XPS, i7 2630QM, 8GB ram, só para estudo básico. Em 19 de maio de 2012 09:19, Ari Arantes Filho a...@dd.com.br escreveu: 13minutos é muito tempo também. Qual a configuração da sua máquina? Em 19 de maio de 2012 02:26, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: e pra remover: 0.238 3.642s 3:44.30 1.7% Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Ari, fiz o teste aqui no meu e ficou o seguinte: 7.088u 19.307s 13:12.91 3.3% Em 18 de maio de 2012 18:37, Ari Arantes Filho a...@dd.com.br escreveu: Testei com o disco sem o thinprovisioning: # time tar xzf ports.tar.gz real16m8.904s mesma coisa, péssima performance. Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Beleza Ari, vamos ficar aguardando o resultado... Amanhã vou fazer o mesmo e posto aqui também o resultado. Em 18 de maio de 2012 17:08, Ari Arantes Filho a...@dd.com.br escreveu: Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: 2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se
Re: [FUG-BR] Acesso ao disco em vmware
São 2 processadores Xeon E5620, 4 HDs SAS 300Gb e 32Gb de RAM. Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho a...@dd.com.br escreveu: SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu: Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a Buslogic. -- Francisco Ricardo ___ Administrador de Redes e Sistemas Unix/Linux Profissional Certificado RedHat | Entusiasta FreeBSD Natal/RN | (84)9461-4801 | frica...@bsd.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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - 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] Acesso ao disco em vmware
Como eu vejo se está dinâmico ou não? No vmware ou no SO? 2 duas VMs: SCSI controller -- LSI Logic Parallel SCSI Bus Sharing -- None HD1 -- Virtual -- SCSI (0:0) Ambos são thinprovisiniong. Mount e fdisk no FreeBSD: # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) # fdisk /dev/da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 20971519 (10239 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Mount e fdisk no ubuntu: # mount /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda1 on /boot type ext2 (rw) # fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007fbc2 Device Boot Start End Blocks Id System /dev/sda1 * 1 32 248832 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 321306102338575 Extended /dev/sda5 32130610233856 8e Linux LVM Em 18 de maio de 2012 00:04, Pedro Madsen pe...@madnix.com escreveu: O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com volume dinâmico. Em 17 de maio de 2012 23:36, Paulo Henrique paulo.rd...@bsd.com.brescreveu: Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho a...@dd.com.br escreveu: SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu: Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a Buslogic. Só uma pergunta, qual o seu valor de HZ no kernel ? Att. -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- :=)(=: Flamers /dev/null !!! - 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] Acesso ao disco em vmware
Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado ou se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, isso demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse para o virtualizador e a resposta da alocação do próprio Windows gera uma latência alta demais que engargala os processos da máquina virtual. No caso do espaço pré-alocado, o virtualizador não demora a responder a solicitação. Em 18 de maio de 2012 08:02, Ari Arantes Filho a...@dd.com.br escreveu: Como eu vejo se está dinâmico ou não? No vmware ou no SO? 2 duas VMs: SCSI controller -- LSI Logic Parallel SCSI Bus Sharing -- None HD1 -- Virtual -- SCSI (0:0) Ambos são thinprovisiniong. Mount e fdisk no FreeBSD: # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) # fdisk /dev/da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 20971519 (10239 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Mount e fdisk no ubuntu: # mount /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda1 on /boot type ext2 (rw) # fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007fbc2 Device Boot Start End Blocks Id System /dev/sda1 * 1 32 248832 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 321306102338575 Extended /dev/sda5 32130610233856 8e Linux LVM Em 18 de maio de 2012 00:04, Pedro Madsen pe...@madnix.com escreveu: O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com volume dinâmico. Em 17 de maio de 2012 23:36, Paulo Henrique paulo.rd...@bsd.com.br escreveu: Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho a...@dd.com.br escreveu: SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu: Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a Buslogic. Só uma pergunta, qual o seu valor de HZ no kernel ? Att. -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista:
Re: [FUG-BR] Acesso ao disco em vmware
Interessante a observação do Pedro Madsen, e inclusive vou checar isto... Sempre usei esta configuração para expandir dinamicamente e também notei lentidão ao realizar os testes informado pelo Ari :-) Em 18 de maio de 2012 16:16, Pedro Madsen pe...@madnix.com escreveu: Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado ou se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, isso demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse para o virtualizador e a resposta da alocação do próprio Windows gera uma latência alta demais que engargala os processos da máquina virtual. No caso do espaço pré-alocado, o virtualizador não demora a responder a solicitação. Em 18 de maio de 2012 08:02, Ari Arantes Filho a...@dd.com.br escreveu: Como eu vejo se está dinâmico ou não? No vmware ou no SO? 2 duas VMs: SCSI controller -- LSI Logic Parallel SCSI Bus Sharing -- None HD1 -- Virtual -- SCSI (0:0) Ambos são thinprovisiniong. Mount e fdisk no FreeBSD: # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) # fdisk /dev/da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 20971519 (10239 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Mount e fdisk no ubuntu: # mount /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda1 on /boot type ext2 (rw) # fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007fbc2 Device Boot Start End Blocks Id System /dev/sda1 * 1 32 248832 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 321306102338575 Extended /dev/sda5 32130610233856 8e Linux LVM Em 18 de maio de 2012 00:04, Pedro Madsen pe...@madnix.com escreveu: O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com volume dinâmico. Em 17 de maio de 2012 23:36, Paulo Henrique paulo.rd...@bsd.com.br escreveu: Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho a...@dd.com.br escreveu: SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu: Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a
Re: [FUG-BR] Acesso ao disco em vmware
Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas como disse noutro post, é uma criança carregando um adulto no colo. Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Interessante a observação do Pedro Madsen, e inclusive vou checar isto... Sempre usei esta configuração para expandir dinamicamente e também notei lentidão ao realizar os testes informado pelo Ari :-) Em 18 de maio de 2012 16:16, Pedro Madsen pe...@madnix.com escreveu: Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado ou se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, isso demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse para o virtualizador e a resposta da alocação do próprio Windows gera uma latência alta demais que engargala os processos da máquina virtual. No caso do espaço pré-alocado, o virtualizador não demora a responder a solicitação. Em 18 de maio de 2012 08:02, Ari Arantes Filho a...@dd.com.br escreveu: Como eu vejo se está dinâmico ou não? No vmware ou no SO? 2 duas VMs: SCSI controller -- LSI Logic Parallel SCSI Bus Sharing -- None HD1 -- Virtual -- SCSI (0:0) Ambos são thinprovisiniong. Mount e fdisk no FreeBSD: # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) # fdisk /dev/da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 20971519 (10239 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Mount e fdisk no ubuntu: # mount /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda1 on /boot type ext2 (rw) # fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007fbc2 Device Boot Start End Blocks Id System /dev/sda1 * 1 32 248832 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 321306102338575 Extended /dev/sda5 32130610233856 8e Linux LVM Em 18 de maio de 2012 00:04, Pedro Madsen pe...@madnix.com escreveu: O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com volume dinâmico. Em 17 de maio de 2012 23:36, Paulo Henrique paulo.rd...@bsd.com.br escreveu: Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho a...@dd.com.br escreveu: SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu: Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora
Re: [FUG-BR] Acesso ao disco em vmware
Ainda que tenha esse HD dinâmico, conhecia como thinprovisioning, concordo que ele cresce qdo precisa e nesse momento fica mais lento, mas 2 coisas: 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente 2) os 2 servidores (freebsd e ubuntu) estão idênticos, ou seja, se tem esse problema de crescer o disco dinamicamente, tem para os 2 servidores. O que quero descobrir é como deixar o BSD mais rápido. Onde podemos mexer. Em 18 de maio de 2012 16:31, Pedro Madsen pe...@madnix.com escreveu: Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas como disse noutro post, é uma criança carregando um adulto no colo. Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Interessante a observação do Pedro Madsen, e inclusive vou checar isto... Sempre usei esta configuração para expandir dinamicamente e também notei lentidão ao realizar os testes informado pelo Ari :-) Em 18 de maio de 2012 16:16, Pedro Madsen pe...@madnix.com escreveu: Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado ou se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, isso demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse para o virtualizador e a resposta da alocação do próprio Windows gera uma latência alta demais que engargala os processos da máquina virtual. No caso do espaço pré-alocado, o virtualizador não demora a responder a solicitação. Em 18 de maio de 2012 08:02, Ari Arantes Filho a...@dd.com.br escreveu: Como eu vejo se está dinâmico ou não? No vmware ou no SO? 2 duas VMs: SCSI controller -- LSI Logic Parallel SCSI Bus Sharing -- None HD1 -- Virtual -- SCSI (0:0) Ambos são thinprovisiniong. Mount e fdisk no FreeBSD: # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) # fdisk /dev/da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 20971519 (10239 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Mount e fdisk no ubuntu: # mount /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda1 on /boot type ext2 (rw) # fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007fbc2 Device Boot Start End Blocks Id System /dev/sda1 * 1 32 248832 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 32 1306 10233857 5 Extended /dev/sda5 32 1306 10233856 8e Linux LVM Em 18 de maio de 2012 00:04, Pedro Madsen pe...@madnix.com escreveu: O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com volume dinâmico. Em 17 de maio de 2012 23:36, Paulo Henrique paulo.rd...@bsd.com.br escreveu: Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho a...@dd.com.br escreveu: SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu:
Re: [FUG-BR] Acesso ao disco em vmware
Ari, pode ser no suporte ao SO mesmo. No caso do Hiper-V, o Linux funciona (mais lento mas funciona) e o FreeBSD tem uma performance tão ruim que fica acusando erro de IO como se o disco tivesse inacessível. Não é a toa que dou preferencia para usar Jails ao invés da virtualização em muitos casos, o suporte ao FreeBSD por parte dos virtualizadores não é prioritário. Em 18 de maio de 2012 16:36, Ari Arantes Filho a...@dd.com.br escreveu: Ainda que tenha esse HD dinâmico, conhecia como thinprovisioning, concordo que ele cresce qdo precisa e nesse momento fica mais lento, mas 2 coisas: 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente 2) os 2 servidores (freebsd e ubuntu) estão idênticos, ou seja, se tem esse problema de crescer o disco dinamicamente, tem para os 2 servidores. O que quero descobrir é como deixar o BSD mais rápido. Onde podemos mexer. Em 18 de maio de 2012 16:31, Pedro Madsen pe...@madnix.com escreveu: Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas como disse noutro post, é uma criança carregando um adulto no colo. Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Interessante a observação do Pedro Madsen, e inclusive vou checar isto... Sempre usei esta configuração para expandir dinamicamente e também notei lentidão ao realizar os testes informado pelo Ari :-) Em 18 de maio de 2012 16:16, Pedro Madsen pe...@madnix.com escreveu: Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado ou se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, isso demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse para o virtualizador e a resposta da alocação do próprio Windows gera uma latência alta demais que engargala os processos da máquina virtual. No caso do espaço pré-alocado, o virtualizador não demora a responder a solicitação. Em 18 de maio de 2012 08:02, Ari Arantes Filho a...@dd.com.br escreveu: Como eu vejo se está dinâmico ou não? No vmware ou no SO? 2 duas VMs: SCSI controller -- LSI Logic Parallel SCSI Bus Sharing -- None HD1 -- Virtual -- SCSI (0:0) Ambos são thinprovisiniong. Mount e fdisk no FreeBSD: # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) # fdisk /dev/da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 20971519 (10239 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Mount e fdisk no ubuntu: # mount /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda1 on /boot type ext2 (rw) # fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007fbc2 Device Boot Start End Blocks Id System /dev/sda1 * 1 32 248832 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 321306102338575 Extended /dev/sda5 32130610233856 8e Linux LVM Em 18 de maio de 2012 00:04, Pedro Madsen pe...@madnix.com escreveu: O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com volume dinâmico. Em 17 de maio de 2012 23:36, Paulo Henrique
Re: [FUG-BR] Acesso ao disco em vmware
Ari, ontem realizei estes mesmos testes utilizando quase o mesmo cenário.. também observei uma demora imensa ao descompactar e remover este arquivo. Em 18 de maio de 2012 16:36, Ari Arantes Filho a...@dd.com.br escreveu: Ainda que tenha esse HD dinâmico, conhecia como thinprovisioning, concordo que ele cresce qdo precisa e nesse momento fica mais lento, mas 2 coisas: 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente 2) os 2 servidores (freebsd e ubuntu) estão idênticos, ou seja, se tem esse problema de crescer o disco dinamicamente, tem para os 2 servidores. O que quero descobrir é como deixar o BSD mais rápido. Onde podemos mexer. Em 18 de maio de 2012 16:31, Pedro Madsen pe...@madnix.com escreveu: Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas como disse noutro post, é uma criança carregando um adulto no colo. Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Interessante a observação do Pedro Madsen, e inclusive vou checar isto... Sempre usei esta configuração para expandir dinamicamente e também notei lentidão ao realizar os testes informado pelo Ari :-) Em 18 de maio de 2012 16:16, Pedro Madsen pe...@madnix.com escreveu: Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado ou se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, isso demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse para o virtualizador e a resposta da alocação do próprio Windows gera uma latência alta demais que engargala os processos da máquina virtual. No caso do espaço pré-alocado, o virtualizador não demora a responder a solicitação. Em 18 de maio de 2012 08:02, Ari Arantes Filho a...@dd.com.br escreveu: Como eu vejo se está dinâmico ou não? No vmware ou no SO? 2 duas VMs: SCSI controller -- LSI Logic Parallel SCSI Bus Sharing -- None HD1 -- Virtual -- SCSI (0:0) Ambos são thinprovisiniong. Mount e fdisk no FreeBSD: # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) # fdisk /dev/da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 20971519 (10239 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Mount e fdisk no ubuntu: # mount /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda1 on /boot type ext2 (rw) # fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007fbc2 Device Boot Start End Blocks Id System /dev/sda1 * 1 32 248832 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 321306102338575 Extended /dev/sda5 32130610233856 8e Linux LVM Em 18 de maio de 2012 00:04, Pedro Madsen pe...@madnix.com escreveu: O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com volume dinâmico. Em 17 de maio de 2012 23:36, Paulo Henrique paulo.rd...@bsd.com.br escreveu: Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56,
Re: [FUG-BR] Acesso ao disco em vmware
Realmente, como o Pedro disse, notei também em algum momento erro de IO em meus testes... Em 18 de maio de 2012 16:41, Pedro Madsen pe...@madnix.com escreveu: Ari, pode ser no suporte ao SO mesmo. No caso do Hiper-V, o Linux funciona (mais lento mas funciona) e o FreeBSD tem uma performance tão ruim que fica acusando erro de IO como se o disco tivesse inacessível. Não é a toa que dou preferencia para usar Jails ao invés da virtualização em muitos casos, o suporte ao FreeBSD por parte dos virtualizadores não é prioritário. Em 18 de maio de 2012 16:36, Ari Arantes Filho a...@dd.com.br escreveu: Ainda que tenha esse HD dinâmico, conhecia como thinprovisioning, concordo que ele cresce qdo precisa e nesse momento fica mais lento, mas 2 coisas: 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente 2) os 2 servidores (freebsd e ubuntu) estão idênticos, ou seja, se tem esse problema de crescer o disco dinamicamente, tem para os 2 servidores. O que quero descobrir é como deixar o BSD mais rápido. Onde podemos mexer. Em 18 de maio de 2012 16:31, Pedro Madsen pe...@madnix.com escreveu: Agora que o Hiper-V vai suportar FreeBSD, isso deve melhorar... mas como disse noutro post, é uma criança carregando um adulto no colo. Em 18 de maio de 2012 16:30, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Interessante a observação do Pedro Madsen, e inclusive vou checar isto... Sempre usei esta configuração para expandir dinamicamente e também notei lentidão ao realizar os testes informado pelo Ari :-) Em 18 de maio de 2012 16:16, Pedro Madsen pe...@madnix.com escreveu: Pelo proprio virtualizador, veja se o espaço do disco já foi préa-locado ou se ele irá expandir dinamicamente conforme o uso. No caso do Hiper-V, isso demora pois após o FreeBSD solicitar espaço no disco, o tempo de repasse para o virtualizador e a resposta da alocação do próprio Windows gera uma latência alta demais que engargala os processos da máquina virtual. No caso do espaço pré-alocado, o virtualizador não demora a responder a solicitação. Em 18 de maio de 2012 08:02, Ari Arantes Filho a...@dd.com.br escreveu: Como eu vejo se está dinâmico ou não? No vmware ou no SO? 2 duas VMs: SCSI controller -- LSI Logic Parallel SCSI Bus Sharing -- None HD1 -- Virtual -- SCSI (0:0) Ambos são thinprovisiniong. Mount e fdisk no FreeBSD: # mount /dev/da0p2 on / (ufs, local, journaled soft-updates) devfs on /dev (devfs, local, multilabel) # fdisk /dev/da0 *** Working on device /dev/da0 *** parameters extracted from in-core disklabel are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=1305 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 238 (0xee),(EFI GPT) start 1, size 20971519 (10239 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 2; end: cyl 1023/ head 255/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED Mount e fdisk no ubuntu: # mount /dev/mapper/coringa-root on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) none on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) /dev/sda1 on /boot type ext2 (rw) # fdisk -l Disk /dev/sda: 10.7 GB, 10737418240 bytes 255 heads, 63 sectors/track, 1305 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x0007fbc2 Device Boot Start End Blocks Id System /dev/sda1 * 1 32 248832 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 321306102338575 Extended /dev/sda5 321306
Re: [FUG-BR] Acesso ao disco em vmware
2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: 2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - 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] Acesso ao disco em vmware
Beleza Ari, vamos ficar aguardando o resultado... Amanhã vou fazer o mesmo e posto aqui também o resultado. Em 18 de maio de 2012 17:08, Ari Arantes Filho a...@dd.com.br escreveu: Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: 2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Testei com o disco sem o thinprovisioning: # time tar xzf ports.tar.gz real16m8.904s mesma coisa, péssima performance. Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Beleza Ari, vamos ficar aguardando o resultado... Amanhã vou fazer o mesmo e posto aqui também o resultado. Em 18 de maio de 2012 17:08, Ari Arantes Filho a...@dd.com.br escreveu: Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: 2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - 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] Acesso ao disco em vmware
Ari, fiz o teste aqui no meu e ficou o seguinte: 7.088u 19.307s 13:12.91 3.3% Em 18 de maio de 2012 18:37, Ari Arantes Filho a...@dd.com.br escreveu: Testei com o disco sem o thinprovisioning: # time tar xzf ports.tar.gz real16m8.904s mesma coisa, péssima performance. Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Beleza Ari, vamos ficar aguardando o resultado... Amanhã vou fazer o mesmo e posto aqui também o resultado. Em 18 de maio de 2012 17:08, Ari Arantes Filho a...@dd.com.br escreveu: Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: 2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
e pra remover: 0.238 3.642s 3:44.30 1.7% Em 19 de maio de 2012 02:11, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Ari, fiz o teste aqui no meu e ficou o seguinte: 7.088u 19.307s 13:12.91 3.3% Em 18 de maio de 2012 18:37, Ari Arantes Filho a...@dd.com.br escreveu: Testei com o disco sem o thinprovisioning: # time tar xzf ports.tar.gz real16m8.904s mesma coisa, péssima performance. Em 18 de maio de 2012 17:17, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Beleza Ari, vamos ficar aguardando o resultado... Amanhã vou fazer o mesmo e posto aqui também o resultado. Em 18 de maio de 2012 17:08, Ari Arantes Filho a...@dd.com.br escreveu: Vou reinstalar um FreeBSD 9 e utilizar um disco sem o thinprovisioning e reporto aqui na lista os resultados. Em 18 de maio de 2012 17:01, Rafael Henrique Faria rafaelhfa...@cenadigital.com.br escreveu: 2012/5/18 Ari Arantes Filho a...@dd.com.br 1) sempre rodo o tar xzf ports.tar.gz e depois rm -rf ports, ou seja, libero o espaço e teoricamente o vmware não precisará aumentar novamente Eu posso estar errado, os mais experientes neste caso que me corrijam, mas o UFS2 em uso no caso do FreeBSD não faz isso que você está imaginando. Quando você descompacta a primeira vez o ports.tar.gz, o UFS2 vai alocar o espaço para o mesmo. E quando você apaga o mesmo, apesar do espaço ficar livre, o UFS2 não apaga o conteũdo do disco. E uma nova gravação, não irá utilizar o espaço liberado, mas sim um espaço livre virgem. O espaço liberado somente será utilizando quando o disco não tiver mais espaços livres. Ao utilizar recursos como este em HDs reais, o file system tem uma melhora de performance, pois não precisa ficar apagando o disco... ele vai usando espaços livres até que realmente seja necessário uma limpeza do file system por ter acabado o espaço livre. Ultimamente percebi que após algum tempo, algumas horas, o espaço acaba sendo liberado para uso... então acredito que tenha sido feita uma alteração para algum processo de varredura ir liberando o espaço de tempo em tempo.. mas isso não é em tempo real. Um exemplo prático disso: - esgote o espaço em disco com arquivos grandes. - apague um dos arquivos grandes. - o espaço não será liberado imediatamente... o disco vai continuar reclamando que não tem espaço livre o suficiente. Normalmente isso não apresenta grandes problemas... pois um bom administrador nunca irá deixar esgotar o espaço em disco. Porém, no caso do thinprovisioning isso é um problema. Pois a cada nova gravação ele vai precisar requisitar do HOST um novo espaço em disco. O que acaba ficando lendo. Eu sinceramente evito usar thinprovisioning em servidores de virtualização, tanto por causa deste problema, quanto pelo efeito surpresa, de você alocar 10 HDs de 1TB em um volume de 7TB, e acontecer de os 10 HDs precisaram usar os 1TB oferecidos para o mesmo. Claro que é um exemplo, na prática teremos 40 máquinas com HDs de tamanhos variados, que se tornará difícil ficar acompanhando o crescimento, e o tamanho configurado para cada uma no momento da crianção da máquina. -- Rafael Henrique da Silva Faria - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - 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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Em 16 de maio de 2012 16:47, Francisco Cardoso frica...@bsd.com.br escreveu: Em 15 de maio de 2012 20:19, Ari Arantes Filho a...@dd.com.br escreveu: No ubuntu também não tem o vmware-tools instalado. Em 15 de maio de 2012 18:36, Luiz Gustavo luizgust...@luizgustavo.pro.br escreveu: Em Ter, 2012-05-15 às 18:26 -0300, Ari Arantes Filho escreveu: Pessoal, Tenho alguns servidores em teste no VMware ESXi 5. Porém reparei que o acesso ao disco é extramente lento. Testei a versão 9.0-RELEASE. Alguém sabe o que pode ser feito para melhorar isso? Sem querer gerar polêmica, mas instalei um Ubuntu 10.04 LTS no mesmo servidor com as mesmas configurações e fiz 8 testes em tempos variados. Para descompactar a árvore do ports (tar xzf ports.tar.gz), no Ubuntu, o pior tempo foi de 0m49.005s e o melhor 0m32.784s.Fiz uns 10 testes (sempre depois que rodava o tar xzf ports.tar.gz, rodava um rm -rf ports), sempre pegando os tempos através do time. Já no FreeBSD, os tempos passam de 10m, 12m, um teste foi até 17m. O / no FreeBSD está com soft-update. Dai Ari, tudo bom ? Você instalou o vwmare-guestd ? se não me engano, isso já vem padrão no ubuntu, por isso talvez a grande diferença. Tente instalar o vmware-guestd, acho que pra teu caso é esse: /usr/ports/emulators/vmware-guestd5 Abraços -- 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Muito estranho Ari ... 10 minutos para descompactar a árvore de ports? Qual a controladora virtual de discos que você usou? Testou com a versão 8.2/8.3 do Free também? -- Francisco Ricardo ___ Administrador de Redes e Sistemas Unix/Linux Profissional Certificado RedHat | Entusiasta FreeBSD Natal/RN | (84)9461-4801 | frica...@bsd.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
Re: [FUG-BR] Acesso ao disco em vmware
Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a Buslogic. -- Francisco Ricardo ___ Administrador de Redes e Sistemas Unix/Linux Profissional Certificado RedHat | Entusiasta FreeBSD Natal/RN | (84)9461-4801 | frica...@bsd.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] Acesso ao disco em vmware
SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu: Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a Buslogic. -- Francisco Ricardo ___ Administrador de Redes e Sistemas Unix/Linux Profissional Certificado RedHat | Entusiasta FreeBSD Natal/RN | (84)9461-4801 | frica...@bsd.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
Re: [FUG-BR] Acesso ao disco em vmware
Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho a...@dd.com.br escreveu: SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu: Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a Buslogic. -- Francisco Ricardo ___ Administrador de Redes e Sistemas Unix/Linux Profissional Certificado RedHat | Entusiasta FreeBSD Natal/RN | (84)9461-4801 | frica...@bsd.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 -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho a...@dd.com.br escreveu: SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu: Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a Buslogic. Só uma pergunta, qual o seu valor de HZ no kernel ? Att. -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- :=)(=: Flamers /dev/null !!! - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
O volume está dinâmico ou estático? Já vi problemas assim com Hiper-V com volume dinâmico. Em 17 de maio de 2012 23:36, Paulo Henrique paulo.rd...@bsd.com.brescreveu: Em 17 de maio de 2012 21:19, Welinaldo Lopes Nascimento welina...@bsd.com.br escreveu: Qual a configuração de hardware deste servidor? Em 17 de maio de 2012 18:56, Ari Arantes Filho a...@dd.com.br escreveu: SCSI controller 0 -- LSI Logic Parallel. A mesma utilizada no Ubuntu. Não mexi na configuração wizard do vmware. Escolhi FreeBSD 64 para o BSD e Ubuntu 64 para ubuntu. Em 17 de maio de 2012 14:46, Francisco Cardoso frica...@bsd.com.br escreveu: Em 17 de maio de 2012 11:58, Ari Arantes Filho a...@dd.com.br escreveu: O servidor é um IBM3550M3. A controladora é a padrão. Também testei com um FreeBSD instalado no storage e não no disco local do vmware na 3550, mas os tempos também são bem parecidos. Vou testar com a 8.3. Acho que não me expressei bem. Quando falei controladora quis dizer a controladora da máquina virtual, não a do hardware físico do servidor. Em outras palavras se a sua máquina virtual usa a controladora Buslogic, por exemplo, você vai ter problemas de lentidão, já que essa controladora é antiga e em geral só deve ser usada para sistemas legados. Em geral o vsphere oferece como padrão para o FreeBSD a controlado LSI Logic Parallel se não me falha a memória. A performance desta é incomparavelmente melhor do que a Buslogic. Só uma pergunta, qual o seu valor de HZ no kernel ? Att. -- .:: Welinaldo L N .:: Estudante de Desenvolvimento de Sistemas .:: FreeBSD Community Member #BSD/OS .:: Antes de imprimir, veja se realmente é necessário! .ılı..ılı. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd -- :=)(=: Flamers /dev/null !!! - 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] Acesso ao disco em vmware
Em 15 de maio de 2012 20:19, Ari Arantes Filho a...@dd.com.br escreveu: No ubuntu também não tem o vmware-tools instalado. Em 15 de maio de 2012 18:36, Luiz Gustavo luizgust...@luizgustavo.pro.br escreveu: Em Ter, 2012-05-15 às 18:26 -0300, Ari Arantes Filho escreveu: Pessoal, Tenho alguns servidores em teste no VMware ESXi 5. Porém reparei que o acesso ao disco é extramente lento. Testei a versão 9.0-RELEASE. Alguém sabe o que pode ser feito para melhorar isso? Sem querer gerar polêmica, mas instalei um Ubuntu 10.04 LTS no mesmo servidor com as mesmas configurações e fiz 8 testes em tempos variados. Para descompactar a árvore do ports (tar xzf ports.tar.gz), no Ubuntu, o pior tempo foi de 0m49.005s e o melhor 0m32.784s.Fiz uns 10 testes (sempre depois que rodava o tar xzf ports.tar.gz, rodava um rm -rf ports), sempre pegando os tempos através do time. Já no FreeBSD, os tempos passam de 10m, 12m, um teste foi até 17m. O / no FreeBSD está com soft-update. Dai Ari, tudo bom ? Você instalou o vwmare-guestd ? se não me engano, isso já vem padrão no ubuntu, por isso talvez a grande diferença. Tente instalar o vmware-guestd, acho que pra teu caso é esse: /usr/ports/emulators/vmware-guestd5 Abraços -- 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Muito estranho Ari ... 10 minutos para descompactar a árvore de ports? Qual a controladora virtual de discos que você usou? Testou com a versão 8.2/8.3 do Free também? -- Francisco Ricardo ___ Administrador de Redes e Sistemas Unix/Linux Profissional Certificado RedHat | Entusiasta FreeBSD Natal/RN | (84)9461-4801 | frica...@bsd.com.br - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] Acesso ao disco em vmware
Pessoal, Tenho alguns servidores em teste no VMware ESXi 5. Porém reparei que o acesso ao disco é extramente lento. Testei a versão 9.0-RELEASE. Alguém sabe o que pode ser feito para melhorar isso? Sem querer gerar polêmica, mas instalei um Ubuntu 10.04 LTS no mesmo servidor com as mesmas configurações e fiz 8 testes em tempos variados. Para descompactar a árvore do ports (tar xzf ports.tar.gz), no Ubuntu, o pior tempo foi de 0m49.005s e o melhor 0m32.784s.Fiz uns 10 testes (sempre depois que rodava o tar xzf ports.tar.gz, rodava um rm -rf ports), sempre pegando os tempos através do time. Já no FreeBSD, os tempos passam de 10m, 12m, um teste foi até 17m. O / no FreeBSD está com soft-update. Obrigado, Ari - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] Acesso ao disco em vmware
Em Ter, 2012-05-15 às 18:26 -0300, Ari Arantes Filho escreveu: Pessoal, Tenho alguns servidores em teste no VMware ESXi 5. Porém reparei que o acesso ao disco é extramente lento. Testei a versão 9.0-RELEASE. Alguém sabe o que pode ser feito para melhorar isso? Sem querer gerar polêmica, mas instalei um Ubuntu 10.04 LTS no mesmo servidor com as mesmas configurações e fiz 8 testes em tempos variados. Para descompactar a árvore do ports (tar xzf ports.tar.gz), no Ubuntu, o pior tempo foi de 0m49.005s e o melhor 0m32.784s.Fiz uns 10 testes (sempre depois que rodava o tar xzf ports.tar.gz, rodava um rm -rf ports), sempre pegando os tempos através do time. Já no FreeBSD, os tempos passam de 10m, 12m, um teste foi até 17m. O / no FreeBSD está com soft-update. Dai Ari, tudo bom ? Você instalou o vwmare-guestd ? se não me engano, isso já vem padrão no ubuntu, por isso talvez a grande diferença. Tente instalar o vmware-guestd, acho que pra teu caso é esse: /usr/ports/emulators/vmware-guestd5 Abraços -- 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] Acesso ao disco em vmware
No ubuntu também não tem o vmware-tools instalado. Em 15 de maio de 2012 18:36, Luiz Gustavo luizgust...@luizgustavo.pro.br escreveu: Em Ter, 2012-05-15 às 18:26 -0300, Ari Arantes Filho escreveu: Pessoal, Tenho alguns servidores em teste no VMware ESXi 5. Porém reparei que o acesso ao disco é extramente lento. Testei a versão 9.0-RELEASE. Alguém sabe o que pode ser feito para melhorar isso? Sem querer gerar polêmica, mas instalei um Ubuntu 10.04 LTS no mesmo servidor com as mesmas configurações e fiz 8 testes em tempos variados. Para descompactar a árvore do ports (tar xzf ports.tar.gz), no Ubuntu, o pior tempo foi de 0m49.005s e o melhor 0m32.784s.Fiz uns 10 testes (sempre depois que rodava o tar xzf ports.tar.gz, rodava um rm -rf ports), sempre pegando os tempos através do time. Já no FreeBSD, os tempos passam de 10m, 12m, um teste foi até 17m. O / no FreeBSD está com soft-update. Dai Ari, tudo bom ? Você instalou o vwmare-guestd ? se não me engano, isso já vem padrão no ubuntu, por isso talvez a grande diferença. Tente instalar o vmware-guestd, acho que pra teu caso é esse: /usr/ports/emulators/vmware-guestd5 Abraços -- 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 - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] acesso a disco
Gilvan, Estou tendo problemas com acesso a disco, (gargalo de acesso) muitos programas tendando acessar o disco ao mesmo tempo, existe algum programa que eu possar ver que software esta gravando ou acessando o disco ?? Você pode utilizar o iostat mesmo, porém o melhor e mais fácil na minha opinião é o gstat (Geom Stat). Abraços -- Diego Linke Public Key: http://www.gamk.com.br/gamk.asc ___ freebsd mailing list freebsd@fug.com.br https://www.fug.com.br/mailman/listinfo/freebsd
[FUG-BR] acesso a disco
Ola lista, Estou tendo problemas com acesso a disco, (gargalo de acesso)muitos programas tendando acessar o disco ao mesmo tempo, existe algum programa que eu possar ver que software esta gravando ou acessando o disco ?? Gilvan Lima ___ freebsd mailing list freebsd@fug.com.br https://www.fug.com.br/mailman/listinfo/freebsd
