Higher usage in Services slice.
This is like 5 GB higher than what I normally see.
Inactive memory ballooning up after upgrade:
I run several jails, and my āServicesā never exceeds much beyond 9 GiB.
Are you running VMs? (I am not.)
I also have 32 GiB of RAM, like your system.
Not VMās, just jails. Iām running the same ones now as I was before the upgrade, but I have updated a few after the TrueNAS upgrade to bring them up to 13.3 as well.
It could be due to an application(s) in one or more of your jails.
htop can clue you in, and lets you sort by MEM%.
Ah, good idea. And I think I can see the cause now on the chart, too.
Jellyfin was on 10.8.13 before, as 10.9 branch would not run on TN 13.0, and the climbing on the chart really starts at 15:13 on the 15th, not early in the morning, when the TrueNAS upgrade happened.
A quarter of your RAM being used by Jellyfin? Is your library that large?
Even with 10.9, and now upgraded to Core 13.3, mine stays around 1.2 GiB.
Itās the same files Plex is running with actually.
Edit: I shut down that jail.
I guess Iāll revisit this issue once the official port catches up to the upstream release.
I suggest rebooting to flush the cache.
This is kind of in a messed up state right now. I primarily use TrueNAS as storage and then to run jails for my media server. I donāt think Scale is ready yet for me, and at least 1 of my jails is broken in Core 13.0. I am reluctant to upgrade to 13.3 as I am seeing a lot of problems with jails and developers not wanting to build/maintain for 13.x.
I think the only real solution for me is to wait until Scale seems solid enough for me (see Upgrading from TrueNAS Core to Scale - #4 by dan) to upgrade. 
I and many others updated without issues. The package things should be resolved by now.
If you donāt feel confident in SCALE, 13.3 will give your CORE system extra time.
4 Likes
Honestly jellyfin has been the most troublesome app for me. Iāve had Plex in a 13.3 jail for a few months now, and it didnāt have any problem with the older TrueNAS kernel during that time. I mostly have jellyfin to keep an eye on development, and so I could jump over if something went south with Plex, Inc. Itās not the real prod media server here.
If folks suddenly stopped supporting things on BSD at all Iād change to a VM for now as a stopgap until Electric Eel.
1 Like
If you want to continue running and updating jails 13.3 is the only way forward. 13.0 is based on FreeBSD 13.1 - this is long EOL and jail provisioning and installing/updating packages is simply not available anymore.
Which developers do you see being reluctant here? The FreeBSD package repositories are all built for 13.3, currently.
iX? 
They do not maintain the FreeBSD packages. To use these in a jail you need to run CORE 13.3.
1 Like
You donāt run your own poudriere for TrueNAS builds?
Poudriere is used as part of our build process for CORE and has been for a long while nowā¦
I spent 10+ years babysitting poudriere and earlier tools to do builds of the entire ports tree into packages for PC-BSD/TrueOS back in the day. Know all too well how easily broken the ports tree is, and the general lack of testing that goes into updates pushed out to the ports repo. I canāt count the number of times port maintainers would push something which compiles, but never bothered to run-time test. Some binary or library bump that seems obvious (it works on upstream linux), but on BSD had some unique quirk that would make it segfault or fail in some other catastrophic manner. Spent a lot of time trying to debug BSD specific issues that upstream Linux maintainers just couldnāt be bothered to troubleshoot, since it wasnāt their default development platform.
But I digress, it is something Iām a bit passionate about having spent so many hours of my life chasing down those issues to make something not BSD-native run on BSD decently 
5 Likes
Coincidence: I started thinking about this yesterday and Iāve all but determined that itās the laziness of developers and/or the useless formula(s) weāve been told to follow. Dependencies are messing up everything. I mean, think about it; one of the reasons why containers were invented to was to solve dependency issues.
As an example, the other day I wanted to create a small utility for BSD and I need to parse a few config files, so I grabbed a ālist.hā from an older project instead of actually using āsys/queue.hā. But therein lies the rub, āqueue.hā will also cause portability issuesā¦ Fortunately, this utility will/can never be used on a linux OS, or even another BSD besides Freeāor anyone but me to be honestābut the point is that developers are stuck between a rock and hard place.
Weāre doing it wrong.
1 Like
What dost thou suggest?
If I could answer that (yet), I certainly wouldnāt tell this group. Iād be rich!
@pmh Lidarr was not built for 13.x until the other day due to an issue in ffmpeg in the 13.x branch/repo. It looks fixed now, but I am just confused about where I should go or if I should just not update anything for a while and wait until I am ready to move to scaleā¦