Absent Member.
Absent Member.
3386 views

Slow CIFS on OES2 SP4

We are trying to implement client-less logins for our students and I'm encountering a problem that I can't resolve.

I have an NSS volume that is shared through CIFS. On this volume, I have a folder called std which contains all of our students' folders. There are roughly 20,000 folders in total.

I can map to the share and go directly to my test user's folder. Here I can see all of the files and do whatever I want with them. The problem I have is if I try to drill down to this folder instead of going directly to it. (ie: open Windows Explorer, click on my mapped drive then click on the std folder). The hourglass spins and spins then I get an error saying that "the specified network name is no longer available".

Just for testing purposes, I created a second volume and recreated the same folder structure but only moved 6 folders instead of the 20,000. I can drill down to it and see all of the 6 folders right away.

If I use the NW client to connect, I can drill down and see my folders. It's a bit slow but at least I'm seeing the expected results. It's only when connecting through CIFS that I get the errors.

I have ran the online update and it has nothing new to update so I'm assuming that I am all patched up. I checked the log files and they are not reporting any errors. I'm pretty sure that it's only a tuning issue but I cannot find any information that tells me what to tune. I have gone through the NSS tuning guide and adjusted the cache buffer values as suggested but it hasn't helped.

Any help would be greatly appreciated.

Mario
Laurentian University
Labels (2)
Tags (3)
0 Likes
5 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

I'm assuming by OES2 SP4, you mean you're on OES2 SP3 on SLES 10 SP4?

I've got a similar call open to Novell and I don't think it's been resolved yet. There's a problem with CIFS (and also NCP) when you have lots of small files and lots of directories.

The problem is more "obvious" with CIFS than NCP for some reason, but I've gotten the same thing. But only on certain data sets (ie, 230 GB of data, but that is comprised of like 1 million files most of which are 2kb or smaller) in thousands of directories.

Note: I can take that same dataset and EVENTUALLY copy it to a native NTFS on Windows 2008 Server and have similar problems. Windows Explorer, accessing its own local NTFS volume with that same dataset will either time out (the flashlight eventually stops moving around) and then it'll give false results like:
0 files found,
or
23 directories found (but there's really like 1,000 directories with thousands of subdirectories in each one).

But a native "dos" command will show the correct results.

However, the only difference in that case is that Windows 2008 doesn't give you a "specified name no longer available".

My client devices are windows XP although I got the same results on Windows 2008 server using CIFS as well.
I don't know about Windows 7

I'll see if I can prod Novell again for any details on my SR.
0 Likes
Absent Member.
Absent Member.

Yes, you are correct with the patch levels... it's OES2 SP3 on SLES 10 SP4

I'm also seeing the same problem when using the Migration Wizard from the OES server. If I select a bunch of folders from the source and drag them to the target, the wizard creates the folders right away but at the rate of about 1 per minute. To me, this looks like some kind of timeout issue. Could it be an LDAP problem? I will try pointing to a different LDAP server and see if it makes a difference. I also don't have a replica on this server. I wonder if it would help if I did? Something to try I guess.

I'm seeing pretty much the same symptoms as you are. If I go into the folder with all of the files on the OES server and do an 'ls', it lists all of the files right away without any delay. Too bad I can't say the same when doing it from a CIFS share!
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Okay this is what I've gotten back so far. Keep in mind this is specific to my "odd" dataset that I sent into Novell. Also keep in mind that this is what Novell tested with a server with 8 GB of RAM. YMMV. These settings DO consume RAM so be careful. I'd strongly suggest TESTING this as much as possible (sometimes it's hard to test on a test lab vs. on your live server):

... the biggest improvement came with the NCP cache settings. This is what we changed the settings to, which gave us the best mix, as our server only had 8 Gb of RAM.

MAXIMUM_CACHED_FILES_PER_SUBDIRECTORY 100000
MAXIMUM_CACHED_FILES_PER_VOLUME 1000000
MAXIMUM_CACHED_SUBDIRECTORIES_PER_VOLUME 1500000
ADDITIONAL_SSG_THREADS 25

The biggest change was the Cached Subdirectories parameter. If you have more memory, you can give more than the 1.5 million I have allocated here.


--Kevin
0 Likes
Absent Member.
Absent Member.

Thanks Kevin,

I implemented those settings and it sure speeded up the NCP connections. At least that part is taken care of.

However, it didn't do a thing for my CIFS issue or the Migration Wizard. For the wizard, I had completely overlooked the fact that it uses LDAP to authenticate and more than likely uses that protocol to figure out permissions. I'll do some research on how I can improve performance on that side. I am fairly new at this stuff so it's baby steps but at least we're getting somewhere.

Mario


kjhurni;2153699 wrote:
Okay this is what I've gotten back so far. Keep in mind this is specific to my "odd" dataset that I sent into Novell. Also keep in mind that this is what Novell tested with a server with 8 GB of RAM. YMMV. These settings DO consume RAM so be careful. I'd strongly suggest TESTING this as much as possible (sometimes it's hard to test on a test lab vs. on your live server):

... the biggest improvement came with the NCP cache settings. This is what we changed the settings to, which gave us the best mix, as our server only had 8 Gb of RAM.

MAXIMUM_CACHED_FILES_PER_SUBDIRECTORY 100000
MAXIMUM_CACHED_FILES_PER_VOLUME 1000000
MAXIMUM_CACHED_SUBDIRECTORIES_PER_VOLUME 1500000
ADDITIONAL_SSG_THREADS 25

The biggest change was the Cached Subdirectories parameter. If you have more memory, you can give more than the 1.5 million I have allocated here.


--Kevin
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Hello Mario,

I'm not 100% sure on the miggui, but I thought it made an NCP connection and utilized TSA/SMS for the transfer method.

What I would suggest is for the MIGGUI/File transfer part, please post a new thread in the Migration sub-forum for OES. Ramesh (the developer for the miggui) is usually reading that forum and he's very keenly interested in any feedback for the migration utility.

CIFS on OES2 does utilize NCP underneath it all, but I do believe that CIFS (in its current forum) will never be as fast as NCP on OES2 alone in this case (ie, there are some connection limits with CIFS like how many active connections on a given server, etc.)

--Kevin
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.