I think I may have an idea about dragging performance (high cpu / disk io) attributed to these services, without having to disable them. (I still need to test this for a while to confirm my findings.)
While wdphotodbmergerd and sometimes apache2 look like they are drawing hard on resources, right now the main culprit appears to be wdmcserverd so I will focus on that here.
A dramatic effect I have found is by one change to the init.d service script for the wdmcserverd service. This was done for a Gen1 MyCloud, but could very well apply elsewhere.
-Connect to the device via SSH and navigate to /etc/init.d.
-Open the “wdmcserverd” file for editing and look/search for one line that reads like “export WDMC_CHILD_MEMSW_LIMIT=314572800”. This line appears to allow the wdmcserver process alone to try and expand to use over 300MB of ram on a unit with only 256MB total!
-Change this line (or comment out and type a new line) so it reads with a smaller number like “export WDMC_CHILD_MEMSW_LIMIT=83886080”.
-Save and close the file, then restart the service by issuing the command “service wdmcserverd restart” or by rebooting your device.
Within a few minutes, you may notice that your Mycloud has calmed down, responsiveness has increased, and that the wdmcserver and wdphotodbmerger processes are both running but not acting up.
@rac8006 well, I meant that you have to check into SQ5 modification of the “wdmcserverd” file of the two lines on the gen2 to see if that would reduce the havoc of wdmcserverd service on the gen2 as well and if it does, whether you can make this permanent on gen2.
Since I’m no longer active on debugging the WD but I see that you have bought a gen2 device or kept the last one that you bought, it is up to you to keep up the fight.
I didn’t buy a gen2 on purpose. The 6tb disk in one of my gen1 systems started going bad. It was cheaper to
buy a 6TB mycloud than buy the bare drive. But the new 6tb mycloud was a gen2. I planned to take the disk out and put it in the gen1. Then I decided rather than throw out the gen2 board why not get a small disk and get the gen2 also working. I couldn’t unbrick the gen2 using a differentt disk. So I ended up leaving the 6tb disk in the gen2 and using the unbrick procedures on the gen1 board and disk. So now I have a gen1 and gen2 6tb system and a 2T gen1 system.
I’ve learned over the last couple of weeks. That the gen2 is also a 64k pagesize linux. Also to get a program to work on the gen2 it needs to be statically linked. A statically linked program will run on both a gen1 and a gen2 system.
I will look into the change in a few hours when I go home. (owns a Gen2.)
Some of the things that go into /etc are stored on a persistent partition on the Gen2. It might be possible to leverage this to make persistent changes of this type. (This is, eg, how the SSH keys can be upgraded by an end user, which I did some time ago, because the default keys were weaksauce garbage, and my ssh client refused to connect with them. Had to connect using connectbot using an android phone, generate new keys, push them to the right place on the NAS, and reboot it with fingers crossed. Worked though.)
I will see if this can be made trivially permanent later.
Ok. /etc/init.d is hosted by the initial ramdisk. That means you will have to either overwrite the file every boot (slow copy operation), or delete it and create a symlink somewhere else (suggest HD_a7, which gets mounted at /usr/local/config. It is the stateful config partition, and not used for shares.) which would be a fast FS operation. Depending on when rac8006’s boot script fires (before or after the scripts in init.d fire), you may need to stop and restart the service after doing the needful.
However, the modification may not be necessary. The Gen2 has 512mb of ram, not 256. It too defaults to using up to 300ish mb for this daemon. Unless something else decides to be a memory hog, the system should not experience excessive thrashing under load, but your mileage may vary.
If you read what was posted above you will see that it is possible to run a script when the system reboots.
This is what manufacturing does. It is easy to set up and no 'changes to the gen2 are necessary for this to work.
Yes. I read that. However, WHEN in the init process does the script fire? Kernel init? (what level)-- User init? (what level).
Some items in init.d will fire at different times in the boot process. That is why I said, "Depending on when [your] boot script [solution] fires, you may need to down the service and restart it again with the boot script.
If you look at system_init in /usr/local/modules/script. You will see that near the end it will
run your script. Just make your change and restart the service.
So far so good overnight. No functionality side effects noticed yet.
Meanwhile a substantial reduction in load. The unit has been mostly idle with a load average between 4 and 5 (remembering that ~4.00 load avg effectively means no load on the Gen1).
The wdmcserver process woke up a couple times, taking load average only to about 7-8 (versus up in the teens and unresponsive before). Load average had dropped down again each time I checked back within less than an hour so it completed somewhere in that range rather than hours/days.
I will be rebooting the unit shortly to see how it continues to perform then.
I’m a little more optimistic now that this could be a silver bullet, though the unit I’m observing has had a bunch of other tweaks added along the way to get it under control. I’ve rolled back some of those tweaks in case it was instead a combination of changes with this being the last piece. I’d be curious to hear when someone has tried on a stock device (or close to stock) to isolate the impact of this tweak by itself.
Do Gen2 users ever experience a performance issue with this daemon too? I can see how the Gen2 likely doesn’t suffer as much as the Gen1 because of its additional ram.
When I looked at it with top, it was only using something like 30mb of ram. I dont have a lot of media shared on it though, and dont use the WD software ecosystem. As such, the circumstances that lead to this service allocating lots of memory may not surface in my use case. Just pointing out that it should not attempt to allocate greater than 100% of the system’s ram, and thus be basically guaranteed to start thrashing the $%^* out of swap when under load.
That is why I said your mileage may vary-- Setting this tweak may be useful, especially if using fox_exe’s installable application bundles, some of which would likely be ram hogs. (like Plex server, or Transmission.)
The first thing I notice on the gen2 device is the responsiveness despite the fact that the scans were running and I thought they may have fixed the scans in the gen2. I should have known that they (WD) probably did not and it was just the difference of a memory upgrade.
That means you will have to either overwrite the file every boot (slow copy operation), or delete it and create a symlink somewhere else (suggest HD_a7, which gets mounted at /usr/local/config. It is the stateful config partition, and not used for shares.) which would be a fast FS operation. Depending on when rac8006’s boot script fires (before or after the scripts in init.d fire), you may need to stop and restart the service after doing the needful.