Fixing quicklookd going nuts on MacOS

Today I looked into a problem with my father’s late 2012 Mac Mini running MacOS High Sierra. Since about a week the machine got terribly slow and often unresponsive. It turned out the system was extremely busy with   kernel_task and quicklookd as per the screenshot below:

Once the CPU load peak started, it would never reduce, making the system almost unusable until a reboot and started again shortly after logging in to the system. More interesting was that the quicklookd process was using memory like crazy:

So within about 6 minutes of processing time, it was already occupying 45GB! of memory. This kept growing till the use of the Swap memory reached it’s 64GB limit and the process died. Since LaunchDaemon is making sure it runs it then got restarted and the whole process got repeated. Even though the CPU load was high, it did not consume all CPU so the system could still be used but the high IO load on the disk caused by swapping memory still killed the performance (despite having an SSD).

So great, it’s clear what is causing the slow computer though even after spending quite some time on googling the symptoms I could only find (quite a few) others that had similar issues but no solutions. The best hint I saw was referring to a corrupt file so I started checking that first. To get the list of open files of the quicklookd process I ran:

lsof -p `pgrep quicklookd` | less

Browsing through the list of open files, I noticed that there were not real data files in there that could be corrupted. Given the symptom – continuous growing memory usage – I would have expected a single file being processed for a long time, which clearly was not the case and (in my opinion) ruling out the corrupt file theory for now.

As this looked more like an internal data corruption to me I decided to check the other files the processes had open. With this I noticed that it created a sqlite cache (DB), which I have seen getting corrupted in other cases. To get the list of files in the cache directly I ran:

ls -l `getconf DARWIN_USER_CACHE_DIR`/

which produced the following output:

total 57024
-rw-r--r--  1 user staff         0 Nov 24 14:42 dirty
-rw-------  1 user staff         0 Nov  9  2013 exclusive
-rw-r--r--  1 user staff     12288 Nov 24 14:50 index.sqlite
-rw-r--r--  1 user staff         0 Nov 24 14:50 index.sqlite-wal
-rw-r--r--@ 1 user staff  29176786 Nov 24 14:50 index.sqlite.lasterror
-rw-r--r--@ 1 user staff        18 Nov 24 14:42 resetreason

The existence and size of index.sqlite.lasterror drew my  immediate attention and when looking at the contents of the file (with the last line repeated 320k+ times) it was clear that this sqlite database indeed got corrupted.

unexpected behavior of sqllite bridge: (triggered by 14 - database errcode: 14 - unable to open database file)
error while preparing 'SELECT value FROM preferences WHERE key='version''
error while executing 'CREATE TABLE preferences (key TEXT UNIQUE PRIMARY KEY, value TEXT)'

To fix this, I backed out the corrupt data directory with:


and restarted the quicklookd daemon with:

pkill -9 quicklookd

QuickLook re-created a new folder and started creating the icons normally again. CPU Load was normal and the memory usage did not grow anymore.

2 Replies to “Fixing quicklookd going nuts on MacOS”

  1. Thanks Frederik! Seems to have sorted the same problem om my machine, MBP Late2013, OSX Sierra. CPU/memory problem started after a System Update yesterday. Strange. In my case, the file was by far the largest (95503328) but your commands worked.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.