File Server Performance (AREV Specific)
At 10 APR 2000 02:28:35PM Jim Dierking wrote:
Our Novell 4.11 file server just crashed after only three years
of duty… This machine was a Pentium II with 196 megs of ram
2gb scsi drive and performed well. Our new backup server waiting in the
wings has been deployed, but the performance is much slower…
It is a Pentium III with dual processors, a 9gig scsi.
Some performance issues I would appreciate feedback on:
1. Is it better to have a smaller drive for accessing AREV vs
a larger scsi?2. I added long name space to the new file server. Does this in fact significantly affect file access performance as I have been told in the past?
3. I have been told that putting too much ram in the file server can
actually reduce performance? Is this true?4. I previously had two novell servers on our tree. When I put up the new server I get a SAP network address error at the file
server monitor. Am I correct in assuming that I just need toupdate the Novell tree database to correct this? And, does aSAP error slow down file access?TIA, for your valuable feedback, Jim Dierking.
PS: Suggestions for optimal server configurations are welcome.
At 10 APR 2000 03:23PM Steve Smith wrote:
Jim,
It's been a few years since I commissioned a Novell server, so take these as ideas for consideration only (not gospel)
(a) Give Novell a separate volume.
(b) Ensure that the AREV volume is 2Gb in size, but not over 2.1 gB. If your application is large add 1.7 gB + application size in bytes=volume size.
© Use cluster sizes when formatting / compsurfing Novell of 4096 bytes.
(d) Ensure that the lock table on the server is quite large (there are notes re this in the Novell setup - do some calcs - qty of users * 40=required lock table # of entries (even if you use NLM).
(e) Leave sufficent space on the SYS volume for spooled print files
(f) Never have too many files in the ROOT path
(g) Don't have too long a file path to AREV if you are not using the NLM (lock conflicts) \AREV\AREV.EXE is ideal. This saves memory in your application (file handles are smaller) and expedites IO.
(h) keep your capture.exe's from earlier versions (eg. 3.11) as these are smaller memory-wise.
(i) disable transaction tracking (TTS) and compression on volume.
(j) RAM should be 256 mB or under
(k) separate server for AREV is best scenario.
(l) remove sound cards, elaborate video and other unnecessary peripherals from the server box.
(m) an extra network card or two should be mounted to your server box during install, so that you can potentially run more segments to your server (this can halve card-based IO bottlenecks on systems with more users).
(n) if your SCSI has room, run a second partition for an AREV backup partition - then use NCOPY /S to generate your backups to this partition.
(o) the less protocols on your client, the better the result. So if another server runs 802.3, you should run 802.3 as the default protocol and so on. If it runs 802.2, you should run 802.2.
(p) don't use long filename support
(q) increase cache buffers
® don't use the Novell SBACKUP utility to create your new server
Hope this helps,
Steve
At 11 APR 2000 02:27PM Don Miller - C3 Inc. wrote:
Steve..
I'd be super-cautious about NCOPY unless you have the patches installed to disable the Turbo-Fat! I've seen this make a total mess out of a backup (which makes it useless). Otherwise, your suggestions are right on the money. Sometimes you'll get a conflict if you use the earlier versions of CAPTURE. I remember this crashing Win-95B.
Don Miller
C3 Inc.