[FUG-BR] Importação de SQL muito mas muito lento

Alessandro de Souza Rocha etherlinkii em gmail.com
Sábado Outubro 29 09:00:07 BRST 2011


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 <gondim em bsdinfo.com.br> 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<lalinden em gmail.com>  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<gondim em bsdinfo.com.br>:
>>>> 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<gondim em bsdinfo.com.br>:
>>>>>>> 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<gondim em bsdinfo.com.br>:
>>>>>>>>> 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


Mais detalhes sobre a lista de discussão freebsd