Skip navigation
This discussion is archived

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

2100 Views 5 Replies Latest reply: Jan 7, 2009 3:02 AM by Alan Trewartha RSS
Ken_Edgar Level 1 Level 1 (30 points)
Currently Being Moderated
Nov 19, 2008 11:04 AM
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 afpwanquantum 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
  • John Weber Calculating status...
    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
    Intel xServe, Mac OS X (10.5.5)
  • Nova Level 2 Level 2 (385 points)
    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.
    I support around 200 Macs at a public/charter school., PowerMacs, iMacs, eMacs, minis, iBooks, PowerBooks, MacBooks, Mac Pros, XServes.
  • SanderZwanenburg Calculating status...
    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!
    iMac 24" 2,8 Extreme C2D 4G-ram, Mac OS X (10.5.5)
  • Alan Trewartha Level 1 Level 1 (20 points)
    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.
    Desktop G5s

Actions

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.