4.0.3 has huge memory and CPU footprint in High Sierra

General discussions about Little Snitch
durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Mon Jun 18, 2018 1:47 am

As far as I can tell, there must be a problem with your graphics driver. This may not be directly related to your memory issue, but it's impacting responsiveness and performance of your computer.


:shock: :(

When you look at the file LittleSnitchDaemon.log from your diagnostics report, you'll notice that there are days and times where no hangs occur. Is your computer off during these times? Or can you find a pattern, maybe a kind of work you do, a program you run or something else which may cause this behavior?


This got long, but I don't know enough to know what of it is irrelevant, so I'm dumping it all on you anyway! :D

Some observations from the log timestamps:

1) The vast majority of the events are either exactly 15 seconds apart, or exactly 2:05 apart:

Code: Select all

0:00:15   52882
0:02:05   16683


2) There's a daily cycle, where I see fewer errors between 7pm and 4am local time:

Code: Select all

hour of day   COUNT of hour of day
0   1508
1   1756
2   2089
3   2386
4   3162
5   3643
6   3721
7   3714
8   3719
9   3715
10   3715
11   3706
12   3661
13   3402
14   3199
15   3081
16   3096
17   3182
18   3239
19   2998
20   2269
21   1914
22   1418
23   1353

Image
This is a home machine that stays on ~all the time, but sees little use during the day on workdays, so if anything this means there are fewer errors when it's in active use. Maybe something strange is happening when it sleeps?

3) There's a weekly cycle:

Code: Select all

day of week   COUNT of day of week
1   5815
2   15553
3   9456
4   8354
5   13004
6   8757
7   8707

The errors are significantly more common on Mondays and Thursdays, and significantly less common on Sundays. I don't really know what to make of this, aside from a weak possible correlation between "more use" and "fewer errors"

4) Weekly cycle, bucketed hourly:

Code: Select all

time of week   COUNT of time of week
0.00   24
0.04   23
0.08   42
0.13   76
0.17   264
0.21   339
0.25   349
0.29   350
0.33   351
0.38   349
0.42   351
0.46   349
0.50   306
0.54   415
0.58   354
0.63   260
0.67   266
0.71   265
0.75   285
0.79   272
0.83   266
0.88   163
0.92   28
0.96   68
1.00   314
1.04   321
1.08   426
1.13   585
1.17   785
1.21   819
1.25   821
1.29   819
1.33   819
1.38   822
1.42   816
1.46   816
1.50   811
1.54   822
1.58   847
1.63   850
1.67   848
1.71   850
1.75   848
1.79   622
1.83   350
1.88   322
1.92   134
1.96   86
2.00   64
2.04   217
2.08   321
2.13   363
2.17   378
2.21   568
2.25   615
2.29   615
2.33   612
2.38   614
2.42   615
2.46   620
2.50   627
2.54   406
2.58   379
2.63   354
2.67   322
2.71   300
2.75   287
2.79   276
2.83   173
2.88   254
2.92   240
2.96   236
3.00   246
3.04   301
3.08   323
3.13   322
3.17   323
3.21   322
3.25   322
3.29   322
3.33   323
3.38   322
3.42   322
3.46   323
3.50   313
3.54   320
3.58   301
3.63   322
3.67   323
3.71   323
3.75   517
3.79   554
3.83   528
3.88   434
3.92   325
3.96   323
4.00   301
4.04   324
4.08   363
4.13   380
4.17   558
4.21   629
4.25   644
4.29   643
4.33   645
4.38   643
4.42   643
4.46   631
4.50   636
4.54   645
4.58   660
4.63   672
4.67   680
4.71   661
4.75   633
4.79   615
4.83   513
4.88   340
4.92   291
4.96   254
5.00   246
5.04   265
5.08   287
5.13   295
5.17   346
5.21   352
5.25   353
5.29   350
5.33   351
5.38   352
5.42   352
5.46   351
5.50   352
5.54   350
5.58   353
5.63   352
5.67   351
5.71   485
5.75   598
5.79   601
5.83   382
5.88   343
5.92   343
5.96   347
6.00   313
6.04   305
6.08   327
6.13   365
6.17   508
6.21   614
6.25   617
6.29   615
6.33   618
6.38   613
6.42   616
6.46   616
6.50   616
6.54   444
6.58   305
6.63   271
6.67   306
6.71   298
6.75   71
6.79   58
6.83   57
6.88   58
6.92   57
6.96   39

