Slower, slower, until it quits...HELP! (AREV Specific) [Revelation On-Line Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
[[https://www.revelation.com/|Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community]]


==== Slower, slower, until it quits...HELP! (AREV Specific) ====
=== At 05 JAN 1998 10:41:14AM Kevin Wood wrote: ===
 
{{tag>"AREV Specific"}}
 
<QUOTE>
We have a client that is running AREV 2.12 with Novell 3.12 and the AREV NLM 1.10.  They are using ArcServe 4.02n on a server with 256 Mb RAM.  They have about 55 users with 700,000 Customer Records and 1.7 Million Sales Order Records.  They are mirroring servers.  Their orders come in an ascii format and they are converted in AREV.  They have had two incidents where they got a GFE and ran LHVERIFY on the index file which crashed several PCs.  After doing this their primary server began to slow down and continued to slow down until it literaly quit responding.  They dirty cache buffers when through the roof and the system utilization went with them.  They changed primary servers after the first incident and it happened again.  They deleted and recreated the primary index file and turned off indexing on most of the workstations.  All of their hardware has gone through extensive diagnostics and it all checked out OK.  They have had 3 different CNEs in for consultation and all 3 have no idea why Novell would be 

causing this type of problem.  Has anyone seen this before?  Any ideas would be greatly appreciated!



TIA!

kevin



Kevin Wood

Network Manager

Tri-Center Computer, Inc.

http://www.tri-center.com
</QUOTE>
----

=== At 05 JAN 1998 01:13PM Victor wrote:  ===

<QUOTE>I guess one possibility would be that there is a sizelock problem. Check the sizelock and modulo on both the data file and the index file for propriety. If you presized the file in anticipation of a bulk load, the sizelock should be 1 and the modulo some large number. Otherwise, the sizelock should be 0. If you are loading a significant percentage of the file (I haven't done any benchmarks, so I can't point at an exact figure, but I'd guess something on the order of 15% or more), i.e., the amount of data you are loading is more than 15% of the amount of data already in the file, then you are most likely better off removing indexes for the load and then adding them on again after the load completes.



This sort of information should have been pointed out to you by verifylh, though, so I suspect your problem lies elsewhere.



Victor

</QUOTE>

----

=== At 12 JAN 1998 09:23AM John Duquette wrote:  ===

<QUOTE>Kevin,



There are a few things that I can think of that might cause this problem:



1) TTS is enabled

2) A "hot" backup system (i.e. one that monitors what files have changed)

3) The flush dirty cache setting is around 3.3 (this should be set to 1 second or less)



Let me know if this does not help



John Revelation

</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=NONWORKS_READ&SUMMARY=1&KEY=E72B27BE50CCD9E68525658300562C5F|View this thread on the  forum...]]