Mirror-admin July 2013

mirror-admin@lists.fedoraproject.org

107 participants
1020 discussions

Start a nNew thread

Joukuu is merging with CloudFuze
by CloudFuze 30 Jul '13

30 Jul '13

1 0

One more day for Joukuu
by CloudFuze 30 Jul '13

30 Jul '13

1 0

Aqueça seu inverno
by Reformar Eletro 30 Jul '13

30 Jul '13

Seu visualizador de e-mail está configurado para mostrar a mensagem em formato texto. Para visualizar corretamente o conteúdo desse e-mail copie e cole o link abaixo em seu navegador: http://d-app.maiscontinental.com.br/e/5139/1275/229075/979e4

1 0

Só no Girafa você tem entretenimento por um preço imbatível. Compre agora!
by Girafa 30 Jul '13

30 Jul '13

1 0

Management du changement : L'exemple récent français
by j.naurdet 30 Jul '13

30 Jul '13

Key Partners Savoir piloter les changements dans l'entreprise et la société Les cultures peuvent-elles réellement changer, ou est-ce une vue de l’esprit ? Et si elles peuvent changer, est-ce qu’un changement peut être rapide ou doit-il nécessairement être très long ? Une question se pose de temps en temps à certains : les cultures peuvent-elles réellement changer, ou est-ce une vue de l’esprit ? Et si elles peuvent changer, est-ce qu’un changement peut être rapide ou doit-il nécessairement être très long ? Pour répondre à cela, rappelons au préalable ce qu’est une culture. Culture a deux sens différents. Le premier est synonyme d’érudition et ne nous intéresse pas dans notre contexte. La seconde est définie dans le dictionnaire comme « les attitudes et comportements propres à un groupe social ou à une organisation. » La définition opérationnelle que nous utilisons chez Key Partners pour définir une culture, c’est l’ensemble des points d’accord d’un groupe. Si vous y regardez de près, vous verrez que c’est ce qui sous-tend la définition précédente. Maintenant, voyons si les cultures peuvent changer, et observons le basculement qu’il y a eu entre début 2008 et mi 2009 : nous avons basculé dans une culture de crise. Comment une culture de crise se crée-t-elle ? Revenons début 2008 : à cette époque on parlait plutôt du changement de nos équipes dirigeantes et de l’impact que cela avait ou aurait sur notre vie. Mi 2009, on parle de crise, de chômage, de la peur de ne pas s’en sortir, etc. Est-ce bien une autre culture ? Sans aucun doute. Il y a bien eu un changement d’attitude et de comportement des gens. Les points d’accord ont bien changé. Un pays entier a changé de culture en quelques mois. Donc, si nous sommes passés d’une culture à une autre, comment ce changement s’est-il produit ? Revenons en arrière : 2008, une crise financière balaye le monde bancaire. Il y a peu de raison que cette crise financière devienne une crise économique… sauf que cette crise économique est annoncée comme imminente. A cette époque, qui parmi nos lecteurs a observé de ses propres yeux les ravages d’une crise ? Probablement très peu de personnes. Votre serviteur a même fait un sondage auprès d’un certain nombre de dirigeants d’entreprise : au début du 3ème trimestre 2008, la réponse la plus fréquente était que l’on ne ressentait pas les effets d’une crise, même si tout le monde en parlait. Mais un martèlement répété par tous les canaux médiatiques possibles qu’il y avait une crise était en train de changer les points d’accord des Français. Les médias ont parlé et ont continué à parler de crise (c’est normal, car cela fait vendre plus). Donc les points d’accord sur l’existence d’une crise ont augmenté. Du côté des dirigeants d’entreprise, cela s’est progressivement transformé en « nous ne sommes pas touchés, mais il faut être vigilant », puis « nous ne sommes pas touchés, mais préférons prendre les devants » (c'est-à-dire, commencer à diminuer les achats) ce qui a commencé à gripper l’économie. Ceci explique peut-être la question que se posent beaucoup : comment est-on passé d’une crise financière à une crise économique ? Selon notre avis, c’est par un martèlement médiatique (entre 3 et 6 mois) qui a créé l’accord sur l’existence de la crise et la peur de lendemains lugubres, qui a ensuite généré la crise économique. Mais notre propos est de rester opérationnel et non pas polémique, et d’illustrer la roue du changement. Donc, si l’on revient à la roue du changement, on peut voir que cette répétition médiatique a fait percevoir aux gens qu’il existait une crise, puis les a mis dans un mode de pensée de crise, qui a généré un comportement de crise, jusqu’à ce que beaucoup de gens aient ce comportement, qui est devenu une habitude, et l’on est passé dans une culture de crise. Comment se sortir d'une crise ? Probablement par la même voie. Quand suffisamment de gens seront d’accord que la crise ne peut plus durer, ils commenceront à relancer les achats qui relanceront la croissance qui ralentira la crise puis relancera l’économie. Nombreux sont les économistes qui parlent des cycles de crise. Ils les nomment les cycles Juglar, Kitchin ou Kondratieff selon leur durée. Ils notent aussi que les cycles ont tendance à se raccourcir. Nous pouvons légitimement nous demander si la raison n’est pas tout simplement le temps qu’il faut pour faire changer les points d’accord d’une culture et si l’accélération des cycles ne provient pas de la démultiplication des canaux de communication (journaux, radio, télévision, internet…) ? Quel rapport entre ceci est le management du changement dans une organisation ? C’est que les cultures peuvent changer. S’il ne faut que quelques mois pour faire changer celle d’un pays entier, et même plusieurs pays, on peut sans aucun doute faire aussi changer la culture d’une entreprise, d’une administration, ou d’un groupe social, d’une ville, etc. Changer de culture est quelque chose qui s’organise, et dont la méthode est expliquée au travers de la roue du changement. Apprenez à mettre en pratique le Management du changement [1][PubSeminaire.png] References 1. http://www.key-partners.biz/seacuteminaires.html This message was sent to mirror-admin(a)fedoraproject.org from: Key Partners | 16 Boulevard Saint Germain - CS 70514 | Paris Cedex 05, IDF 75237, France Désabonner: http://app.icontact.com/icp/mmail-mprofile.pl?r=67750824&l=108455&s=GKGM&m=…

