Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

mediaanalysisd, photoanalysisd and photolibraryd

N0ne1eft said:
SIP madness.
Click to expand...
SIP madness? Please elaborate.
I consider madness to have processes like the ones discussed in the thread, routined & navd running without user knowledge and consent.

"routined is a per-user daemon that learns historical location patterns of a user and predicts future visits to locations."
"navd uses your location, calendar event's location and traffic conditions to generate hypotheses about when you need to leave"
 
bogdanw said:
SIP madness? Please elaborate.
Click to expand...
I meant other solutions online suggested disabling SIP in an attempt to permanently disable mediaanalysisd from launchd (with mixed results), it needs SIP disabled because mediaanlaysisd is a system service. I don't really want to mess with SIP for stability reasons, so suppressing it by excluding drive in spotlight indexing is better than disabling a system service. I am happy knowing it is no longer scanning my photos for the OCR and face detection features I don't need on my external backup HDD 24/7.
 
Today, mediaanalysisd decided to run while my laptop wasn't plugged in, and ate 20% of my laptop's battery in a few minutes. :confused:

I found that it's configured to run via the file /System/Library/LaunchAgents/com.apple.mediaanalysisd.plist, where it's configured as follows:

<key>RequiresExternalPower</key>
<false/>
<key>Priority</key>
<string>Maintenance</string>
<key>ResourceIntensive</key>
<false/>

The ResourceIntensive=false tag... :rolleyes:
 
Last edited:
Today I noticed that disk space was almost completely full on an older MacBook that was left online only as an APFS network share server, but otherwise mostly unused (too old and too slow for much else). It was sharing volumes on an externally mounted Drobo RAID array, but otherwise was unused.

A few weeks ago, I noticed the system became unresponsive.
Then, I noticed that com.apple.imdpersistence and com.apple.imdpersistence.IMDPersistenceAgent launchd Daemons were running and consuming almost ALL RAM on the system.

I shut them each down with:

Bash: 
launchctl stop com.apple.imdpersistence

launchctl stop com.apple.imdpersistence.IMDPersistenceAgent

I left the system alone again for a few weeks. Today, I came back to find that almost ALL disk space on the internal system Data volume was full!

Running DaisyDisk.app, and the POSIX find command, I found that the culprit was some SQLite3 database files being accessed by photolibraryd and mediaanalysisd:

Bash: 
find ~/Library -size +1G

~/Library/iTunes/iPhone Software Updates/iPhone_4.0_64bit_13.2_17B84_Restore.ipsw
~/Library/iTunes/iPhone Software Updates/iPhone_4.0_64bit_12.4.1_16G102_Restore.ipsw
~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal

sudo lsof ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
COMMAND   PID     USER   FD   TYPE DEVICE     SIZE/OFF       NODE NAME
photolibr 748 exampleuser    5u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   12u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   20u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   31u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   38u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
mediaanal 36424 exampleuser    7r   REG    1,5 126882016752 8711819778 ~Library//Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
mediaanal 36424 exampleuser   10r   REG    1,5 126882016752 8711819778 ~/Library//Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal

$ ls -lh ~/Library//Photos/Libraries/Syndication.photoslibrary/database/
total 251815656
drwxr-xr-x@ 11 exampleuser  staff   352B Oct 14  2024 .
drwxr-xr-x@  8 exampleuser  staff   256B Aug 15 06:15 ..
drwxr-xr-x@  3 exampleuser  staff    96B Sep 23  2023 .Photos_SUPPORT
-rw-r--r--@  1 exampleuser  staff   298B Sep 23  2023 DataModelVersion.plist
-rw-r--r--@  1 exampleuser  staff   1.7G May 21 10:57 Photos.sqlite
-rw-r--r--@  1 exampleuser  staff   235M Aug 15 06:24 Photos.sqlite-shm
-rw-r--r--@  1 exampleuser  staff   118G Aug 15 06:25 Photos.sqlite-wal
-rw-r--r--@  1 exampleuser  staff   444B Apr 22 12:56 Photos.sqlite.lock
-rw-r--r--@  1 exampleuser  staff    48K Sep 23  2023 metaSchema.db
-rw-r--r--@  1 exampleuser  staff    48K Sep 23  2023 photos.db
-rw-r--r--@  1 exampleuser  staff     0B Sep 23  2023 protection

