| Title: | SCHEDULER |
| Notice: | Welcome to the Scheduler Conference on node HUMANE ril |
| Moderator: | RUMOR::FALEK |
| Created: | Sat Mar 20 1993 |
| Last Modified: | Tue Jun 03 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1240 |
| Total number of notes: | 5017 |
Hello A customer has DECscheduler 2.1B running on a VAX/VMS 5.5-2 three node cluster. The disks are SCSI devices attached to HSJ controllers with memory cache module and the disks are shadowed. The sched databases have about 1200 jobs, 1500 dependencies and 20 sd classes. At the end of day, about 250 jobs have to run in a short period of time. In that interval DECps shows that the VSS.DAT database I/O load range from 100 to 300 I/O's per second but the disk where it resides shows no queues and good response times. I think that caches, shadowing and a 98% read operations over VSS.DAT permits this high I/O load, however: - Is this high I/O load expected for this configuration? - To keep performance levels we close VERMONT_CREAMERY often and keep VSS.DAT compressed and contiguous but we see that other databases like DEPENDENCY.DAT are not compressed using DB_UTILITY.EXE. - Could we use CONVERT/RECLAIM to free empty buckets in DEPENDENCY.DAT and SCHED$SD_RESTRICTIONS.DAT? - - Any ideas to improve DECscheduler performance appart from these? - Thanks in advance for the response to any of these questions. Jose
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1110.1 | don't chang if performance is good | HLFS00::ERIC_S | Eric Sonneveld MCS - B.O. IS Holland | Wed May 29 1996 14:29 | 37 |
>To keep performance levels we close VERMONT_CREAMERY often and keep VSS.DAT
>compressed and contiguous but we see that other databases like DEPENDENCY.DAT
>are not compressed using DB_UTILITY.EXE.
>- Could we use CONVERT/RECLAIM to free empty buckets in DEPENDENCY.DAT and
> SCHED$SD_RESTRICTIONS.DAT? -
First:
Only start playing around when you think you need to get more
performance then you get, if you're happy - don't do anything.
I'm not sure about the high I/O load, never seen this.
Dependency.dat can always reconstructed from vss. When scheduler does
not find the file nsched process will reconstruct it, but it never does
this in a optimal way, so...
Keep vermont_*.log to sie less than � 5000 blocks,
After db_utility has run - keep scheduler down and perform
$ set def nsched$:
$ ana/rms/fdl vss.dat
$ edit/fdl/nointer/ana=vss.fdl vss.fdl /out=vss_new.fdl
normally this will produce a very good optimsed data file, however look
at the output together with an RMS expert. He/she might be able to
advise turn on/off compression or change bucket sizes.
Then convert the file again
$ conver/fdl=vss_new.fdl vss.dat vss_new.dat
$ rename/log vss_new.dat vss.dat
The same for the two other files, dependency.dat and the Sd-files.
Then start scheduler again.
Once done this and there is less additions/changes/deletions you should
not need to perform this operation more tan e.g. once a year.
Otherwise use the rule to run db_utility (too much deleted jobs) to run
this scripts automated, where you have already the 'perfect' acls ready
Eric
| |||||
| 1110.2 | convert/reclaim will help dependency.dat, but be careful | RUMOR::FALEK | ex-TU58 King | Wed May 29 1996 14:47 | 8 |
I believe that a convert/reclaim on dependency.dat CAN help
performance with that file (if that is a bottleneck). The compress
utility supplied with the scheduler does not touch that file.
| |||||