1 0

ftp.icm.edu.pl Fedora mirror slow rsync directory listing
by Matt Domsch 29 Jul '13

29 Jul '13

Greetings. I'm the Mirror Wrangler for the Fedora Project, and author of the tool we use to know which mirrors are up-to-date: MirrorManager. We have recently begun using rsync to retrieve the list of files on a particular mirror, if you've registered rsync URLs in MirrorManager (which you have). For most mirrors, rsync directory listings of each of the four Category trees you're carrying (Feodra Linux, Fedora EPEL, Fedora Archive, and Fedora Seconary Arches) is the fastest way to get a full list of what content your mirror has. It falls back to doing FTP DIR listings, and then individual HTTP HEAD requests on a subset of the files, if rsync isn't available. In your case, the crawler takes a relatively long time to retrieve the directory listing from your mirror. By category, I see something like this: 7/26/2013 09:00:15 PM Starting crawl 07/26/2013 09:00:15 PM scanning Category Fedora Linux 07/26/2013 10:19:29 PM rsync time: 1:16:20.570514 07/26/2013 10:25:35 PM scanning Category Fedora EPEL 07/26/2013 10:30:06 PM rsync time: 0:04:21.676678 07/26/2013 10:30:48 PM scanning Category Fedora Secondary Arches (during which the 2-hour cumulative timeout expires, and the crawler is killed. It never completes Fedora Secondary Arches). This is what we're running: rsync --temp-dir=/tmp -r --exclude=.snapshot --exclude='*.~tmp~' --no-motd rsync://ftp.icm.edu.pl/pub/Linux/fedora/linux/ rsync --temp-dir=/tmp -r --exclude=.snapshot --exclude='*.~tmp~' --no-motd rsync://ftp.icm.edu.pl/pub/Linux/fedora/linux/epel/ rsync --temp-dir=/tmp -r --exclude=.snapshot --exclude='*.~tmp~' --no-motd rsync://ftp.icm.edu.pl/pub/Linux/dist/fedora-secondary/ Now, for other mirrors serving rsync such as mirrors.us.kernel.org shown here, we see times such as: 07/27/2013 12:29:05 AM Starting crawl 07/27/2013 12:29:05 AM scanning Category Fedora Linux 07/27/2013 12:31:26 AM rsync time: 0:01:14.965211 07/27/2013 12:34:21 AM scanning Category Fedora EPEL 07/27/2013 12:34:41 AM rsync time: 0:00:12.548085 07/27/2013 12:34:59 AM scanning Category Fedora Secondary Arches 07/27/2013 12:40:12 AM rsync time: 0:02:49.361520 07/27/2013 12:47:02 AM scanning Category Fedora Other 07/27/2013 12:47:13 AM rsync time: 0:00:06.161032 07/27/2013 12:57:27 AM Total directories: 5805 07/27/2013 12:57:27 AM Changed to up2date: 0 07/27/2013 12:57:27 AM Changed to not up2date: 0 07/27/2013 12:57:27 AM Unchanged: 5805 07/27/2013 12:57:27 AM Unknown disposition: 0 07/27/2013 12:57:27 AM New HostCategoryDirs created: 87 07/27/2013 12:57:27 AM HostCategoryDirs now deleted on the master, marked not up2date: 0 07/27/2013 12:57:27 AM Ending crawl The whole process takes under 30 minutes. By relative difference, your mirror is taking 60x more time to serve the same directory list as does other mirrors. I would have to increase the timeout to crawl your mirror from 2 hours to 30 hours, by which point the content would have changed yet again, several times... I raise this because I know you do a good job running your mirror generally, so this seems anomalous. In the past, mirror admins have suggested reducing the value of /proc/sys/vm/vfs_cache_pressure, from the default value 100, to a lower number, causing the kernel to prefer to keep dentries when under memory pressure: https://www.kernel.org/doc/Documentation/sysctl/vm.txt vfs_cache_pressure ------------------ Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will never reclaim dentries and inodes due to memory pressure and this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. Please take a look and see if a change is warranted on your side, or if you see different behaviour for rsync directory listings than I am. Thank you for being a long-standing Fedora mirror. I still had reference to the old sunsite name on our lists from before I took over the role as Mirror Wrangler back in 2006. We appreciate your commitment to Fedora. Thanks, Matt

