Im Folgenden finden Sie die E-Mail, die ich an Mitglieder auf Host3 und Host5 gesendet habe. Meistens gilt dies nur für frühe Mitglieder - Mitglieder, die eingesetzt wurden, bevor ich die Gelegenheit hatte, die Vorlagendateisysteme zu aktualisieren. Es kann nicht schaden, einen Blick auf Ihre Cron-Zeiten zu werfen. Das Entfernen oder zumindest das Verschieben der updatedb-Cron-Zeit von täglich auf wöchentlich würde helfen.
——
Liebes Linode-Mitglied,
Um die Festplatten-E/A-Last auf Ihrem Host-Server zu reduzieren, bitte ich Sie
den folgenden Befehl (als root) für Ihre Distribution auszuführen:
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
Keine Änderung notwendig
Dadurch wird der Job "updatedb" nicht mehr täglich, sondern nur noch wöchentlich ausgeführt. Der
Befehl "updatedb" indiziert Ihr gesamtes Dateisystem neu, so dass Sie Dateien
schnell mit dem Befehl "locate (Dateiname)" finden können. Wenn Sie nicht oft den Befehl
"locate"-Befehl selten benutzen, können Sie die Indexaktualisierung auf wöchentlich verschieben (oder den Cron-Job komplett löschen).
komplett löschen), kann dies die Last in den frühen Morgenstunden verringern. Derzeit,
der Rechner zu einem Kriechgang, während viele Linodes versuchen, ihre Dateisysteme
Dateisysteme neu zu indizieren.
Auf neueren Hosts ist dies kein so großes Problem, da ich die Vorlage
Dateisysteme geändert habe und die Leute diese Dateien bereits verschoben haben.
Wenn Sie die Änderung vornehmen und es keine Meldung über eine nicht gefundene Datei gibt (was bedeutet, dass die Datei bereits verschoben wurde), senden Sie mir bitte eine E-Mail.
dass sie bereits verschoben wurde), schreiben Sie mir bitte eine E-Mail und lassen Sie es mich wissen.
Ich danke Ihnen,
-Chris
Kommentare (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.