Vous trouverez ci-dessous l'email que j'ai envoyé aux membres sur host3 et host5. La plupart du temps, cela ne s'applique qu'aux premiers membres - ceux qui ont été déployés avant que je n'aie eu le temps de mettre à jour les systèmes de fichiers des modèles. Cela ne peut pas faire de mal de jeter un coup d'œil à vos temps de cron. Supprimer, ou au moins déplacer le temps de cron de updatedb de quotidien à hebdomadaire pourrait aider.
--
Cher membre de Linode,
Afin de réduire la charge d'E/S sur le disque de votre serveur hôte, je vous demande d'exécuter la commande suivante (en tant que root) pour votre distribution
d'exécuter la commande suivante (en tant que root) pour votre distribution :
Debian
mv /etc/cron.daily/find /etc/cron.weekly/
RedHat
mv /etc/cron.daily/slocate.cron /etc/cron.weekly/
Gentoo
mv /etc/cron.daily/slocate /etc/cron.weekly/
Mandrake :
mv /etc/cron.daily/slocate.cron /etc/cron.weekly/
Slackware
mv /etc/cron.daily/slocate /etc/cron.weekly/
Fedora
Pas de changement nécessaire
La tâche "updatedb" passe ainsi d'une exécution quotidienne à une exécution hebdomadaire. La commande
La commande "updatedb" réindexe l'ensemble de votre système de fichiers, afin que vous puissiez retrouver rapidement les fichiers à l'aide de la commande "locate (nom de fichier)".
rapidement les fichiers à l'aide de la commande "locate (filename)". Si vous n'utilisez pas souvent la commande
Si vous n'utilisez pas souvent la commande "locate", le fait de déplacer la mise à jour de l'index à une fréquence hebdomadaire (ou de supprimer complètement la tâche cron)
complètement) permettra de réduire la charge pendant les premières heures de la matinée. Actuellement,
l'hôte ralentit pendant que de nombreux Linodes tentent de ré-indexer leurs
systèmes de fichiers.
Le problème ne se pose pas autant sur les nouveaux hôtes, puisque j'ai modifié les systèmes de fichiers du modèle et que les gens ont déployé avec ces fichiers déjà déplacés.
et que les gens ont déployé des systèmes avec ces fichiers déjà déplacés.
Si vous effectuez le changement et qu'il ne se plaint pas d'un fichier non trouvé (ce qui indique qu'il a déjà été déplacé), envoyez-moi un courriel pour me le faire savoir.
qu'il a déjà été déplacé), envoyez-moi un courriel pour me le faire savoir.
Nous vous remercions,
-Chris
Commentaires (3)
[quote:90ec82635e=”caker”]Below is the email I sent to members on host3 and host5. Mostly this only applies to early members — member’s that deployed before I had a chance to update the template filesystems. It couldn’t hurt to take a look at your cron times. Removing, or at least moving the updatedb cron time from daily to weekly would help.
[/quote]
I would like to add that if you do not move your daily cron jobs to weekly as mentioned, or delete them, that you at least “randomize” the times that your daily cron jobs run. This is probably the best way to solve this problem as it allows you to install services as normal and not worry about whether they put cron jobs in daily or weekly, and yet help prevent huge loads on the Linode host at specific times. To do this, simply edit your /etc/crontab file, under the # run-parts entry.
Here is an example section from an /etc/crontab file:
[code]
# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
[/code]
These indicate that cron.hourly jobs run at 1 minute past the hour, cron.daily jobs run at 4:02 am every day, cron.weekly jobs run at 4:22 am every Monday, and cron.monthly jobs run at 4:42 am on the first day of each month.
An example random change would be:
[code]
# run-parts
16 * * * * root run-parts /etc/cron.hourly
25 6 * * * root run-parts /etc/cron.daily
45 6 * * 2 root run-parts /etc/cron.weekly
55 6 3 * * root run-parts /etc/cron.monthly
[/code]
This moves the hourly jobs to the 16th minute of every hour, dailies to 6:25 am, weeklies to Wednesday at 6:45 am, and monthlies to 6:55 on the third day of each month.
If we all stagger our times randomly like this, we can go a long way towards eliminating some common performance bottlenecks on Linodes.
Thanks!
In addition to ‘randomising’ start times, I schedule maintenance cron jobs after hours or on weekends, 😀
Just a reminder that each time you upgrade the package containing the “find” utility (in Debian, it’s “findutil”), the cron job will likely be unpacked into /etc/cron.daily again, while the old cron job you have moved into /etc/cron.weekly will be left there as an orphan.
So remember to move /etc/cron.daily/(find|slocate(.cron)?) back to /etc/cron.weekly (overwriting the orphan) after each upgrade of the parent package.