Image
The troughs on Saturday/Sunday/Monday nights are striking; my best theory is still that these are hours of peak likelihood of use.

5) As you observed, there are some significant gaps where no errors occur:

Code: Select all

timestamp   gap (days)
2017-12-31 21:33:47   31
2018-01-31 18:57:15   9
2018-02-09 20:09:08   16
2018-02-26 22:11:54   10
2018-03-08 16:21:14   13
2018-03-21 19:24:04   25
2018-04-17 13:06:52   1
2018-04-19 20:39:02   2
2018-04-21 13:21:27   2
2018-04-24 22:26:07   6
2018-05-01 20:07:21   1
2018-05-03 22:41:04   2
2018-05-12 14:51:15   3
2018-05-15 15:20:22   2
2018-05-19 13:02:35   2
2018-05-27 12:03:09   2
2018-05-29 21:36:14   1
2018-06-04 20:12:15   3
2018-06-14 21:40:47   3

This machine is almost always on, but it does spend a fraction of its lifetime in Bootcamp, which would be effectively "off" as far as Little Snitch is concerned.

So, here's a list of my user login sessions on OS X going back to the start of the year, filtered to "console" only, which I believe are the local user login sessions, not terminal (remote or local) sessions:

Code: Select all

durandal   console   Sun   Jun   17   13:51   still   logged   in
durandal   console   Thu   Jun   7   11:24   -   13:48   (10+02:23)
durandal   console   Mon   May   28   22:46   -   11:14   (9+12:27)
durandal   console   Mon   May   28   20:58   -   21:01   (00:03)
durandal   console   Sat   May   5   13:03   -   20:46   (23+07:43)
durandal   console   Mon   Apr   30   13:53   -   12:58   (4+23:04)
durandal   console   Tue   Apr   24   23:11   -   23:19   (00:08)
durandal   console   Sat   Apr   21   00:11   -   22:47   (3+22:36)
durandal   console   Sun   Apr   15   04:11   -   00:10   (5+19:59)
durandal   console   Wed   Apr   11   13:51   -   04:01   (3+14:10)
durandal   console   Thu   Mar   29   17:57   -   16:40   (10+22:43)
durandal   console   Wed   Mar   21   12:06   -   19:57   (07:51)
durandal   console   Fri   Mar   16   14:59   -   20:27   (1+05:28)
durandal   console   Sat   Mar   10   15:00   -   16:09   (01:08)
durandal   console   Sun   Mar   4   23:59   -   12:18   (4+12:18)
durandal   console   Fri   Mar   2   19:46   -   23:24   (03:37)
durandal   console   Sun   Feb   25   23:48   -   14:32   (4+14:43)
durandal   console   Fri   Feb   23   18:32   -   23:45   (2+05:12)
durandal   console   Tue   Feb   20   02:00   -   21:19   (2+19:19)
durandal   console   Mon   Feb   19   20:30   -   01:54   (05:23)
durandal   console   Sun   Feb   18   16:09   -   17:18   (01:08)
durandal   console   Sat   Feb   17   00:30   -   15:50   (15:20)
durandal   console   Wed   Feb   14   18:12   -   21:37   (2+03:25)
durandal   console   Mon   Feb   12   17:03   -   20:05   (1+03:02)
durandal   console   Sat   Feb   10   03:45   -   15:38   (2+11:53)
durandal   console   Fri   Feb   9   20:25   -   22:35   (02:10)
durandal   console   Fri   Feb   9   01:10   -   crash   (19:11)
durandal   console   Thu   Feb   8   23:12   -   00:33   (01:20)
durandal   console   Sun   Jan   21   13:13   -   20:41   (18+07:27)
durandal   console   Sun   Dec   31   13:09   -   crash   (21+00:04)

Assuming this is trustworthy in the face of bootcamp interactions, here's the "missing time" not accounted for by an active login session:

Code: Select all