I also found some large old iPhone software updates, but those are unrelated to these daemons, were much smaller, and can be deleted safely. So, I focused on the SQLite files and photolibraryd first.

It can be observed that photolibraryd opens these files, and periodically mediaanalysisd also does (see above). Running that lsof command again later only shows that photolibraryd was still running while mediaanalysisd had stopped:

Bash: 
sudo lsof ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal

COMMAND   PID     USER   FD   TYPE DEVICE     SIZE/OFF       NODE NAME
photolibr 748 exampleuser    5u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   12u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   20u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   31u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   38u   REG    1,5 126882016752 8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal

sudo lsof -p $(pgrep photolibraryd )

COMMAND   PID     USER   FD   TYPE DEVICE     SIZE/OFF                NODE NAME
photolibr 748 exampleuser  cwd    DIR    1,5          384              627552 ~/Library/Containers/com.apple.photolibraryd/Data
photolibr 748 exampleuser  txt    REG    1,5       719936 1152921500312565718 /System/Library/PrivateFrameworks/PhotoLibraryServices.framework/Versions/A/Support/photolibraryd
photolibr 748 exampleuser  txt    REG    1,5        47144          8786940317 /Library/Preferences/Logging/.plist-cache.Emz91ENc
photolibr 748 exampleuser  txt    REG    1,5       297536 1152921500312783165 /usr/lib/libobjc-trampolines.dylib
photolibr 748 exampleuser  txt    REG    1,5    246382592          8711819779 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-shm
photolibr 748 exampleuser  txt    REG    1,5        32768          8617081827 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite-shm
photolibr 748 exampleuser  txt    REG    1,5       202800 1152921500312266607 /System/Library/Frameworks/FileProvider.framework/OverrideBundles/CloudDocsFileProvider.bundle/Contents/MacOS/CloudDocsFileProvider
photolibr 748 exampleuser  txt    REG    1,5       204912 1152921500312266618 /System/Library/Frameworks/FileProvider.framework/OverrideBundles/FileProviderOverride.bundle/Contents/MacOS/FileProviderOverride
photolibr 748 exampleuser  txt    REG    1,5       526960 1152921500312266632 /System/Library/Frameworks/FileProvider.framework/OverrideBundles/FinderSyncCollaborationFileProviderOverride.bundle/Contents/MacOS/FinderSyncCollaborationFileProviderOverride
photolibr 748 exampleuser  txt    REG    1,5       233968          8780397739 /private/var/db/timezone/tz/2025a.1.0/icutz/icutz44l.dat
photolibr 748 exampleuser  txt    REG    1,5     30399984 1152921500312794992 /usr/share/icu/icudt70l.dat
photolibr 748 exampleuser  txt    REG    1,5      2177216 1152921500312783145 /usr/lib/dyld
photolibr 748 exampleuser  txt    REG    1,5     27971344 1152921500312795120 /usr/share/langid/langid.inv
photolibr 748 exampleuser  txt    REG    1,5       466296 1152921500312488669 /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/Resources/tokruleLE.data
photolibr 748 exampleuser  txt    REG    1,5      6105232          8711791033 /System/Library/AssetsV2/com_apple_MobileAsset_LinguisticData/57dfe54591169394d709a70c6875765df82226bd.asset/AssetData/embedding.dat
photolibr 748 exampleuser  txt    REG    1,5       521520          8711848744 ~/Library/Containers/com.apple.photolibraryd/Data/Library/Caches/PFTimeZoneData.index
photolibr 748 exampleuser  txt    REG    1,5       679936 1152921500312118022 /System/Library/ColorSync/Resources/ColorTables.data
photolibr 748 exampleuser  txt    REG    1,5       136152 1152921500312200271 /System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/SystemAppearance.car
photolibr 748 exampleuser  txt    REG    1,5        71320 1152921500312200257 /System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/FauxVibrantDark.car
photolibr 748 exampleuser  txt    REG    1,5      7214792 1152921500312200245 /System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/DarkAqua.car
photolibr 748 exampleuser  txt    REG    1,5      6194600 1152921500312200275 /System/Library/CoreServices/SystemAppearance.bundle/Contents/Resources/VibrantDark.car
photolibr 748 exampleuser  txt    REG    1,5       117025          8801061743 /private/var/db/analyticsd/events.allowlist
photolibr 748 exampleuser  txt    REG    1,5      8716288          8801129239 /private/var/folders/f0/49hvn6tn71723n4840d566vm0000gn/0/com.apple.LaunchServices.dv/com.apple.LaunchServices-3028-v2.csstore
photolibr 748 exampleuser    0r   CHR    3,2          0t0                 317 /dev/null
photolibr 748 exampleuser    1u   CHR    3,2          0t0                 317 /dev/null
photolibr 748 exampleuser    2u   CHR    3,2   0x1abea411                 317 /dev/null
photolibr 748 exampleuser    3w   REG    1,5          444          8760483559 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite.lock
photolibr 748 exampleuser    4u   REG    1,5   1875808256          8711819772 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser    5u   REG    1,5 126882016752          8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser    6u   REG    1,5    246382592          8711819779 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-shm
photolibr 748 exampleuser    7w   REG    1,5          444          8760483536 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite.lock
photolibr 748 exampleuser    8u   REG    1,5    292167680          8617081822 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser    9u   REG    1,5      1697472          8617081826 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   10u   REG    1,5        32768          8617081827 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite-shm
photolibr 748 exampleuser   11u   REG    1,5   1875808256          8711819772 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   12u   REG    1,5 126882016752          8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   13u   REG    1,5    292167680          8617081822 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   14u   REG    1,5      1697472          8617081826 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   15u   REG    1,5     97879552          8711862351 ~/Library/Photos/Libraries/Syndication.photoslibrary/resources/derivatives/thumbs/4532.ithmb
photolibr 748 exampleuser   16r   REG    1,5   1875808256          8711819772 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   17u   REG    1,5     27977216          8711862352 ~/Library/Photos/Libraries/Syndication.photoslibrary/resources/derivatives/thumbs/4133.ithmb
photolibr 748 exampleuser   18u   REG    1,5   1875808256          8711819772 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   19u   REG    1,5      7136768          8711862353 ~/Library/Photos/Libraries/Syndication.photoslibrary/resources/derivatives/thumbs/3356.ithmb
photolibr 748 exampleuser   20u   REG    1,5 126882016752          8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   21u   REG    1,5    292167680          8617081822 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   22u   REG    1,5      1697472          8617081826 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   23u   REG    1,5    292167680          8617081822 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   24u   REG    1,5      1697472          8617081826 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   25u   REG    1,5    196682496          8712514799 ~/Pictures/Photos Library.photoslibrary/resources/derivatives/thumbs/4532.ithmb
photolibr 748 exampleuser   26u   REG    1,5     56218368          8712514800 ~/Pictures/Photos Library.photoslibrary/resources/derivatives/thumbs/4133.ithmb
photolibr 748 exampleuser   27u   REG    1,5     14340864          8712514801 ~/Pictures/Photos Library.photoslibrary/resources/derivatives/thumbs/3356.ithmb
photolibr 748 exampleuser   28r   REG    1,5       679936 1152921500312118022 /System/Library/ColorSync/Resources/ColorTables.data
photolibr 748 exampleuser   29u   REG    1,5   1875808256          8711819772 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   30u   REG    1,5    292167680          8617081822 ~/Pictures/Photos Library.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   31u   REG    1,5 126882016752          8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal
photolibr 748 exampleuser   32u   REG    1,5   1875808256          8711819772 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   33u   REG    1,5   1875808256          8711819772 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   35r   REG    1,5   1875808256          8711819772 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
photolibr 748 exampleuser   38u   REG    1,5 126882016752          8711819778 ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite-wal

