以下は、私がホスト3とホスト5のメンバーに送ったメールです。 ほとんどの場合、これは初期のメンバーにのみ適用されます。つまり、私がテンプレートファイルシステムを更新する前にデプロイしたメンバーです。 cronの時間を見てみるのも悪くないと思います。 updatedbのクーロンを削除するか、少なくとも毎日から毎週に変更すると効果的です。
——
Linodeメンバーの皆様。
お客様のホストサーバーのディスクI/O負荷を軽減するために、お客様のディストリビューションに対して以下のコマンドを（rootとして）実行してください。
以下のコマンドを（rootとして）実行してください。
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/
スラックウェア
mv /etc/cron.daily/slocate /etc/cron.weekly/
Fedora
変更の必要なし
これにより、"updatedb "ジョブは毎日実行されていたものが、週に一度だけ実行されるようになりました。 このように
"updatedb」コマンドは、ファイルシステム全体のインデックスを再作成します。
ロケート（ファイル名）」コマンドでファイルを素早く見つけられるようになります。 ロケート」コマンドをあまり使用しない場合は
"ロケート」コマンドを頻繁に使用しない場合は、インデックスの更新を週1回にする（またはcronジョブを完全に削除する）ことで
を完全に削除）すると、早朝の負荷が軽減されます。 現在は
現在、多くのLinodesがファイルシステムのインデックスを更新しようとすると、ホストが遅くなります。
ファイルシステムの
新しいホストでは、テンプレートのファイルシステムを変更したので、これはそれほど問題にはなりません。
ファイルシステムを修正し、これらのファイルを既に移動した状態でデプロイしたため、新しいホストではそれほど問題になりません。
もし変更してもファイルが見つからないというメッセージが出なければ（既に移動されていることを示す
変更してもファイルが見つからないというメッセージが出なければ（すでに移動されていることを示しています）、私にメールでお知らせください。
ありがとうございました。
-Chris
コメント (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.