login timestamp   duration   logout timestamp   missing time   missing days
2018-06-17 13:51            
2018-06-07 11:24   242:23   2018-06-17 13:47   0:04   
2018-05-28 22:46   228:27   2018-06-07 11:13   0:11   
2018-05-28 20:58   0:03   2018-05-28 21:01   1:45   
2018-05-05 13:03   559:43   2018-05-28 20:46   0:12   
2018-04-30 13:53   119:04   2018-05-05 12:57   0:06   
2018-04-24 23:11   0:08   2018-04-24 23:19   134:34   5
2018-04-21 00:11   94:36   2018-04-24 22:47   0:24   
2018-04-15 04:11   139:59   2018-04-21 00:10   0:01   
2018-04-11 13:51   86:10   2018-04-15 04:01   0:10   
2018-03-29 17:57   262:43   2018-04-09 16:40   45:11   1
2018-03-21 12:06   7:51   2018-03-21 19:57   190:00   7
2018-03-16 14:59   29:28   2018-03-17 20:27   87:39   3
2018-03-10 15:00   1:08   2018-03-10 16:08   142:51   5
2018-03-04 23:59   108:18   2018-03-09 12:17   26:43   1
2018-03-02 19:46   3:37   2018-03-02 23:23   48:36   2
2018-02-25 23:48   110:43   2018-03-02 14:31   5:15   
2018-02-23 18:32   53:12   2018-02-25 23:44   0:04   
2018-02-20 02:00   67:19   2018-02-22 21:19   21:13   
2018-02-19 20:30   5:23   2018-02-20 01:53   0:07   
2018-02-18 16:09   1:08   2018-02-18 17:17   27:13   1
2018-02-17 00:30   15:20   2018-02-17 15:50   24:19   1
2018-02-14 18:12   51:25   2018-02-16 21:37   2:53   
2018-02-12 17:03   27:02   2018-02-13 20:05   22:07   
2018-02-10 03:45   59:53   2018-02-12 15:38   1:25   
2018-02-09 20:25   2:10   2018-02-09 22:35   5:10   
2018-02-09 01:10   19:11   2018-02-09 20:21   0:04   
2018-02-08 23:12   1:20   2018-02-09 00:32   0:38   
2018-01-21 13:13   439:27   2018-02-08 20:40   2:32   
2017-12-31 13:09   504:04   2018-01-21 13:13   0:00   

The gaps <15m are probably rebooting for updates. Longer than that is probably time spent in Bootcamp, but there might be some cases of not immediately logging in after an OS update mixed in.

Either way, the "missing time" is not enough to account for the multi-week-long gaps between error events. :(

6) Every error in the log is associated with one of two LS versions: 3.8.2 or 4.06. Here's the pair of lines where it flips over:

Code: Select all

2018-04-24 22:26:07.193 Little Snitch Daemon[90:842] 3.8.2 (4740): m26b16e2b: 8796 5 0
2018-04-30 13:59:57.752 Little Snitch Daemon[90:836] 4.0.6 (5124): m26b16e2b: 488 5 0

This corresponds to the 6-day gap in the earlier "significant gaps" table, and also a 5-day period of "missing time".
(I don't know when between these dates the update actually happened. I've got reboots on both the 24th (a little after the first log line) and 30th (a little before the second log line). Maybe it's somewhere else in the diagnostics report?)

The long gaps between errors stopped a ~month before the earliest the 4.0.6 update could have taken place, so I'm not particularly worried that this got *worse* with that update.

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Fri Jun 22, 2018 5:10 am

Here's more vmmap output, this time for LSNM v4.1.0: https://pastebin.com/Jh7VXyA1

... and the corresponding Console output:

Code: Select all

2018-06-21 20:05:38.069 Little Snitch Network Monitor[435:4754] #### object allocation statistics: ####
2018-06-21 20:05:38.069 Little Snitch Network Monitor[435:4754]             LSMDataModel:        1 208 bytes each
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754]         LSMConnectionSet:        9 88 bytes each
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754]     LSMSummaryConnection:     6100 240 bytes each
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754]        LSMTrafficHistory:      364 1976 bytes each
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754]          LSMProcessGroup:      202
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754] ----- Connections in Live Set: -----
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754]      Logical Connections:     3833
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754] Peer Summary Connections:     1787
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754]  Dom Summary Connections:      267
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754]  App Summary Connections:       66
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754] ----- Other: -----
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754]    LSMPhysicalConnection:   117928 (0 null, 0 inactive)
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754] LSMTrafficHistory (live):      364
2018-06-21 20:05:38.070 Little Snitch Network Monitor[435:4754]         2.00 MB bytes for objects
2018-06-21 20:05:38.071 Little Snitch Network Monitor[435:4754]         1.29 MB in 5357 32-bit sections
2018-06-21 20:05:38.071 Little Snitch Network Monitor[435:4754]         0 B in 0 64-bit sections
2018-06-21 20:05:38.071 Little Snitch Network Monitor[435:4754] #### end statistics ####

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by christian » Fri Jun 22, 2018 9:50 am

