suggestd daemon is memory & cpu pig how do i clean it up?

Agreed, i had to reboot, and my uptime as of now is 1 day, size is now creeped up to 200 MB. Problem is still there. I don't have support contract with apple, and this machine isn't new enough to log a support instance. It does appear that it is "better", but without knowing root cause(s) for the memory issue then I can't say for sure.

In any even this is a bug that needs to be reported, and not a configuration setting.

Well I did solve the problem. This was overkill because i had to do something because the problem was costing me productivity...

Warning, I've got 20+ years of *nix kernel development so I am telling you what I discovered and how I fixed it. If you don't understand this then consider you probably shouldn't even try because risk is high of screwing things up even worse.

In $HOME/Library/Suggestions you will find several sqlite .db files. I am now booted to 10.12.6 and I made the fix on whatever o/s was current on 21 Sep 2016 because I kept the files. But problem did persist through at least one upgrade. I looked at contents of these databases and they contained information related to rules and string contents and other things related to internet content so that was a good clue..

The $HOME directory is going to be your non-root name like /Users/David .. not root.

then I booted to single user mode, just for safety. You could probably get away with doing this in normal multiuser mode, but make sure you don't fire up browser and disable email and I even turned off internet access to prevent these files from likely being touched. (Again, may be overkill but I didn't want to risk screwing up a database).

Then I simply cd to that directory

mv harvestqueue harvestqueold

mv journals journalsold

(I MAY have done same for some entities-related files, i just don't remember, but I would do these 3 first and see)

then rebooted. The system built new subdirectories and populated them. My post-mortem revealed that the original harvestqueueold/queue sql files were 5+MB, and then it got rebuilt, also the journals subdirectory had a file called snippets that also got repopulated.

I renamed them so I could restore them obviously. I would NOT do anything on web that involves any keychain activity and would not fire up email until you spend some time surfing web and seeing if suggestd footprint stays small. IN my case this was absolutely a cure and i was able to verify.

I apologize for not posting followup until now.

Remember, i am renaming some databases that it did recreate, you can clone the files and work with a copy and use sqlite database to see what those files contain. I did that and only remember thinking I didn't care if it lost that information. Your mileage may vary.

Root cause was absolutely memory leak related to rules in database, or perhaps circular or conflicting rules. Either way, solving problem is going to require removing content from one or more of these files..

Better picture, with contents of subdirectories ...

well, after a system restart it went to maybe 40MB. Now after 3 days of uptime (and huge amount of work, building kernels and such), back to 750MB. It is clear this is a bug, specifically memory leak(s).

Blindly deleting files is what you DO NOT want to do. I decoded the contents of some of the sqlite databases it refers to, and some of the information is old. There is an opportunity here for apple to offer some housekeeping to purge entries.

Look below, the directory listing shows 766MB which pretty much corresponds to what is in memory. You should do the same, looks like webkit is source. Also there are stale directories in the /private/var/folders/g7 ... directory where some of the data files this app stores. You will have to use the activity monitor to determine path for the scratch files the app uses on your PC, but this should give a clue.

I'm in the middle of some projects that take days to finish so can't risk a reboot, but i expect that if I rebooted the system in single-user mode and renamed this private/var directory to save it, and created an empty directory in it's place, then rebooted normally then problem may go away. This should not result in any corruption.

suggestd *should* be running all the time. That is not the problem it is the memory footprint and cpu overhead.

for what it is worth, suggestd was updated in 10.11.3 Release notes indicate that there were "memory corruption" issues in Safari.

As of a few hours worth of use, after installing the O/S, the program is not significantly increasing it's CPU or memory footprint.

It is promising that the Jan 19th update of El Capitan addressed the issue.

(I WISH apple gave detailed release notes on fixes)

New system?? Call apple and tell them. You have free support contract still in force. Put them on the hook to fix it and PLEASE report what you learn, as well as tell them about this thread. The screenshots I provided (you do the same) will be of interest to the developers.

I guarantee at least part of this is a memory leak, so that is a clear bug that they have the power and obligation to fix. The memory footprint shouldn't be growing like this.

Dumping the sqlite database files to ascii text would be revealing, but only if one has the source code to suggestd

Also you shouldn't be deleting those files. Look at screenshots i posted. You need to dig inside the suggestd program and see all the open files it uses. That is where the problem is. The files you deleted basically configure the daemon.