2 2

HEAnet Fedora tree rsync times are long
by Matt Domsch 29 Jul '13

29 Jul '13

Greetings. I'm the Mirror Wrangler for the Fedora Project, and author of the tool we use to know which mirrors are up-to-date: MirrorManager. We have recently begun using rsync to retrieve the list of files on a particular mirror, if you've registered rsync URLs in MirrorManager (which you have). For most mirrors, rsync directory listings of each of the four Category trees you're carrying (Feodra Linux, Fedora EPEL, Fedora Archive, and Fedora Seconary Arches) is the fastest way to get a full list of what content your mirror has. It falls back to doing FTP DIR listings, and then individual HTTP HEAD requests on a subset of the files, if rsync isn't available. In your case, the crawler takes a relatively long time to retrieve the directory listing from your mirror. By category, I see something like this: 07/26/2013 06:00:13 PM Starting crawl 07/26/2013 06:00:13 PM scanning Category Fedora EPEL 07/26/2013 06:15:20 PM rsync time: 0:14:54.263938 07/26/2013 06:15:35 PM scanning Category Fedora Linux 07/26/2013 07:32:58 PM rsync time: 1:16:25.136438 07/26/2013 07:38:11 PM scanning Category Fedora Archive (during which the 2-hour cumulative timeout expires, and the crawler is killed. It never completes Fedora Archive, and never starts Fedora Secondary Arches). The commands invoked to get the listings are: rsync --temp-dir=/tmp -r --exclude=.snapshot --exclude='*.~tmp~' --no-motd rsync://ftp.heanet.ie/pub/fedora/epel/ rsync --temp-dir=/tmp -r --exclude=.snapshot --exclude='*.~tmp~' --no-motd rsync://ftp.heanet.ie/pub/fedora/linux/ rsync --temp-dir=/tmp -r --exclude=.snapshot --exclude='*.~tmp~' --no-motd rsync://ftp.heanet.ie/pub/fedora-archive/ Now, for other mirrors serving rsync such as mirrors.us.kernel.org shown here, we see times such as: 07/27/2013 12:29:05 AM Starting crawl 07/27/2013 12:29:05 AM scanning Category Fedora Linux 07/27/2013 12:31:26 AM rsync time: 0:01:14.965211 07/27/2013 12:34:21 AM scanning Category Fedora EPEL 07/27/2013 12:34:41 AM rsync time: 0:00:12.548085 07/27/2013 12:34:59 AM scanning Category Fedora Secondary Arches 07/27/2013 12:40:12 AM rsync time: 0:02:49.361520 07/27/2013 12:47:02 AM scanning Category Fedora Other 07/27/2013 12:47:13 AM rsync time: 0:00:06.161032 07/27/2013 12:57:27 AM Total directories: 5805 07/27/2013 12:57:27 AM Changed to up2date: 0 07/27/2013 12:57:27 AM Changed to not up2date: 0 07/27/2013 12:57:27 AM Unchanged: 5805 07/27/2013 12:57:27 AM Unknown disposition: 0 07/27/2013 12:57:27 AM New HostCategoryDirs created: 87 07/27/2013 12:57:27 AM HostCategoryDirs now deleted on the master, marked not up2date: 0 07/27/2013 12:57:27 AM Ending crawl The whole process takes under 30 minutes. By relative difference, your mirror is taking 60x more time to serve the same directory list as does other mirrors. I would have to increase the timeout to crawl your mirror from 2 hours to 30 hours, by which point the content would have changed yet again, several times... I raise this because I know you do a good job running your mirror generally, so this seems anomalous. In the past, mirror admins have suggested reducing the value of /proc/sys/vm/vfs_cache_pressure, from the default value 100, to a lower number, causing the kernel to prefer to keep dentries when under memory pressure: https://www.kernel.org/doc/Documentation/sysctl/vm.txt vfs_cache_pressure ------------------ Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will never reclaim dentries and inodes due to memory pressure and this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. Please take a look and see if you see different behaviour for rsync directory listings than I am, and if the behaviour is indeed not what you would expect, consider what could be done to adjust. I note that you are running report_mirror after each rsync content pull, thank you. If you look, I suspect that too takes a long time, for the same reason. Thanks, Matt

