Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Slow reading search drives 2

Status
Not open for further replies.

fbizzell

Programmer
Joined
Jul 3, 2000
Messages
217
When loading programs such as brequest from a search drive it is very slow. If I access the search drive directly it loads immediately. Brequest is in my Public directory so loading it from any directory should work. What is causing it to slow very slo
 
What other information do you want? We are using Netware 5.5 and all of our application are dos programs. We load brequest in order to access btrieve data files. We are also running Pervasive 2000. Even using the simple dos editor EDIT is taking a long time to load from other than the directory where the EDIT.COM is located. All of this was working before it just recently started having this problem. We have made no changes to the server.
 
If I do this at the K:\data prompt: BREQUEST it loads very slowly.

If I do this at the K:\data prompt: Z:\PUBLIC\BREQUEST it loads immediately.

Z:\public is a search directory.
 
There is no such version as NetWare 5.5 so you may want to check - also Service Pack level will help. What version of the NetWare client are you using (is it running in a DOS window on Windows)?

Have you done any upgrades recently?

-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------
 
We are on Netware 5.1 SP Level 6.

The 2000 workstations are using 4.83 SP2 client.

The win98 workstations are using 3.32 client.

 
How many files are in your K:DATA folder (including purgable)? How many search drives do you have and in what order.. How many files are in those folders?

Some DOS based btrieve apps I've seen are really sloppy and leave tons of temp files behind. By tons, I mean 100,000's over the course of a week or so. This is bad for your performance due to the limitations of how DOS handles file searches.

see if this Tid helps.. TID# 10021744

Also, if you understand search drives, you'd realize that when you're in K:DATA, it will look for BREQUEST there first, then go down your list of search drives. So the problem is most likely in either your K:DATA folder or another search drive that gets hit before the SYS:PUBLIC

Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
 
Following on what Marvin said, and to make it easier to see if that is the problem, map sys:public to be the lowest search drive you can. (d or e or even lower if possible), and make sure you don't have any search drive below this one.



Regards

Frederico Fonseca
SysSoft Integrated Ltd
 
You don't necessarily have to have your search mappings at the lowest letter, Z: is appropriate as long as it is also mapped to SEARCH1.

You can force drive letters to search mappings by using the following syntax:

MAP ROOT INS S1:=Z:=SERVER/SYS:PUBLIC

-----------------------------------------------------
"It's true, its damn true!"
-----------------------------------------------------
 
Thanks to everyone for their help on this. I am going to post the mappings as soon as I can get into the computer at the office, but I think that my mapping to z:\public is too far down the list.
 
Here is my mapping. I notice that public is mapped to two different search drives. Is this a problem:

Drives A,B,C,D,E map to a local disk.
Drive F: = FS1_VOL1: \USERS\FBIZZELL\MCS
Drive G: = FS2\VOL1: \APPS\DBASE
Drive H: = FS2\SYS: Drive I: = FS1_ATABOY: Drive J: = FS3\VOL1: \DBDATA
Drive K: = FS1_VOL1: \DBDATA
Drive M: = FS3\VOL1: \USERS\FBIZZELL\MCS2000
Drive N: = FS1_VOL1: \RWC80
Drive Q: = FS3\SYS: Drive U: = SNAPNW\SHARE1: \TRANSFER
Drive W: = FS1_VOL1: \APPS\DBASE
----- Search Drives -----
S1: = Z:. [FS1_SYS: \PUBLIC]
S2: = Y:. [FS1_SYS: \GLOBAL]
S3: = X:. [FS1_SYS: \PUBLIC]
S4: = V:. [FS1_SYS: \NETUTILS]
S5: = C:\NOVELL\CLIENT32
S6: = C:\WINDOWS
S7: = C:\WINDOWS\COMMAND

FS1 is our main server. That is where we run all our applications and central file storage.
 
I don't remember now, but will Windows/Dos search first the PATH variable or the Sx variables?

If PATH is first then you need to look at this one also.



Regards

Frederico Fonseca
SysSoft Integrated Ltd
 
I still think you need to look at the number of files in your K:data folder. How many files total and how many purgable files?

I don't see a problem with the way your search drives are setup. It is most likely a problem within your K:Data folder.



Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
 
The number of files in k:\data is 2700 however the slow reading of a program from the search drive is slow no matter from what directory it is called from. I can be at the f:\users\fbizzell directory for example where I have few files and the slow accessing of the search drive is as bad as it is with k:\data.

Frank
 
The number of files in K:\data is an issue. I had over 5000 files in that directory not the 2700 that I thought. I have reduced the number of files to 3732 and the program I am trying to load from this drive that is in the search drive loads much quicker now. I also misinformed all that I had few files in f:\users\fbizzell. I have over 11000 files in that directory, so obiously running anything out of that directory that must find it in search drive is really slowing me down. THANKS TO ALL FOR YOUR HELP>
 
Also check to see if there are lots of deleted files that need to be purged. They are included in the total number of files, even though you can't see them normally..

You may also be able to tweak your Directory Cache buffers for better performance.

Your defaults for NetWare 5 are 150 (Min) and 500 (Max)... If you look in MONITOR for the number of Buffers in use, if it's at the MAX number, you need to up it.. I'm assuming you have plenty of memory to work with. Don't change it if your available cache buffers is low.

The rule of thumb is this... Look at the Number in use, set the Min Dir Cache Buffers to that. Then double that number and set the max Dir Cache buffers to that. Watch it for a while and then adjust again until you get it to calm down and stay about the same. Just watch your Available Cache Buffers and make sure you don't add directory cache buffers and drain the overall memory pool.


Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top