afp server issue - very hign cpu load

Hi All,

Very interesting (and frustrating) thread! I offer no solutions but agree that killing the process within activity monitor provides some degree of relief. However, within 2 hours, the CPU load is maxxed out yet again. It is also important to note that any user with files open will lose the connection to that file and thus any changes beyond the last save. They will not, however, lose the AFP connection to the server.

In the past, issues like this have been caused by a dodgy file being opened by a client. However, it would seem this time it is not as easy-fixed. Also, it should be noted I am not dealing with user homes etc, rather a number of sharepoints available to multiple users via individual logins.

*Is it possible it was a particular update on the clients that has caused the excessive load?* I ask this because there was no updates performed/changes made on this server at the time the load increased, however it is possible that client updates went ahead. *Perhaps it is an outside influence affecting the AFP Service?*

In our case, it was the 10.5.5 (combo) update that triggered the problem, I cannot 100% say whether it was the server or client side that caused the issue as the update was carried out to both before we noticed a problem but presumably both client and server carry the same (bugged) afp binaries.

10.5.6 does nothing to cure the problem.

10.5.7 maybe? I really hope so...

This problem seems almost identical to an issue that occurred in 10.4.7 <--> 10.4.10.

Pull your finger out Apple....

No news on the ticket that I have open with Apple. I have requested weekly updates and have been informed again that engineers are working on the problem.

I would vote for a client-side cause. I was seeing similar behavior on 10.4.11 server after the clients went to 10.5.6. It seems to be under control after adjusting several variables: Turning off host cache flushing on the XServe RAIDs, turning off logging on the server, and deleting Spotlight indices in the user home directories and reindexing.

OK so now this is really starting to affect our workflow. The CPU loads and InDesign documents crash. I'm unsure if it is directly related but some files (not just InDesign) are also ending up with screwy permissions.

Has anyone experienced similar problems? Can anyone offer any insight into how to avoid the permissions errors at the very least?

Cheers!

I don't think it's a software related problem- we see the CPU loads go thru the roof sometimes when no apps are running- when no one's even in the building.

I'm very interested to read "screwy permissions." I've had another X.5.6 server (that doesn't have the AFP/CPU problem) with really strange permissions- One day admin owned about 30 of 500 users HDs. About an hour after I repaired those (very tedious), admin owned nearly 400 HDs including the ones I had just fixed, and root owned a couple of alphabetical blocks of about 20 users each in just one of four shares. The fifth and final share point was fine.

As an attempt to rule out everything, I downgraded from X.5.6 to X.5.3 with a clean install this weekend. I reconfig'd everything from scratch (except LDAP accounts).

No go. We still get CPU spikes. They seem to happen, as they always have, on about 30 minute increments.

We are still free of the problem - a few days and no CPU hogging going on. we get the occational spikes but they go away. to recap our successful method:
did a reinstall of 10.5.4 server on a iMac 2.0 Alum. Choose the advanced install and ONLY turned on AFP and SMB services - NO DNS OR Open directory services touched. not an option for some i know 😟
all user and group accounts manually added, no home folders or directory services, just filesharing access

DID NOT run software update, except ARA 3.2.2

File sharing as AFP and SMB, standard authentication, we have ACL's active

We have time machine backups on and working (took a weekend for the 'preparing' to complete, but it worked

the only thing left to do is to run software update - which i am sorry to say , i will not risk it, We are finally up and running !

Hi All,

Spoke to Apple Enterprise Techs yesterday. I am assured the issue is known and the update that will resolve it is to be deployed in the not too distant future.

Officially, the only workaround is to kill the AppleFileService process in activity monitor, allowing it to respawn whenever the CPU load reaches its maximum.

It looks like the key here is patience.....

where is the difference between killing AppleFileService in Terminal and in Activitiy Monitor. it's the same process owned by root?

when i kill AppleFileService, i kill a lot of Apps from most of my users at the same time, loosing their preferences (plist), loosing open data etc.

killing AFP is no workaround for more than 100 serverbased users. hope the update is deployed very soon.

There is no difference between killing it in Activity Monitor and Terminal.

When I kill it I need to ask any users in Adobe applications to close the files they are working on. Obviously this is fine for a deployment of 40 computers, none server-based. This work around is definitely not appropriate in your situation.

The tech I spoke to wasn't able to go into too much detail but the issue occurs when 2 or more users are viewing the same sharepoint directory and the dir then refreshes. Very obscure but I think the update is just going thru the usual channels towards distribution so it has to be close.

Kery O wrote:
As an attempt to rule out everything, I downgraded from X.5.6 to X.5.3 with a clean install this weekend. I reconfig'd everything from scratch (except LDAP accounts).

No go. We still get CPU spikes. They seem to happen, as they always have, on about 30 minute increments.

Are you sure you are talking about the same problem Kery?

Your description of 30 minute spikes sounds like they come and go, rather than the CPU hitting 100% (or 200%, or 400%, or 800% depending on no. of cores) and staying their solid until afp is killed as most people are experiencing.

I have seen momentary spikes to 100% in the past each time a PHD / Mobile account user syncs when 'Server-Side File Tracking for Mobile Sync' is switched on in S/A. Do you have PHDs set to sync on a 30 minute cycle?

Also, if we are talking about the same problem, did you downgrade server and clients to < 10.5.5 or just servers?

All the best

Which OS and which Adobe applications are the clients running?

I'm running 10.4.11 on a xserve G5 2Ghz/6GB. It has no problems whatsoever serving files to Tiger clients.
Leopard 10.5.6 clients running CS2 applications will bring the server to it's knees quite frequently.

When this happens, killing AppleFileServer only has effect for a few seconds. Almost immediately the load goes through the roof again and stays there until the Leopard clients are rebooted or until all Adobe and other "rosetta applications" on the Leopard clients are all closed.

So it looks like Rosetta might be the culprit.


Funny to see my old G4 server, running panther, having no problems at all serving files to both Tiger and Leopard clients.
I'm not using networked home directories. All spotlight indexing and generation of DS_Store files is disabled. I've tried about every possible quantum or cache setting without success.

Codeus: I'm not sure. Daily, with classes logging in, the CPU pegs with AFP the culprit. It will max for 5-20 minutes or so and then drop to normal. During the spikes, the clients (X.4.11) are useless until the CPU usage drops again.

This weekend I downgraded only the server to X.5.3- I have since returned the original X.5.6 drives to it. The clients are almost entirely X.4.11 with a handful of X.5.x clients. There are ~20 PHDs, but syncing has been turned off.

Frustrating to see there is still no fix for this. What I did to fix this was move all of my student home folders to NFS. NFS is way way faster and treads much lighter, the down side? Not all that secure, but my students don't really keep anything in their homes that needs securing. It took some messing with to make work but if someone wants details, AIM (iChat) WindozBreakerG4 and I can try to get you going.