Hello,
Since the installation of 1.18.7.2415 on Docker in DSM 6.2.2.
I consume a lot of RAM, I am 85% used on 16 GB.
Am I the only one ?
I would like to know myself. I am also on a synology and this version seems to be getting a lot of good word on reddit regarding synology.
But the version I am on now, 1.18.5 something seems to have this ram issue too. Out of the blue it went to 70% of system ram (also 16gb). Restarting the plex server fixed it, and it hasn’t happened again, but I hope this not the norm on 1.18.7.2415 as this version I’m told finally fixed the intel Apollo lake quick sync issue.
Any thoughts from the devs on this ram issue?
Please tell me the conditions of your testing.
I am running 1.18.7.2415 on a DS-1815 w/ 8GB of RAM.
Native app (not containered)
RAM utilization 7%
I am on a synology ds1019+. 16gb ram. Native app, no container. After I restarted plex it went away and hasn’t happened again. Under normal circumstances ram utilization sits around 10% or so. This is on 1.18.5.2309. If it happens again I’ll send the logs.
Guy from the first post, Evotk, is it still happening for you, can you send the log?
I plan to go to 1.18.7 at some point because of all the good synology comments I have read about that version, and hope that ram bug too will be fixed there as well. Or soon after. Thanks.
Thank you for your answers.
The problem was not with Plex. Docker was giving false information. The ram consumption was due to another container.
The htop command in ssh revealed the truth to me.
As a point of order,
This is why I don’t use containers when native apps are available. Too many things can go wrong.
I see. That’s good to know. In my case it was for sure plex that went nuts and consumed 70% of the ram. I could tell in the resource monitor. But it hasn’t happened again since the restart, on version 1.18.5.2309. I’m hoping this won’t be a regular thing in 1.18.7.2415. Doesn’t sound like it is. Thanks for your help all.
I have built a full up library on an 8GB DS-1815+ and it still only uses 7% of RAM.
In the end after a long search, I confirm that it is Plex! All versions after 1.18.6.2368 have this problem of leaking memory on a Docker installation under DSM 6.2.2-5
A “friend” has the same concerns as me.
I am going to draw the line here. I cannot support XPEnology. I am not equipped to do so.
Is the DLNA server active? it is a known memory leak source.
Thank you for the answer.
DNLA is not active with me.
Idem in 1.18.7.2457
I strongly recommend avoiding the Docker layer on Synology.
There is zero net gain.
- Moving the Plex server is highly unlikely
- Start/Stop control is just as easily performed with Package Center
- Configuration of additional share locations does not require the additional step of adding the map point into the container.
- Mapping of the transcoding hardware is performed automatically by the native app at installation time. Docker does not provide this.
- Complexity and “swoopiness” just because one can is nobody’s friend.
Taken to extreme:
Should I run PMS in a Docker container on a Windows Hyper-V VM which is hosting Ubuntu Linux? No. There is so much complexity in the translation layers and easily measured loss of performance that its only purpose is at the academic level “Yes, it can be done but nobody would do such a thing in real application”.
1 Like
Docker on Synology is very reliable and Plex is far more practical this way:
- you can rollback to whichever version you want with ease, Package can’t.
- Easy backup of your Library.
- Fine ressources tuning.
- Easy to move to another computer if needed.
But all these considerations have nothing to do with the actual matter, the culprit is iHD_drv_video.so driver. Once deleted, everything is working fine again. Perhaps the Transcoder change from 1.18.6 to 1.18.7 regarding Apollo Lake cpus is not fine with our rigs, same with actual 1.18.8.2468 so I suppose we’ll have to keep deleting this driver or stop updating Plex. A simple option to be able to chose between old Vaapi and new driver would be nice.
1 Like
Incorrect / inaccurate statement:
-
To roll back the package:
a. Stop PMS
b. Uninstall the package from Package Center
c. Install the desired package in Package Center
d. NO CHANGES / TUNING REQUIRED. -
Per the PMS release notes, add
VaapiDriver="i965"toPreferences.xml(which you can access via File Station and the Synology Text Editor -
Porting to another system:
a. Stop PMS
b. Make a ZIP file
c. Copy the ZIP
d. UNZIP it
Note: I have yet to be able to move Docker between any of the distro combinations of: Synology, QNAP, Fedora, or Debian.
2 Likes
Thank you very much for pointing me to this more elegant solution, I didn’t see it in the actual PMS release notes, is it a recent one?
I’m a long time user of Plex, firstly in its native synology package, since DSM 5 if I remember well, but at that time I experienced some library losses while downgrading and this is why I switched to docker. I still think it’s more flexible and easy to backup/upgrade/downgrade/tinker with config files because of its direct access in File Station, and since that switch, this 1.18.7 upgrade is the first one causing troubles to my setup. So, long live to PMS and the variety of choices it offers to set it up 
Hi,
VaapiDriver=“i965” setting disappears from Preferences.xml after PMS update, is there a way to make it persistent?
EDIT: it happened on my rig but not on a friend’s one, so I suppose it might be a local bug.
the VaapiDriver=i965 is new this release. It doesn’t surprise me of the need to reapply it as crossing versions.
Huge memory leak leading to OOM kills on my side with PMS 1.18.9.2578 (edit: bare metal deployment, no docker).
Adding the VaapiDriver=i965 workaround solved the issue. Thanks !
I have spoken too soon: memory leaks are back…
Have you checked that the parameter VaapiDriver=i965 has not disappeared from Preferences.xml?
