10.4.x clients reporting slow and disconnected afp connections from 10.5.4

Question

Level 1

30 points

10.4.x clients reporting slow and disconnected afp connections from 10.5.4

I have a Leopard server serving a small group of users. Most of the clients are on 10.4 (there may be one on 10.3.9). I have one guy on 10.5.5. The guy on Leopard has not had any issues since he has been on Leopard.

The 10.4 users seem to be experiencing sporadic slowness throughout the day, and sometimes disconnects from the AFP shares. I have not seen anything going on with the server during the times this happens. I even moved a small backup database backup job to run at night rather than during the day. This didn't seem to have any affect.

The data the users are accessing is on a fiber attached raid array. Thought I'd throw that in if it would be of any help.

I am trying the suggestion for tuning afp on Tiger clients by changing the afp wanquantum preference on one of the clients, but I'm thinking that this is not the cause.

Has anyone experienced this? Any help is greatly appreciated.

Thanks,
Ken

Mixed environment

Posted on Nov 19, 2008 11:04 AM

Reply

Answer 1

Nov 20, 2008 7:33 AM in response to Ken_Edgar

Ken,

We are experiencing the same problems. Leopard server (10.5.5) and a mix of Leopard and Tiger clients. All Leopard clients are fine. Problems with many of the Tiger clients. No heavy processor load or network load on the server when the slowdown occurs. Seems to happen more in the afternoon than in the morning. This is a school environment. What is really strange is that the problem seems worse on iMac G5 than on slower eMacs. Something as simple as opening an Appleworks documents can take minutes.

John

Reply

Answer 2

Ken_Edgar Author

Level 1

30 points

Nov 20, 2008 7:59 AM in response to John Weber

That sounds like exactly what it happening to me. Right down to the problem mainly happening in the afternoons. There is nothing happening on the server or the rest of the network that I am aware of each day in the afternoon. CPU and Memory usage is low at these times, and there are probably less than 10 AFP connections at any given time.

I have asked the users to unmount their share points whenever they leave... I have also implemented afp disconnects when a user is idle for an extended period of time. This has not seemed to help either.

Reply

Answer 3

Nova

Level 2

385 points

Nov 20, 2008 3:05 PM in response to Ken_Edgar

same issue. I was having tons of processor overruns from AFP under Server 10.5.4. both 10.5.4 clients and 10.4.9 clients would slow to a crawl when 40 or so clients were logged in. the 2 steps that i took resolved this: first, i upgraded the server and all leopard clients to 10.5.5, and then i stopped auto-mounting a shared group folder, which effectively created 2 connections to the server for every 1 person that logs into a client. therefore, cutting the AFP connections to the server in half.

however, since the 10.5.5 Server update, my 10.4.9 clients now frequently hang at login, or just perform really poorly... as in slower than they should be.

Reply

Answer 4

Dec 3, 2008 12:41 AM in response to Nova

Same issue here. We upgrade lost month to an OSX Leopard 10.5 server and have about 20 Mac Mini's all on 10.4.11, about 10 iMac's on 10.4.11 and 10 Mac Pro's some on 10.4.11 and some on Leopard 10.5.5. The strange thing is that all the trouble come from the Mac Mini's and the iMac's. The problem hasn't been seen on the Mac Pro's, not on the ones with Leopard and not on the ones with Tiger...

But we hadden't any hangs on the login screen though!...yet...

Hope they can fix this soon!

Reply

Answer 5

Jan 7, 2009 3:02 AM in response to Ken_Edgar

Chiming in with another me too! When we noticed it never happens on leopard clients we stepped up our leopard roll out! so far still no leopard client problems.

We had a workround that we deployed multiple times a day which was to 'shake off' the server with an IP change . To expand:

If a client was suspected of having what we called the 'slow homes' issue we checked it out by copying a small 1MB file from the home to the clients local disk. when it wasn't instant - and sometimes it took a loooooong time and tied up finder for a while - then that was proof +ve.

workround was to change the IP address of the client. now we have a DHCP environment (MS-infrastructure of course), so how we did that was

1 - "DHCP with manual address" and assign a known free address (around .150 in that VLAN usually)

2 - find an unused 'sacrificial client' in the same VLAN and set it to "DHCP with manual address" and the original client's address - effectively squatting/occupying that spot from the DHCP-server's PoV

3 - return the original client to plain DHCP and wait for a new address to be assigned.

4 - wait for the mac to sort itself out and do the 1MB copy test. much faster? then sorted

5 - return the sacrificial client to DHCP too

hope this helps someone out there.

Reply