I was chasing down another issue (slow "Save As") and thought these two issues may have been related (with QuickLook being the common broken link). Unfortunately, my "Save As" dialog is still miserably slow on the initial load; but IconServicesAgent hasn't gone above 30MB and he rarely makes an appearance in the Console!
Some of these steps may not be necessary, but here are all of the steps I took that inadverdently put IconServicesAgent back in its place. Note: all commands are a single-line, if they appear to be multiple that's just the forum formatting.
-
Check for any QuickLooks related .plist files. In a terminal:
mdfind com.apple.quicklook. -name .plist -
I only had files at the system level (specifically within /System/Library/LaunchAgents/). If you have others, modify the directions below to take that into account (re-introducing plist files from the system level back up to the user).
-
Make some temporary directories to store these plist files, just in case:
mkdir ~/tmp-quicklook -
Kill the IconServicesAgent:
killall -KILL com.apple.IconServicesAgent -
Move the plist files to temporary directories:
sudo mv /System/Library/LaunchAgents/com.apple.quicklook.* ~/tmp-quicklook/ -
Reset QuickLook generators and disk cache:
qlmanage -r && qlmanage -r cache -
Reboot
-
Move plist files back:
sudo mv ~/tmp-quicklook/com.apple.quicklook.* /System/Library/LaunchAgents -
Reboot
From this point on you shouldn't see IconServiceAgent ever go above 30MB on the memory tab; Twitter is actually consuming more memory than IconServiceAgent is right now! You will continue to see entries in your logs but they should only occur once per file type, roughly. I found just scrolling through "All My Files" in Finder really quick took care of most everything and after another reboot and repeating this process - I saw very few, if any, new entries.
If this doesn't work, my only suggestion would be to remove all entries from the user's Login Items and then go through the instructions above (I did this but I don't beleive it was relevant, therefore the ommission).
I had that happen to me on 10.14.6. IconServices went to 8GB in seconds. Killing it, killing Finder and killing it again helped temporarily. Turns out the problem was a huge .rar file that IconServices didn't like for whatever reason. Deleting it in Terminal fixed the problem (didn't need the file anymore).
A few days later it happened again, this time while downloading a 10GB .tar file. Closing the Finder window that showed the directory with the incomplete .tar file and killing IconServices a few times fixed the problem. Memory usage went down and stayed down, no reboot necessary. After the download was complete, IconServices continued to behave.
So it seems IconServices has a problem with some big files. Maybe it tries to read the whole file into memory when searching for a custom icon?