다음은 host3 및 host5의 회원들께 보낸 이메일입니다. 이것은 대부분 템플릿 파일 시스템을 업데이트하기 전 배포된 멤버인 초기 멤버에게만 적용됩니다. 크론 시간을 본다고 해서 나쁠 건 없습니다. 업데이트된 크론 시간을 제거하거나 적어도 매일 혹은 매주 이동하면 도움이 됩니다.
——
Linode 회원 여러분께,
호스트 서버의 디스크 I/O 부하를 줄이기 위해,
배포 시 다음 명령어를 (root로) 실행할 것을 요청드립니다.
Debian
mv /등/cron.daily/find/etc/cron.weekly/
레드햇
mv /etc/cron.daily/slocate.cron/등/cron.weekly/
젠투
mv /등/cron.daily/slocate/기타/cron.weekly/
만드레이크:
mv /etc/cron.daily/slocate.cron/등/cron.weekly/
슬랙웨어
mv /등/cron.daily/slocate/기타/cron.weekly/
페도라
변경이 필요하지 않습니다.
이렇게 하면 “updatedb” 작업이 매일 실행되는 것에서 일주일에 한 번만 실행되는 것으로 변경됩니다. .
“updatedb” 명령어는 파일을 찾을 수 있도록 전체 파일 시스템을 다시 인덱싱합니다.
“(파일 이름) locate” 명령어를 사용하여 신속하게 자주 사용하지 않는 경우
“locate” 명령어를, 인덱스 업데이트를 주간으로 이동(또는 크론 작업을 완전히 삭제)
하면 이른 아침 시간의 부하를 줄이는 데 도움이 됩니다. 현재
많은 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.