So, we can see that photolibraryd is the longer-term running daemon, and that it opens other files in .photoslibrary directory "bundles" too.
What are these SQLite databases and why are they so large? Well, it turns out that someone has investigated the issue:

These files evidently have something to do with the "Shared with You" feature of iCloud & iMessage. That's apparently Apple's official name for this, but the internal Photos library is called the "Syndication Photo Library". It uses a directory structure similar to the standard Photos.app photo library, with SQLite database files located under:

  • ~/Library/Photos/Libraries/Syndication.photoslibrary/database/
  • ~/Pictures/Photos Library.photoslibrary/database/
So, these files in the "Syndication" photo library are stored in a similar way to the standard Photos app. The contents seem to be generated by iMessages and shared files from other family members or friends with iCloud. Why the write-ahead logs for SQLite grew so large, I can only guess... but something seems wrong or badly engineered if they are growing that large without cleanup or VACCUUM.

Also, remember that com.apple.imdpersistence that was using an extremely large amount of RAM before? It turns out that this daemon is the background process also related to syncing iMessage messages, photos and other data from and iCloud.

So, something went horribly wrong on this old Monterey MacBook that involved gigabytes of data being synced and stored in this "Syndication" photos library and related SQLite database files.

Now the question, is how to clean this mess up and prevent it from happening again?

