que bom. olha que aqui e supermercado a base cresce o tempo todo, daqui a tres meses terei que trocar os disco colocar 04 hd sas 600gb.
Em 29 de outubro de 2011 08:58, Marcelo Gondim <[email protected]> escreveu: > Em 29/10/2011 08:52, Alessandro de Souza Rocha escreveu: >> aqui no servidor base oracle, rodando oracle linux, a base de dados >> era uns 20gb, demorou um dia para subir tudo quando fomos trocar o >> servidor >> que aqui e um dell 1900 xeom quad-core 3.0 10gb de ram hds sas 300gb 15000 >> rpm. > > É tempo heim! :) Aqui acabou de fazer em umas 8 horas mas a máquina > aqui na ajudava muito. > Como já tava fazendo deixei rolando para ver quanto tempo iria levar. > Agora tá tudo bem por aqui. > >> >> Em 28 de outubro de 2011 17:39, Leonardo Augusto<[email protected]> >> escreveu: >>> De quantos registros nesse insert voce esta falando ? pra demorar tanto ? >>> >>> Tenho tabelas que faco dump e restore seguido na ordem dos 10 milhoes >>> de registros e vai >>> rapidinho.. O arquivo da tabela gira em torno de 4G só ele... >>> >>> Mas a maquina é dual quad core, barramento 1000mhz 8Gecc raid 5 ultra >>> scsi 256 de cache. >>> Bsd 7.2, o desempenho do mysql com innodb é muito bom. >>> Existem 4 indices e apenas um é sobre um varchar 255, os demais sao sobre >>> uint. >>> >>> Para levar horas... vc deve ter bilhoes entao... e passar dos 20G de >>> dados, com indices complexos... >>> Creio eu... se vc tem fulltext index acredito que possa pesar tambem... >>> >>> []´s >>> >>> >>> 2011/10/28 Marcelo Gondim<[email protected]>: >>>> Em 28/10/2011 15:05, Paulo Henrique BSD Brasil escreveu: >>>>> Leonardo, >>>>> >>>>> I/O não se limita a hardware, se o sistema ou o driver da controladora >>>>> possuir alguma problema ou limitação isso se reflete na performace do >>>>> hardware. >>>>> >>>>> Creio que no caso do companheiro pode ser problema de configuração do >>>>> sistema. >>>> Opa Paulo, >>>> >>>> Pois é o problema aqui foi só com essa base de dados mesmo, as outras >>>> foram bem rápidas. E tipo no acesso está normal, só tive esse problema >>>> mesmo na importação da sql. :) >>>> O I/O do servidor não é alto, é um servidor de correio sem tráfego alto, >>>> não passa de 1.5Mbps ;) >>>> Outra coisa é que usei uma máquina muito fraca pra puxar esse backup. >>>> Pouco processamento e pouca memória. >>>> >>>>> Att. >>>>> >>>>> Em 28/10/2011 14:46, Leonardo Augusto escreveu: >>>>>> Vou se dar uma sugestao de amigo. >>>>>> >>>>>> Nao existe servidor que o IO de disco fique bom sem um raid 10(por >>>>>> exemplo) numa boa controladora dedicada a isso... >>>>>> >>>>>> Se o teu problema for IO de disco.. pense em por uma controladora >>>>>> descente e monte um raid 10, se quer desempenho. >>>>>> >>>>>> []´s >>>>>> >>>>>> >>>>>> 2011/10/28 Marcelo Gondim<[email protected]>: >>>>>>> Em 28/10/2011 11:48, Leonardo Augusto escreveu: >>>>>>>> Esta fazendo insert em myisam ou innodb ? >>>>>>> Em myisam >>>>>>>> Innodb precisa ser configurado corretamente, ele so funciona bem com >>>>>>>> muita ram. >>>>>>>> Uma dica, é a de configurar o innodb para gerar um arquivo para cada >>>>>>>> tabela, e com isso nao socar tudo naquele mega file ibdata.... >>>>>>>> Quanda vc tem mega tabelas, facilita em muito a manutencao, >>>>>>>> principalmente a liberacao de espaco fisico, ja que o ibdata nao >>>>>>>> regride o tamanho.. >>>>>>>> E quanda é um file per table, vc da um drop table e libera o espaco >>>>>>>> fisico.. >>>>>>>> >>>>>>>> http://dev.mysql.com/doc/refman/5.0/en/innodb-multiple-tablespaces.html >>>>>>>> >>>>>>>> Voce tunou o kernel do seu bsd ? Ou é o generic ? >>>>>>> Kernel tá tunado. >>>>>>> >>>>>>>> O fs esta como ? soft_updates ? Quanto tem de ram na maquina ? >>>>>>> soft_updates. quanto à ram a máquina que está com o hd só tem 2Gb mesmo >>>>>>> :( mas esse hd irá para a máquina definitiva que é um quad com 8Gb de >>>>>>> ram. Só to usando essa máquina para baixar o backup para o sistema novo >>>>>>> mesmo. >>>>>>> Tudo indica que são os índices mesmos e anotei o lance do innodb com >>>>>>> múltiplas table spaces. :) >>>>>>> >>>>>>>> 2011/10/28 Marcelo Gondim<[email protected]>: >>>>>>>>> Em 28/10/2011 10:52, Welkson Renny de Medeiros escreveu: >>>>>>>>>> Marcelo Gondim escreveu: >>>>>>>>>>> Olá pessoal, >>>>>>>>>>> >>>>>>>>>>> Montei um sistema FreeBSD novo em um HD Sata II cujo teste de >>>>>>>>>>> velocidade >>>>>>>>>>> deu uns 85MB/s usando o dd como testador. Até aqui tranquilo. >>>>>>>>>>> No servidor Linux eu fiz um mysqldump da base que levou um tempo >>>>>>>>>>> considerável de uns 20 minutos por aí me gerando um arquivo SQL de >>>>>>>>>>> 1.6Gb. >>>>>>>>>>> Eis que peguei esse sql e fui importar no MySQL do FreeBSD que >>>>>>>>>>> montei, >>>>>>>>>>> coisa que até agora fazia normalmente sendo que dessa vez já tem 4 >>>>>>>>>>> horas >>>>>>>>>>> que está importando e ainda não acabou. >>>>>>>>>>> Coloquei até um time na frente do comando para que quando acordasse >>>>>>>>>>> pudesse ver o tempo que levou mas acordei e ainda está fazendo. >>>>>>>>>>> >>>>>>>>>>> Tirando a possibilidade do hd estar com problemas porque havia >>>>>>>>>>> feito uns >>>>>>>>>>> testes e não tinha encontrado nada, alguém faz idéia do que pode >>>>>>>>>>> estar >>>>>>>>>>> causando essa lentidão absurda? :( >>>>>>>>>>> >>>>>>>>>>> Instalei o mytop para ver o que ocorria e tá lá a instrução: >>>>>>>>>>> >>>>>>>>>>> MySQL on localhost >>>>>>>>>>> (5.0.92-log) >>>>>>>>>>> up 0+05:05:26 [09:59:23] >>>>>>>>>>> Queries: 1.3k qps: 0 Slow: 758.0 >>>>>>>>>>> Se/In/Up/De(%): >>>>>>>>>>> 00/86/00/01 >>>>>>>>>>> qps now: 1 Slow qps: 0.0 Threads: 2 ( >>>>>>>>>>> 2/ 1) >>>>>>>>>>> 00/00/00/00 >>>>>>>>>>> Key Efficiency: 89.0% Bps in/out: 64.2k/ 1.3k Now in/out: >>>>>>>>>>> 21.0/202.8k >>>>>>>>>>> Master: mysql-bin.000004/130386302 do: ign: >>>>>>>>>>> >>>>>>>>>>> 4 root localhost amavisd 0 >>>>>>>>>>> Query INSERT >>>>>>>>>>> INTO `msgs` VALUES >>>>>>>>>>> (0,'Xd-lNqGsr21c','OAKrnkFF6DbX','03004-03-238',1302211535,'20110407T212535Z',1 >>>>>>>>>>> 9 root localhost amavisd 0 >>>>>>>>>>> Query show >>>>>>>>>>> full processlist >>>>>>>>>>> >>>>>>>>>>> 9 root localhost amavisd 0 >>>>>>>>>>> Query show >>>>>>>>>>> full processlist >>>>>>>>>>> 4 root localhost amavisd 8 >>>>>>>>>>> Query INSERT >>>>>>>>>>> INTO `msgs` VALUES >>>>>>>>>>> (0,'Xhh-6D2A2Km3','uZFrbYygiyc3','15174-04',1313098381,'20110811T213301Z',16434 >>>>>>>>>>> >>>>>>>>>>> 9 root localhost amavisd 0 >>>>>>>>>>> Query show >>>>>>>>>>> full processlist >>>>>>>>>>> 4 root localhost amavisd 29 >>>>>>>>>>> Query INSERT >>>>>>>>>>> INTO `msgs` VALUES >>>>>>>>>>> (0,'Xhh-6D2A2Km3','uZFrbYygiyc3','15174-04',1313098381,'20110811T213301Z',16434 >>>>>>>>>>> >>>>>>>>>>> 9 root localhost amavisd 0 >>>>>>>>>>> Query show >>>>>>>>>>> full processlist >>>>>>>>>>> 4 root localhost amavisd 14 >>>>>>>>>>> Query INSERT >>>>>>>>>>> INTO `msgs` VALUES >>>>>>>>>>> (0,'XmRZtbsqKoWA','Fy5S22U8sVHv','27252-03-28',1302225807,'20110408T012327Z',12 >>>>>>>>>>> >>>>>>>>>>> Pensei: nossa o mysql deve estar consumindo uns 200% de CPU e aí no >>>>>>>>>>> top >>>>>>>>>>> vejo que ele está apenas com 0.00%: >>>>>>>>>>> >>>>>>>>>>> 2092 mysql 12 44 0 489M 119M ucond 0 18:47 >>>>>>>>>>> 0.05% mysqld >>>>>>>>>>> 2134 root 1 44 0 19900K 4708K sbwait 1 0:21 >>>>>>>>>>> 0.00% mysql >>>>>>>>>>> >>>>>>>>>>> No dmesg não acusa nenhuma mensagem e nem no messages. Realmente não >>>>>>>>>>> entendo porque não acabou de importar ainda >>>>>>>>>> Uma boa prática na inserção de grandes quantidades de dados é antes >>>>>>>>>> remover os índices. >>>>>>>>>> Quando concluir a inserção, recria. >>>>>>>>>> >>>>>>>>>> Isso melhora o muito o desempenho. >>>>>>>>>> >>>>>>>>>> Índice é bom para consulta, para inserção deixa o processo bem mais >>>>>>>>>> lento. >>>>>>>>>> >>>>>>>>> Tranquilo :) vou esperar agora que já tá fazendo mesmo rsrsrsrsrs >>>>>>>>> mas >>>>>>>>> pode ser isso mesmo. >>>>>>>>> >>>>>>>>> Valeu pela luz pessoal. >>>>>>>>> > > ------------------------- > Histórico: http://www.fug.com.br/historico/html/freebsd/ > Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd > -- Alessandro de Souza Rocha Administrador de Redes e Sistemas FreeBSD-BR User #117 Long live FreeBSD Powered by .... (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
