[technique] Problème avec picbackup

[Emmanuel Courcelle]

Le 31/07/2017 à 10:58, Mehdi Abaakouk a écrit :
> Bonjour,
>
> Il semblerai que ce soit parce que 'tar' soit oom killer:
>
> # dmesg | grep 'Killed.*(tar)'
> [10011987.862479] Killed process 23630 (tar) total-vm:24292kB,
> anon-rss:5676kB, file-rss:1032kB
> [10014201.854420] Killed process 23679 (tar) total-vm:23748kB,
> anon-rss:5160kB, file-rss:1068kB
> [10628925.769733] Killed process 467 (tar) total-vm:23208kB,
> anon-rss:4684kB, file-rss:1048kB
> [10629371.273167] Killed process 478 (tar) total-vm:22268kB,
> anon-rss:3636kB, file-rss:1084kB
>
> Tu ne vois pas le problème sur /dev/vda parceque les écritures et
> lectures sont sur un disque différent. Tar n'a pas le temps
> d'utiliser beaucoup de RAM que les data sont déjà écrites.
>

Bonjour Mehdi

Merci pour ta réponse

ça doit être ça, même si je ne comprends pas trop cette différence de 
comportement: /dev/vda est-il plus beaucoup rapide que /dev/vdb ?

En regardant mieux le dmesg, je vois que tuer des processes pour cause 
de oom est une pratique assez courante sur cette machine... :-(. ça 
craint un peu car je vois que des rsync se font tuer, donc il y a des 
trucs qui ne doivent pas être correctement sauvegardés, même si nous 
avons toujours pu restituer ce dont nous avions besoin.

Pourrait-on la passer à 1 Go au lieu de 512 Mo ? (à coûts constants si 
possible...)

Merci d'avance,
Emmanuel


>
> On Sun, Jul 30, 2017 at 05:06:53PM +0200, Emmanuel Courcelle via 
> technique wrote:
>> Bonjour
>>
>> J'ai un souci avec picbackup (89.234.156.206 ou 
>> 2a03:7220:8083:ce00::1), hébergé chez tetaneutral. Cette machine a 
>> deux volumes montés:
>>
>> root at picbackup:/backup/d_pic/20170730/tree/pic/sympa# mount
>> sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
>> proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
>> udev on /dev type devtmpfs 
>> (rw,relatime,size=10240k,nr_inodes=62184,mode=755)
>> devpts on /dev/pts type devpts 
>> (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
>> tmpfs on /run type tmpfs 
>> (rw,nosuid,noexec,relatime,size=50884k,mode=755)
>> */dev/vda1 on / type ext3 
>> (rw,relatime,errors=remount-ro,user_xattr,acl,barrier=1,data=ordered)**
>> *tmpfs on /run/lock type tmpfs 
>> (rw,nosuid,nodev,noexec,relatime,size=5120k)
>> tmpfs on /run/shm type tmpfs 
>> (rw,nosuid,nodev,noexec,relatime,size=101760k)
>> */dev/vdb on /data/1 type ext4 
>> (rw,noatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)**
>> *
>>
>> J'ai un gros répertoire sur /dev/vdb, je voudrais en faire un fichier 
>> tar. ça marche bien si je mets le fichier tar sur /dev/vda1, mais ça 
>> plante au bout d'environ 2Go si je l'écris sur /dev/vdb, comme le 
>> montre la séquence suivante. Je l'ai fait plusieurs fois, c'est 
>> reproductible.
>>
>> *root at picbackup:/backup/d_pic/20170730/tree/pic/sympa# tar cf 
>> wwsarchive.tar wwsarchive
>> **Processus arrêté*
>>
>> *root at picbackup:/backup/d_pic/20170730/tree/pic/sympa# ls -lh 
>> wwsarchive.tar **
>> **-rw-r--r-- 1 root root 2,2G juil. 30 15:56 wwsarchive.tar**
>> **
>> root at picbackup:/backup/d_pic/20170730/tree/pic/sympa# tar cf 
>> /tmp/wwsarchive.tar wwsarchive **
>> *
>>
>> *root at picbackup:/backup/d_pic/20170730/tree/pic/sympa# ls -lh 
>> /tmp/wwsarchive.tar**
>> **-rw-r--r-- 1 root root 14G juil. 30 16:55 /tmp/wwsarchive.tar**
>> *
>>
>> Je n'ai pas trop d'idées...
>> Amicalement,
>>
>> Emmanuel
>>
>>
>
>> _______________________________________________
>> technique mailing list
>> technique at lists.tetaneutral.net
>> http://lists.tetaneutral.net/listinfo/technique
>
>