System: MacBook Pro (Retina, 13-inch, Early 2015) (MacBookPro12,1)
OS: macOS Monterey (see sw_vers output below)

Bash: 
sw_vers

ProductName:    macOS
ProductVersion:    12.7.6
BuildVersion:    21H1320
 
Last edited:
  • Like
Reactions: gilby101
Digging further into this, I found some useful info about SQLite3 write-ahead logs and how they might grow to large sizes.

The SQLite3 docs were helpful in this regard:

So based on the documentation for SQLite, we can see that the write-ahead log files can grow to large size in certain situations. Apple must have created one of these situations by their design of the Syndication.photoslibrary & "Shared With You" photos features.

We can inspect the current settings of the SQLite3 database as follows. Note that because SQLite3 supports multiple readers & writers at once, this is fine to do without stopping any of the related Apple services (e.g. photolibraryd, mediaanalysisd, and photoanalysisd).

In a terminal, we can open the file with the sqlite3 command, and look at the WAL & VACUUM related settings:

SQL: 
sqlite3  ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
SQLite version 3.37.0 2021-12-09 01:34:53
Enter ".help" for usage hints.
sqlite> PRAGMA journal_mode;
wal

sqlite> PRAGMA journal_size_limit;
32768
sqlite> PRAGMA wal_autocheckpoint;
1000

sqlite> PRAGMA auto_vacuum;
2
sqlite> PRAGMA freelist_count;
0
sqlite> PRAGMA secure_delete;
2
sqlite> .quit

Here, we see the values of some SQLite settings related to the write-ahead log (a.k.a journal), the current auto vacuum setting, and the secure delete setting. These can all be read about further in the SQLite documentation starting here. You might choose later to change some of these settings, but note that only some of them are persistent after the sqlite3 .quit command, while some others such as wal_autocheckpoint revert to their old value the next time the database is opened. I won't go into this here, and know that doing so might affect database performance and impact how Apple's daemons interact with the database. However, since Apple's engineers seem to have created a situation where the write-ahead log is growing to extremely obnoxious levels, and my old MacBook Pro is on the latest version of macOS (Monterey) that it's capable of running thanks to Apple's EOL (and planned obsolescence), I'm changing my auto_vacuum setting to 1 / FULL. Hopefully this will avoid this WAL file growing too large in the future for my old machine, since I can not benefit from any bugfixes that Apple might have made in later OS versions.

Whether or not we choose to change some settings, we can address the WAL file & disk space issue by truncating it. So...

Next, we can shutdown the services to ensure that no other process is reading or writing to the SQLite database or write-ahead log files. In some situations, the VACUUM or WAL-related commands can block read & write for other concurrent processes using the database. Since the WAL file has grown to extraordinary size and we need to address that, we might as well avoid conflict or database file write blocking so we can slim down the size of those files.

Bash: 
launchctl disable gui/$UID/com.apple.photoanalysisd
launchctl disable gui/$UID/com.apple.photolibraryd
launchctl disable gui/$UID/com.apple.mediaanalysisd

launchctl kill -TERM gui/$UID/com.apple.photoanalysisd
launchctl kill -TERM gui/$UID/com.apple.photolibraryd
launchctl kill -TERM gui/$UID/com.apple.mediaanalysisd

Once those daemons are disabled and killed, we can verify that nothing else is using the SQLite database file:

Bash: 
sudo lsof ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
# Should return no processes

Next, we can open the SQLite database and change some settings related to the WAL file size limit and wal_autocheckpoint.

