Jordan Miguel Postado Fevereiro 11, 2012 Postado Fevereiro 11, 2012 Jordan, mas isso é normal acontecer com dedicado, pois quando estava usando vps isso não ocorria. Não, isto não é normal ocorrer. Porém, pode haver algo no HD que esteja fazendo com que ocorra.. Primeiro você tem que se certificar que realmente é isto. Pode fazer isto utilizando o iostat, durante a operação.
Andre Juliano Postado Fevereiro 11, 2012 Autor Postado Fevereiro 11, 2012 Vou forçar um bkp incremental agora como o Jordan sugeriu e monitorar. Obrigado a Jefferson e Jordan pelas dicas. WebChamp - Hospedagem de Sites, Revenda de Hospedagem, Revenda de VPS, Servidores Virtuais (OpenVZ / KVM).
Andre Juliano Postado Fevereiro 11, 2012 Autor Postado Fevereiro 11, 2012 Jordan, sabe como testo o uso do HDe o IO dele? WebChamp - Hospedagem de Sites, Revenda de Hospedagem, Revenda de VPS, Servidores Virtuais (OpenVZ / KVM).
Jordan Miguel Postado Fevereiro 11, 2012 Postado Fevereiro 11, 2012 Jordan, sabe como testo o uso do HDe o IO dele? Pode tentar algo como hdparm: hdparm -Tt /drive (por exemplo: /dev/hda)
Andre Juliano Postado Fevereiro 11, 2012 Autor Postado Fevereiro 11, 2012 OK, irei testar. Muito obrigado. WebChamp - Hospedagem de Sites, Revenda de Hospedagem, Revenda de VPS, Servidores Virtuais (OpenVZ / KVM).
Andre Juliano Postado Fevereiro 11, 2012 Autor Postado Fevereiro 11, 2012 Jordan, não sei se ajuda, mas segue o resultado: /dev/sda: Timing cached reads: 3516 MB in 2.00 seconds = 1759.04 MB/sec Timing buffered disk reads: 168 MB in 3.01 seconds = 55.91 MB/sec WebChamp - Hospedagem de Sites, Revenda de Hospedagem, Revenda de VPS, Servidores Virtuais (OpenVZ / KVM).
Andre Juliano Postado Fevereiro 11, 2012 Autor Postado Fevereiro 11, 2012 Rodrigo, veja o que apareceu no log: ]Feb 7 04:02:01 de01 syslogd 1.4.1: restart. Feb 7 04:02:18 de01 kernel: WARNING: at fs/dquot.c:814 dquot_claim_reserved_space() Feb 7 04:02:18 de01 kernel: Feb 7 04:02:18 de01 kernel: Call Trace: Feb 7 04:02:18 de01 kernel: [<ffffffff801065fc>] dquot_claim_space+0xa3/0x110 Feb 7 04:02:18 de01 kernel: [<ffffffff8805a00b>] :ext4:ext4_da_update_reserve_space+0x12e/0x195 Feb 7 04:02:18 de01 kernel: [<ffffffff8806f2b0>] :ext4:ext4_ext_get_blocks+0x14f9/0x167d Feb 7 04:02:18 de01 kernel: [<ffffffff8809f5db>] :raid1:r1bio_pool_alloc+0x20/0x39 Feb 7 04:02:18 de01 kernel: [<ffffffff880a05b0>] :raid1:make_request+0x5c7/0x5d8 Feb 7 04:02:18 de01 kernel: [<ffffffff80023469>] mempool_alloc+0x31/0xe7 Feb 7 04:02:18 de01 kernel: [<ffffffff88058763>] :ext4:ext4_mark_iloc_dirty+0x465/0x4ea Feb 7 04:02:18 de01 kernel: [<ffffffff8805a18d>] :ext4:ext4_get_blocks+0x11b/0x1cf Feb 7 04:02:18 de01 kernel: [<ffffffff8805a351>] :ext4:mpage_da_map_blocks+0xb0/0x678 Feb 7 04:02:18 de01 kernel: [<ffffffff80047d1f>] pagevec_lookup_tag+0x1a/0x21 Feb 7 04:02:18 de01 kernel: [<ffffffff800f6f37>] write_cache_pages+0x164/0x334 Feb 7 04:02:18 de01 kernel: [<ffffffff8805c382>] :ext4:__mpage_da_writepage+0x0/0x167 Feb 7 04:02:18 de01 kernel: [<ffffffff80047cfc>] __pagevec_release+0x19/0x22 Feb 7 04:02:18 de01 kernel: [<ffffffff8803bce4>] :jbd2:start_this_handle+0x305/0x3b7 Feb 7 04:02:18 de01 kernel: [<ffffffff8000ec35>] find_get_pages_tag+0x34/0x89 Feb 7 04:02:18 de01 kernel: [<ffffffff800de927>] alternate_node_alloc+0x70/0x8c Feb 7 04:02:18 de01 kernel: [<ffffffff8805dbf5>] :ext4:ext4_da_writepages+0x338/0x4ff Feb 7 04:02:18 de01 kernel: [<ffffffff8005a8fb>] do_writepages+0x20/0x2f Feb 7 04:02:18 de01 kernel: [<ffffffff8002fa38>] __writeback_single_inode+0x1a2/0x31c Feb 7 04:02:18 de01 kernel: [<ffffffff8002115e>] sync_sb_inodes+0x1b7/0x271 Feb 7 04:02:18 de01 kernel: [<ffffffff800a2d8a>] keventd_create_kthread+0x0/0xc4 Feb 7 04:02:18 de01 kernel: [<ffffffff80050d6a>] writeback_inodes+0x82/0xd8 Feb 7 04:02:18 de01 kernel: [<ffffffff800cc57a>] wb_kupdate+0xef/0x169 Feb 7 04:02:19 de01 kernel: [<ffffffff800562fa>] pdflush+0x0/0x1fb Feb 7 04:02:19 de01 kernel: [<ffffffff8005644b>] pdflush+0x151/0x1fb Feb 7 04:02:19 de01 kernel: [<ffffffff800cc48b>] wb_kupdate+0x0/0x169 Feb 7 04:02:19 de01 kernel: [<ffffffff80032755>] kthread+0xfe/0x132 Feb 7 04:02:19 de01 kernel: [<ffffffff8005dfb1>] child_rip+0xa/0x11 Feb 7 04:02:19 de01 kernel: [<ffffffff800a2d8a>] keventd_create_kthread+0x0/0xc4 Feb 7 04:02:19 de01 kernel: [<ffffffff80032657>] kthread+0x0/0x132 Feb 7 04:02:19 de01 kernel: [<ffffffff8005dfa7>] child_rip+0x0/0x11 Feb 7 04:02:19 de01 kernel: Feb 7 04:02:43 de01 kernel: WARNING: at fs/dquot.c:814 dquot_claim_reserved_space() Feb 7 04:02:43 de01 kernel: "/var/log/messages" [converted] 1288121L, 99617069C WebChamp - Hospedagem de Sites, Revenda de Hospedagem, Revenda de VPS, Servidores Virtuais (OpenVZ / KVM).
Andre Juliano Postado Fevereiro 11, 2012 Autor Postado Fevereiro 11, 2012 Acabei de realizar um fullbkp de todas as contas no modo tradicional e o dedicado não caiu. Deve ser outra coisa que esta sendo executado de madrugada que esta derrubando. :/ WebChamp - Hospedagem de Sites, Revenda de Hospedagem, Revenda de VPS, Servidores Virtuais (OpenVZ / KVM).
Jordan Miguel Postado Fevereiro 11, 2012 Postado Fevereiro 11, 2012 Acabei de realizar um fullbkp de todas as contas no modo tradicional e o dedicado não caiu. Deve ser outra coisa que esta sendo executado de madrugada que esta derrubando. :/ Certo, como foi dito acima, tente desativar o cron para verificar se não há algo que possa estar fazendo isso. Tente pegar o horário exato em que o servidor sai do ar e comparar com o horário dos cron jobs.
Andre Juliano Postado Fevereiro 11, 2012 Autor Postado Fevereiro 11, 2012 Bom, parei o cron. Agora vou verificar se o dedicado ira cair novamente de madrugada. WebChamp - Hospedagem de Sites, Revenda de Hospedagem, Revenda de VPS, Servidores Virtuais (OpenVZ / KVM).
Posts Recomendados