2 2

Galaxy S4 tá no Girafa, ta na mão.
by Girafa 29 Jul '13

29 Jul '13

1 0

ftp.tsukuba.wide.ad.jp Fedora content slow rsync listing
by Matt Domsch 29 Jul '13

29 Jul '13

Greetings. I'm the Mirror Wrangler for the Fedora Project, and author of the tool we use to know which mirrors are up-to-date: MirrorManager. We have recently begun using rsync to retrieve the list of files on a particular mirror, if you've registered rsync URLs in MirrorManager (which you have). For most mirrors, rsync directory listings of each of the Category trees you're carrying (Fedora Linux, Fedora EPEL, Fedora Archive) is the fastest way to get a full list of what content your mirror has. It falls back to doing individual HTTP HEAD requests on a subset of the files, if rsync isn't available, and then FTP DIR if http isn't available. In your case, the crawler takes a relatively long time to retrieve the directory listing from your mirror, using rsync. I see something like this: 07/27/2013 07:00:21 AM Starting crawl 07/27/2013 07:00:21 AM scanning Category Fedora Archive during which the 2-hour cumulative timeout expires, and the crawler is killed. It never completes Fedora Archive, and never starts either of the others. https://admin.fedoraproject.org/mirrormanager/host/1192 is a link to your mirror information in MirrorManager, including a crawler log. Now, for other mirrors serving rsync such as archive.kernel.org shown here, we see times such as: 07/27/2013 05:03:11 AM Starting crawl 07/27/2013 05:03:11 AM scanning Category Fedora Archive 07/27/2013 05:09:40 AM rsync time: 0:04:22.125007 07/27/2013 05:20:21 AM Total directories: 1973 07/27/2013 05:20:21 AM Changed to up2date: 0 07/27/2013 05:20:21 AM Changed to not up2date: 0 07/27/2013 05:20:21 AM Unchanged: 1973 07/27/2013 05:20:21 AM Unknown disposition: 0 07/27/2013 05:20:21 AM New HostCategoryDirs created: 1972 07/27/2013 05:20:21 AM HostCategoryDirs now deleted on the master, 07/27/2013 05:20:21 AM Ending crawl The whole process takes under 20 minutes, the rsync time alone is less than 4 1/2 minutes. Your mirror is taking over 2 hours for same. I raise this because I know you do a good job running your mirror generally, so this seems anomalous. In the past, mirror admins have suggested reducing the value of /proc/sys/vm/vfs_cache_pressure, from the default value 100, to a lower number, causing the kernel to prefer to keep dentries when under memory pressure: https://www.kernel.org/doc/Documentation/sysctl/vm.txt vfs_cache_pressure ------------------ Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. When vfs_cache_pressure=0, the kernel will never reclaim dentries and inodes due to memory pressure and this can easily lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes. Please take a look and see if a change is warranted on your side, or if you see different behaviour for rsync directory listings than I am. Thanks, Matt

2 1

Não deixe para amanhã o que você pode comprar agora no Girafa.
by Girafa 29 Jul '13

29 Jul '13

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mirror-admin July 2013