May Kung
03-25-2003, 10:30 AM
This is a continuation from the thread on which OS we'd like to use in a perfect world. The discussion is about how to optimize performance by tinkering with swap file settings and setups.
I'm *guessing* that over time the OSDM/Annotator combo consumes more and more virtual memory, and this is indeed a condition which can slow the whole system down. Clearing the UNDO buffer will not return any virtual memory to the system, so this alone doesn't necessarily make the system any snappier.
That would explain why the hard reboot seems to help.
Invest some effort to configure the page file properly for your systems. Some hints on improving paging performance:
I'll mention it to the sysadmin, but since his full-time job is keeping the email and network servers running, CAD optimization is low on the list. Ditto for me, as my main job is supposed to be design work, not CAD support. We *really* need a full-time person to do such projects, or at least to have such things made a higher priority so it can get some resource. *sigh*
Create a page file partition rather than a page file on the system partition
Do you mean like an actual partition that is separate from the system partition? For example, we currently use 2 partitions, C: and D:. Perhaps we need to make E:, which would be a partition that is only used for the swap file?
Make sure that the page file is on a fast disk
Yep. All the workstations use a single 10K SCSI drive, partitioned into two. Half the page file is on C: and the other half is on D:.
Make sure that the disks in the system use DMA transfers.
Don't think is applicable for SCSI, as it's supposed to do this by default.
Set the page file to a fixed size to reduce file fragmentation.
We currently already do this.
Use a page file defragmentation tool, such as the one from http://www.sysinternals.com
Haven't tried that yet. I'll make a note to try it out when I have some free time.
Choosing the right size of page file is also important, of course.
We've been making the page files twice the physical RAM, fixed in size, split between C: and D:.
If you get a SIGSEGV error message, this is usually not an indication of an instable system, except for some (rare) circumstances where the graphics driver fails. Instead, it is rather an indication that OSDM might have become slightly unstable, possibly because of previous errors or because of inconsistent data. Restarting OSDM is often a good idea in such a case. This should also return all virtual memory to the system, and after some paging activities, overall performance should be close to normal (provided that the page file isn't fragmented). Check for runaway processes after terminating OSDM. Occasionally, especially after crashes, I have seen annotator.exe processes which wouldn't die and still consumed lots of resources.
Hmm. Thanks for the information, Claus. I've noticed sigsegv errors can also spontaneously stop showing up, particularly when dealing with the Move command in Annotation. The segmentation violation errors get pretty nasty at times, in general resulting in a crash within minutes of showing up.
An even better idea in such a case, of course, is to report the SIGSEGV and its circumstances via CoCreate support so that we have a chance to fix those issues .-)
I already do that. It's a bad sign (or maybe a good one? ;)) that CoCreate support reps know me by name.
I'm *guessing* that over time the OSDM/Annotator combo consumes more and more virtual memory, and this is indeed a condition which can slow the whole system down. Clearing the UNDO buffer will not return any virtual memory to the system, so this alone doesn't necessarily make the system any snappier.
That would explain why the hard reboot seems to help.
Invest some effort to configure the page file properly for your systems. Some hints on improving paging performance:
I'll mention it to the sysadmin, but since his full-time job is keeping the email and network servers running, CAD optimization is low on the list. Ditto for me, as my main job is supposed to be design work, not CAD support. We *really* need a full-time person to do such projects, or at least to have such things made a higher priority so it can get some resource. *sigh*
Create a page file partition rather than a page file on the system partition
Do you mean like an actual partition that is separate from the system partition? For example, we currently use 2 partitions, C: and D:. Perhaps we need to make E:, which would be a partition that is only used for the swap file?
Make sure that the page file is on a fast disk
Yep. All the workstations use a single 10K SCSI drive, partitioned into two. Half the page file is on C: and the other half is on D:.
Make sure that the disks in the system use DMA transfers.
Don't think is applicable for SCSI, as it's supposed to do this by default.
Set the page file to a fixed size to reduce file fragmentation.
We currently already do this.
Use a page file defragmentation tool, such as the one from http://www.sysinternals.com
Haven't tried that yet. I'll make a note to try it out when I have some free time.
Choosing the right size of page file is also important, of course.
We've been making the page files twice the physical RAM, fixed in size, split between C: and D:.
If you get a SIGSEGV error message, this is usually not an indication of an instable system, except for some (rare) circumstances where the graphics driver fails. Instead, it is rather an indication that OSDM might have become slightly unstable, possibly because of previous errors or because of inconsistent data. Restarting OSDM is often a good idea in such a case. This should also return all virtual memory to the system, and after some paging activities, overall performance should be close to normal (provided that the page file isn't fragmented). Check for runaway processes after terminating OSDM. Occasionally, especially after crashes, I have seen annotator.exe processes which wouldn't die and still consumed lots of resources.
Hmm. Thanks for the information, Claus. I've noticed sigsegv errors can also spontaneously stop showing up, particularly when dealing with the Move command in Annotation. The segmentation violation errors get pretty nasty at times, in general resulting in a crash within minutes of showing up.
An even better idea in such a case, of course, is to report the SIGSEGV and its circumstances via CoCreate support so that we have a chance to fix those issues .-)
I already do that. It's a bad sign (or maybe a good one? ;)) that CoCreate support reps know me by name.