Thanks again! This time the relation to CoreAnimation is not so pronounced:

Code: Select all

CoreAnimation          00000001147a9000-00000001147de000 [  212K   212K   212K     0K] rw-/rwx SM=SHM PURGE=V  
VM_ALLOCATE            00000001147ec000-0000000175824000 [  1.5G     0K     0K   1.5G] rw-/rwx SM=PRV         
MALLOC_LARGE           0000000175824000-0000000175ac9000 [ 2708K  2708K  2708K     0K] rw-/rwx SM=PRV          MallocHelperZone_0x104f44000
VM_ALLOCATE            0000000175ac9000-000000019a67f000 [587.7M  23.1M  23.1M 564.6M] rw-/rwx SM=PRV         
MALLOC_LARGE           000000019a67f000-000000019a6ff000 [  512K   512K   512K     0K] rw-/rwx SM=COW          MallocHelperZone_0x104f44000
MALLOC_LARGE           000000019a6ff000-000000019a77f000 [  512K    72K    72K     0K] rw-/rwx SM=PRV          MallocHelperZone_0x104f44000
MALLOC_LARGE (empty)   000000019a77f000-000000019a87f000 [ 1024K   568K   568K     0K] rw-/rwx SM=PRV         
CoreAnimation          000000019a8a3000-000000019a8ac000 [   36K    36K    36K     0K] rw-/rwx SM=SHM PURGE=N 

There are gaps between the CoreAnimation allocations and the large blocks.

The large blocks are still tightly packed, so we can assume that they have been allocated as a consequence of the same cause. 1.5 GB correspond roughly to a backing store of 10,000 lines of Network Monitor list. Do you keep the list expanded for an extended period of time?

If we could reproduce the issue here, we could run a debug version of Network Monitor in Instruments and see a stack backtrace of the point where the blocks are allocated...

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Sun Jun 24, 2018 11:44 am

Same instance as before, now grown to 3.6GB: https://pastebin.com/c8S5aMPc

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Mon Jun 25, 2018 5:30 am

Do you keep the list expanded for an extended period of time?


I don't go out of my way to close it, but I also don't open it very often. I know this isn't a very helpful answer. :(

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by christian » Mon Jun 25, 2018 12:01 pm

We need to get more information about where the large blocks are allocated and what they contain. We can't use the debugger, though, due to security settings. But as far as I can tell, the `heap` tool should work. So please try the following: Open Activity Monitor to find the PID (Process ID) of Little Snitch Network Monitor. Then open a Terminal window and type:

Code: Select all

heap <pid-of-LSNM>


(replacing <pid-of-LSNM> with the actual PID, of course). This shows a different view on allocations, this time with information about the content of the blocks. It might not list the large blocks, though...

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Tue Jun 26, 2018 4:43 am

`heap` output for that same instance of LSNM, which doesn't seem to have significantly grown since last update: https://pastebin.com/vjfDafkm

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by christian » Tue Jun 26, 2018 9:48 am

Thanks for the `heap` output! Unfortunately it does not list the large sections, so it's not much help.

So let me summarize:
- Network Monitor sometimes swallows a large chunk of memory (several 100 MB).
- The memory is not freed (maybe it's freed some times, but we won't notice those chunks).
- The memory is probably allocated with vm_allocate().
- The blocks immediately before and after the large block are often owned by CoreAnimation or CoreGraphics.
- When your computer is in sleep mode or the screen locker is active, LS Agent hangs frequently.

We can now point our finger on the system frameworks and claim that it's probably a bug there, but that won't help you.

We can try various workarounds, but it's hard for us to test them. The development would be tedious because we would have to send every test version to you for testing.

And we can try to figure out what could be different on your machine with respect to most others. So: Do you have unusual graphics drivers or graphics hardware? An unusual screen locker, other kernel modules or similar?

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Wed Jun 27, 2018 9:10 am

And we can try to figure out what could be different on your machine with respect to most others. So: Do you have unusual graphics drivers or graphics hardware? An unusual screen locker, other kernel modules or similar?


graphics hardware: unmodified Mac Pro (Late 2013), with an "AMD FirePro D500 3072 MB" graphics card.

graphics drivers: whatever macOS 10.13.5 runs by default; I haven't gone out of my way to tinker with this.

screen locker: standard macOS screenlock; I'm using "minimal Screensaver" which just shows a black screen.

kernel modules:

Code: Select all

