Home › Forums › OS X Server and Client Discussion › File Serving › CatSearch starting then server crawling….
FWIW
My setup is a xServe G5 DP 2.3Ghz, 10.4.8 PPC, 8GB RAM connected to xServe Raid running 1.5.1 firmware. My AFP server has crawled to a halt and continues to do so. I see the same entries on my afp access log as Moofo (CatSearch…)
My boot drive on the server is a software raid 1 of 2x 80GB drives.
Jason
[QUOTE][u]Quote by: cohey[/u][p]My problem seems to have gone away as well. I had noticed a ‘build_hd_index’ process being kicked off by Apple Remote Desktop that was causing some other issues so I disabled indexing on all of my ARD Admin machines to prevent the process from starting on the server every night. I don’t know if it was coincidental or not but the catsearch problem is now not occurring. If I see the problem again or get any more insight on what was causing it I will post it up here.
Thanks for the help![/p][/QUOTE]
How did you disable the indexing on the remote machine? I’m missing it in the docs or it isn’t listed.
Thanks!
On your ARD admin machines, “Get Info” on the machine you want to disable reporting on. Under the “Data Settings” tab, I unchecked everything because I really have no need to audit my servers. I imagine similar results could be achieved by just unchecking the “File Search” option. Details on these features are on pages 159 and 160 of the ARD Administrator’s Guide.
Also, make sure you do this on all ARD admin machines you connect to your server with. If even just one still has this option checked, it will kick off that process.
Hope this helps!
I don’t think it has anything to do with the problem. ARD index is a totally different beast.
I disabled the indexing by simply adding the drive were the data is to the “Privacy” tab in the Spotlight System preferences pane.
I reproduced the problem many times now, and one of those time, I took continuous Top output as well as AFP log, screenshots of Activity Monitor before, and while the problem is occuring.
Sent that to Apple Engineering. There is definitely a problem with AFP server.
They should come back to me soon.
Thanks cohey!
[QUOTE]I first thought it was retrospects fault but…[/QUOTE]
I’m noticing what seems to be a correlation between Retrospect and my server slowdown. I can’t yet confirm anything but looking into it. Do you have Retrospect client installed on your server or are you running Retrospect from the problem server itself? I have Retrospect client 6.1.130 running on my xServe.
The one thing that would hint that its not Retro’s fault is that in the afp logs, the CatSearch shows up for a specific connected afp user.
Just frustrating… my server slows almost once/day now and its not exactly easy to kick everyone out and restart afp.
Yes Retrospect (Not the client, the full app) is running on the server.
[url=http://forums.dantz.com/ubbthreads/showflat.php?Cat=0&Board=Desktopworkgrupx&Number=93657&Searchpage=1&Main=93657&Words=+Moofo&topic=&Search=true#Post93657]I first thought it was retrospect[/url] (My thread at EMC)
However, further analysis of logfiles and continuous Top Output proved to demonstrate a problem with the AFP server.
Just for your info, I reproduced the problem without Retrospect running on the server. I doubt it has anything to do with it.
And yes I’m P***** Apple Enterprise is working on it since december. I got a very rude phone call from them today. I guess I was being too inquisitive.
I gave them:
Screenshot of activity monitor before it happens
Screenshot of activity monitor while it happens
Countinuous top output (fresh from a reboot) from a “Clean state” to a “Problem state”
Countinuous AFP output (fresh from a reboot) from a “Clean state” to a “Problem state” with one user doing search.
And still “The engineer are working on it” I directed them to this thread and I’m sure they are ignoring it.
Is your real memory usage of “Kernel Task” jumping to inordinate amounts ?
I am running Retrospect client on the server, not the full app.
Looking at the logfiles I noticed “CatSearch starting [share point]” only seems to show up for certain users of thet server. Actually, only those people in my Studio department. I have other departments using this server.
As of right now, the log shows two machines registering the “CatSearch” stuff. They are both G5 stations, one is running 10.4.7 and the other is running 10.4.8. The users have been using InDesign v4.0.2 all day. Both machines are bound via LDAP. Both accounts are local user accounts.
Update: These are the only machines that had outdated versions of InDesign running on them. My Studio users use ID all day long. All my users were at ID 4.0.4 w/ the exception of the two machines that were showing up w/ the CatSearch in the logs.
I just restarted AFP on the server so nothing to report as of yet. I’ll monitor memory usage of Kernel Task as well.
Update: This morning I checked the AFP logs on my server and noticed the CatSearch stuff again. As always it is coming from one of my Studio users logged into the Studio afp share. Only one machine was creating the CatSearch in the logs and when I checked the machine I noticed it was running InDesign 4.0.0. In the process of updating that to InDesign 4.0.4. So far, none of my machines running ID 4.0.4 have been registering the CatSearch in the afp logs. My guess is now that the offending machine has been updated, the CatSearch in the logs will be gone.
With that said, I am not 100% certain the slowdown of the AFP server is directly related to the CatSearch stuff although it would seem that way. Processes CPU % and memory usage on the server are normal as of now.
I have users in my studio using the latest version of ID and it doesn’t make a difference.
Try the following:
Log in SSH to your server from a machine and run top “top -ovsize” It will sort the output by VirtualMemory Size
Then from the same machine or another, mount a volume on your server and do a file find.
While the search is running, look at the top output, especially the RSIZE column.
There you have your proof. I don’t know if InDesign is using the search function to look for artwork and related file, but I think it has to do with the problem.
Apple is really slow and not very talky for what I would call a major issue.
Look there
[url]http://discussions.apple.com/thread.jspa?messageID=4014503�[/url]
[url]http://discussions.apple.com/message.jspa?messageID=3995835#3995835[/url]
Is your AFP server tweaked at all? I’ve tweaked my settings according to Nigel Kirsten’s posting at [url]https://www.afp548.com/article.php?story=20060329213629494[/url]. Mainly, my max thread count is 400 and looking at the AFP server right now, it shows 402 threads. I am seeing the CatSearch in the logs again, and AFP is dog slow, however ‘kernel_task’ appears to be consistent… right around 335M for RSIZE and 1.7GB for VSIZE. The machine as 8GB ram total. I checked this against another server also running 10.4.8 but with way less users and so far, no problems and its about the same.
Kernel_task runs around 5-10% cpu as well.
Another issue is after I perform a find on the mounted volume, even if I cancel the fint, I can’t unmount the volume (says its in use) and the CatSearch crap continues to show in the logs until an AFP server reboot.
And yes… to me this is a major major issue. The reason I have the xServe in this case is for AFP and AFP alone. If it can’t do that really well that is a bad bad thing.
Called Apple Ent. They said they have a fix for this issue. The guy I spoke with today was very nice and knew about the issue. You need to edit the rc.server file to release the ram after the find is performed. This file only exists on Universal installs but the tech told me to copy the file from one of my Univ servers to my non ones and it should work just fine.
1. Make a copy of /etc/rc.server.
$ sudo cp /etc/rc.server /etc/rc.server.bak
2. In the text editor of your choice, make the following change to /etc/rc.server. You will need to edit this file as the root user.
Locate this line in /etc/rc.server:
sysctl -w kern.maxnbuf=90000
Change the line to read:
sysctl -w kern.maxnbuf=20000
Save the changes you have made to /etc/rc.server.
3. Verify the changes were made to /etc/rc.server
4. Reboot the server.
I tried the fix.
It works ! I was able to do lots of search without Kernel Task gobbling it all up ! Yay !
Awesome! It doesn’t work on PPC installs but they’re working on a fix for me.
Does anyone know if it’s possible on PPC systems (where there doesn’t seem to be an rc.server) to put the kern.maxnbuf=20000 in /etc/sysctl.conf?