Then, we issue the PRAGMA wal_checkpoint(TRUNCATE) command to force the WAL file entries to be processed and truncate the file. That should address the immediate issue where the WAL file has consumed all disk space. Finally, we can run the VACUUM command to slim down the size of the Photos.sqlite database, and issue another forced WAL truncate command PRAGMA wal_checkpoint(TRUNCATE), for good measure and to ensure the VACUUM operation hasn't re-increased the WAL file size again.

SQL: 
sqlite3  ~/Library/Photos/Libraries/Syndication.photoslibrary/database/Photos.sqlite
sqlite> sqlite> PRAGMA journal_size_limit=0;
0

sqlite> sqlite> PRAGMA wal_autocheckpoint=500;
500

sqlite> PRAGMA  wal_checkpoint(TRUNCATE);                                                                                                                                                                                       
0|0|0

sqlite> VACUUM;

sqlite> PRAGMA  wal_checkpoint(TRUNCATE);                                                                                                                                                                                       
0|0|0

sqlite> .quit

Last but not least, we can check the size of the Photos.sqlite-wal file, to make sure that it's been zereoed out.

Bash: 
ls -lh  ~/Library/Photos/Libraries/Syndication.photoslibrary/database/              
total 2739416
-rw-r--r--@ 1 exampleuser  staff   298B Sep 23  2023 DataModelVersion.plist
-rw-r--r--@ 1 exampleuser  staff   1.3G Aug 15 12:31 Photos.sqlite
-rw-r--r--@ 1 exampleuser  staff    32K Aug 15 12:49 Photos.sqlite-shm
-rw-r--r--@ 1 exampleuser  staff     0B Aug 15 12:31 Photos.sqlite-wal
-rw-r--r--@ 1 exampleuser  staff    48K Sep 23  2023 metaSchema.db
-rw-r--r--@ 1 exampleuser  staff    48K Sep 23  2023 photos.db
-rw-r--r--@ 1 exampleuser  staff     0B Sep 23  2023 protection

🎉 Success! So, now the Photos.sqlite-wal file has zero size (down from 118G !!), and the Photos.sqlite database file has been vacuumed from 1.7G down to 1.3G in size!

Hopefully this helps anyone who encounters a similar issue with these semi-hidden Syndication.photoslibrary files, which appear to grow because Apple had originally setup incremental vaccuum mode, and likely had not been running the PRAGMA incremental_vacuum command and ensuring "reader gaps" periodically enough so WAL checkpointing can truncate the file.

I'm not 100% sure, but it seems that based on all these daemons reading the SQLite database file (some periodically, and photolibraryd persistently), Apple has created a situation that the SQLite docs call "Checkpoint Starvation":

  • Checkpoint starvation. A checkpoint is only able to run to completion, and reset the WAL file, if there are no other database connections using the WAL file. If another connection has a read transaction open, then the checkpoint cannot reset the WAL file because doing so might delete content out from under the reader. The checkpoint will do as much work as it can without upsetting the reader, but it cannot run to completion. The checkpoint will start up again where it left off after the next write transaction. This repeats until some checkpoint is able to complete.
    However, if a database has many concurrent overlapping readers and there is always at least one active reader, then no checkpoints will be able to complete and hence the WAL file will grow without bound.
    This scenario can be avoided by ensuring that there are "reader gaps": times when no processes are reading from the database and that checkpoints are attempted during those times. In applications with many concurrent readers, one might also consider running manual checkpoints with the SQLITE_CHECKPOINT_RESTART or SQLITE_CHECKPOINT_TRUNCATE option which will ensure that the checkpoint runs to completion before returning. The disadvantage of using SQLITE_CHECKPOINT_RESTART and SQLITE_CHECKPOINT_TRUNCATE is that readers might block while the checkpoint is running.
Click to expand...

After dealing with all this, the reader can decide whether it's worth re-enabling these launchctl daemons... EDIT: See note 1

[1]: Evidently, people have been trying to disable these daemons without much success. Here are some of those attempted methods:

 
Last edited:
  • Like
Reactions: gilby101
jcuzella said:
After dealing with all this, the reader can decide whether it's worth re-enabling these launchctl daemons... EDIT: See note 1

[1]: Evidently, people have been trying to disable these daemons without much success. Here are some of those attempted methods:

Click to expand...
That is false, see https://forums.macrumors.com/thread...ysisd-and-photolibraryd.2445597/post-33630693
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back