$ kextstat | grep -v com.apple
Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
   71    0 0xffffff7f80fda000 0x17e000   0x17e000   at.obdev.nke.LittleSnitch (5167) 9EEA1B6A-76B4-325A-BDFC-14183C43D5C4 <7 5 4 3 1>
   86    1 0xffffff7f80e42000 0x45000    0x45000    com.Logitech.Control Center.HID Driver (3.9.5) no UUID <85 83 53 47 5 4 3>
   88    0 0xffffff7f80e97000 0x17000    0x17000    com.Logitech.Unifying.HID Driver (1.3.5) no UUID <86 83 53 47 5 4 3>
  129    0 0xffffff7f83220000 0x5000     0x5000     com.driver.LogJoystick (2.0) B02191E1-23F0-3B9B-BD97-F6173C3C2BD4 <47 5 4 3>
  150    0 0xffffff7f85a92000 0x6000     0x6000     com.valvesoftware.SteamInput (3083.39.62) DED4413E-CD8E-3E56-B0AB-7B3B20ECE4BF <47 5 4 3>
  151    0 0xffffff7f85a98000 0x7000     0x7000     com.AmbrosiaSW.AudioSupport (4.1.4) no UUID <121 5 4 3 1>

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Sun Jul 01, 2018 4:46 am

vmmap again, same process, now grown to 7.5GB: https://pastebin.com/77qXrajR

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Mon Jul 02, 2018 9:00 am

vmmap again, same process, now grown to 9.25GB: https://pastebin.com/944yAkxL

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Tue Jul 03, 2018 11:16 pm

vmmap again, same process, now grown to 11.99GB: https://pastebin.com/tifXk67b

After that snapshot, I killed the process.

christian
Objective Development
Objective Development
Posts: 1443
Joined: Thu Nov 09, 2006 11:46 am

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by christian » Sun Jul 08, 2018 1:20 am

Thanks for all the info!

For the moment, I can't get any additional information out of this. What would be helpful is if you can find out which action causes a sudden increase of memory usage. Here's a shell script which checks memory usage every 10 seconds and brings a notification if it exceeds a limit:

Code: Select all

PID=775
while true; do
    vmmap -summary -pages $PID \
  | awk '/^TOTAL/{
        print $2;
        if ($2 > 700000) {
            system("osascript -e \"display notification \\\"Memory consumption just increased\\\" with title \\\"Network Monitor Memory\\\"\"");
        };
        exit
    }'
    sleep 10
done


Replace the PID with that of your Network Monitor and replace 700000 with a useful limit in pages of 4 kB each.

The script also prints the current usage in pages every 10 seconds. You can paste it as-is into a Terminal window.

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Mon Jul 09, 2018 8:06 pm

What would be helpful is if you can find out which action causes a sudden increase of memory usage.


It grew again, from ~80mb to ~800mb, after/during:
    computer sleep overnight
    external network connectivity outage

Observation: The following is a new symptom with 4.1, but maybe it's related: when my ISP drops my connection, LS often displays an outgoing connection request from Chrome to xxx.yyy.zzz.www (IP varies) to port 443 (https). What's fishy is that Chrome already has permission to connect to that port of any server; this request seems to me to be covered by existing rules. Furthermore, approving this request ("forever") *doesn't actually do anything*; no new rule is created, and I immediately get another (seemingly identical) connection request. Approving this also does nothing, etc. The only ways I've found to break this loop are quitting chrome, putting LSNM into "Silent Mode - Allow Connections", or waiting for my ISP to come back.

Speculation: The loop and failure to match an existing rule make me wonder: are there circumstances under which LSNM is doing something similar in a less focus-grabbing way, piling up a list of pending connections? Either while the computer is asleep or offline? Does LSNM do its own reverse-DNS lookups when passing judgment on connections? What happens if it can't connect to the outside world? Presumably there's a cache, but does that cache have a TTL? What happens if the computer's asleep for 10 hours (DNS cache flushed by then?) and then is offline when it wakes up (can't do new lookups?)?

Anyway, I'll try to keep watching what happens immediately before a memory growth.

durandal42
Rank 1
Rank 1
Posts: 25
Joined: Wed Aug 09, 2017 9:35 pm

Re: 4.0.3 has huge memory and CPU footprint in High Sierra

Post by durandal42 » Tue Jul 10, 2018 8:32 am

It grew again, from ~80mb to ~800mb, after/during:
    computer sleep overnight
    external network connectivity outage


It grew again, to 1.72GB, under similar circumstances (not overnight, but several hours asleep).

Post Reply