Original question:
Our Unix computer Info:
Model: Alpha Server 1200 5/533 DA-54KHC-DA
CPU: 533 MHz
Cache: 4 MB
RAM: 2507 MB
Hard Drive: More than 100 GB
Operating System: Digital Unix 4.0 E
I found our Unix computer is delayed a few seconds to display from the
screen.
The delayed display is happened every 30 second and lasts about 8-9 second.
I think the reason is because an update process.
The update process executes a sync system call every 30 seconds.
>From the Top program I found when the update process is running it take
96.9% of CPU.
The Top program displayed as below:
load averages: 3.43, 1.10, 0.95
11:47:35
87 processes: 5 running, 5 sleeping, 77 idle
CPU states: 0.0% user, 0.0% nice, 85.8% system, 14.0% idle
Memory: Real: 241M/2507M act/tot Virtual: 2046M use/tot Free: 2031M
PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND
19649 root 53 0 1704K 90K run 26:02
96.90% update
499 root 42 0 6256K 2473K run 5:55
0.00% insightd
456 root 44 0 2376K 163K run 1:26
0.00% svrSystem_mib
20318 zuh 44 0 2616K 401K run 0:00
0.00% top
444 root 44 0 1872K 163K sleep 2:18
0.00% snmpd
460 root 44 0 2944K 663K sleep 0:02
0.00% cpq_mibs
455 root 44 0 2368K 155K sleep 0:01
0.00% svrMgt_mib
873 root 44 0 2944K 475K sleep 0:00
0.00% httpd
19975 root 44 0 4192K 409K sleep 0:00 0.00%
sshd2
Every 30-second delaying 8-9 second is quite inconvenient.
Question:
1. Can I kill this update process and never run it again?
2. Can I change the 30-second to 5 or 10 minutes for the update
process executes a sync system call? How to change it?
3. Why does the update process take so many percentage usages
on CPU? Even it doesn't have many and big jobs on this Unix computer.
4. Can I limit the update process percentage usage on CPU?
5. Any other method to fix this problem?
Thank you!
Answers:
1. No. Read the manual page for the command that you can
understand what it does.
2. Maybe. Read the manual page. I think it is run from
/etc/inittab, so read up on init(8) as well.
3. Because it has a lot of work to do. Track down my previous
message to understand why. The problem is not update(8) taking a lot of
time, but why update(8) needs a lot of time. I'll explain this again below.
4. See if you can find anything on class scheduling. The Master
Index might be a good place to start. You might be able to, but I doubt you
want to.
Update flushes the buffer cache on a regular basis. If it doesn't,
dirty data will stay in the cache until:
o A clean buffer is needed, which means a dirty one will be
written.
o Some application or user runs the sync(1) command.
o The particular file system is unmounted.
o The system crashes and the data is lost.
With the cache full of dirty data, the 2nd one is going to be far worse than
what you see now.
Also, if the system crashes, all that dirty data will be lost. Individual
applications may use to flush their own buffers or use synchronous write in
the first place, but most don't.
As I probably mentioned previously, see what you can find on "smooth sync".
This is a feature of some versions (V4.0E might be one of them), that tries
to even out the heavy I/O load from a very dirty cache being flushed. The
tuning guide may offer other suggestions on how to limit the amount of dirty
data in the cache.
Finally, if a specific application is writing large amounts of data and you
have control of that application's source, you may want to have the
maintainers investigate ways of controlling the amount of dirty data and
write load from within the appilcation.
The manual page for fsync(2) is a good place to start.
Thanks lot for help!
Performing:
I rebooted the machine then it is OK.
Now, the Top program shows the update process as below:
#top
load averages: 0.00, 0.00, 0.00
09:08:27
37 processes: 2 running, 12 sleeping, 23 idle
CPU states: 0.0% user, 0.0% nice, 0.2% system, 99.6% idle
Memory: Real: 12M/2507M act/tot Virtual: 2046M use/tot Free: 2330M
PID USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND
26 root 42 0 1704K 90K sleep 0:00
0.00% update
Received on Thu Jan 17 2002 - 14:22:04 NZDT