Synlogy Diskstation 416play Performance Fixed

avatar
(Edited)

The Month of Problems

For over a month I had problem with my Synlogy Diskstation 416play. After a few hours of usage the Diskstation became sluggish, unresponsive and eventually froze up. If I noticed in time I could quickly reboot the system via ssh. The web interface usually didn't work at that point any more. However if I didn't notice early enough then all that was left was pressing the power button for 8 seconds to reboot the system.

Not a good solution as that leads to a RAID parity check.

If you look at the CPU, memory and I/O statistics of the last month you can see the down times quite clearly:

Physical Memory in %

Swap Memory in I/O operations

CPU usage in %

Volume I/O in %

Whenever the values show zero the system was basically frozen. I call it frozen as the system wasn't responding. However, the hard-drives where still in full use. But whatever the system was doing it wasn't anything useful as not even the statistical data was saved any more.

Switching off Services

In order to keep the system running I switched off all non essential services and one by one started them again. In the end the system was halfway stable without index service, Moments, Synlogy Drive Server, Synlogy Office, Hyper Backup and SMB / AFP connection.

But with that many essential services, including the SMB / AFP connection, deactivated the system wasn't very helpful any more. I had to find a proper fix.

Adding more Memory

Throughout the month I was looking for a solution, Tried difference combination services to activate. Doubling vm.min_free_kbytes as that was mentioned as a fix. But nothing helped. Until i finally found a community posting mentioning installing more memory. Increasing memory from 1GB to 8GB to be precise. The Memory used by the 416play is not that expensive, warranty has expired, so I ordered a KINGSTON 8 GB DDR3L-SDRAM SO-DIMM 204-Pin.

With the aid of one of the many guide on the internet I replaced the memory in less than an hour. Taking the case apart is the most difficult.

Synlogy knows precisely what part is in desperate need of an upgrade.

And the result: Everything is working again and better than it ever did before. All services started again, including Moments and indexing, which had been the biggest trouble maker in the past, and everything is working smoothly.

A Closer Look at the Current Statistic

With this success I took a closer look at the memory usage of the currently running system:

Physical Memory in usage

Swapper in I/O and usage

The swapper is, as expected after adding eight time the memory, empty so only main memory is of interest. The yellow part is the memory actually used by the apps. With that 2.5GB this is 2½ times the total memory originally installed.

I have worked with swapper ever since they where invented in the 1980th. And ever since then they have been a constant pain.

When introduced in the 1980th swapper where advertised as a great way to expand expensive main memory to become virtually limitless by use of cheap hard drive memory.

But that is not true. In my 30 years of experience I have learned that the swapper can at best double your memory. Once more data is stored in the swapper then main memory system performance degrades significantly. And once the swapper exceeds twice the main memory (⅓ of data is stored in main memory and ⅔ in the swapper) death by swapping will follow soon — that is the system becomes unusable.

That Synlogy added 6GB of swapper to a computer with only 1GB main memory is pointless. The system died by swapping long before the 6GB filled up.

From this one might be tempted to think that 4GB is enough and one could save some money when extending their system. That has some merit but I like to direct you to the 5.1 GB memory marked in dark green. That's the hard drive cache. The Diskstation is a NAS and providing data from the hard drive is its main job. With a such a huge hard drive cache data is provided that much faster.

Current status

Let's look at the table from before but instead of last month only from today:

Physical Memory in %

Swap Memory in I/O operations

CPU usage in %

Volume I/O in %

You can see that the system has frozen over night and was rebooted shortly before 7 o'Clock. You can also see that the system was shut down at about 15 o'Clock to install the new memory.

Main memory usage dropped 65% (of 1GB) to 30% (of 8GB). The system never used all the system memory for applications. Even before some was used as hard drive cache. Which means that from the 2.5GB of application memory needed only ¼ was keep in main memory.

Swap I/O dropped to zero as those 6GB of swapper is not unused any more. Which is perfect. For best performance the swapper should only be used in exceptional circumstance. Mind you, I tried using systems with lots of main memory and swapper deactivated but that turned out to be not a good idea. It's OK to have those 6GB do nothing.

CPU usage increased which is also no surprise. With only 1GB even the relatively weak Celeron N3060 was waiting for memory to be swapped in and out most of the time.

Which brings us to volume I/O which changed from 100% choke block to a more healthy 50%. That all look very promising.

I do suspect now that it was indeed the vm.min_free_kbytes filling up. This memory is used to provide emergency memory to interrupt handler and will indeed freeze the system if there is nothing left. Doubling vm.min_free_kbytes form 64MB to 128 MB (⅛ of 1GB) did not help and doubling yet again wasn't really an option on a system with only 1GB of memory.

Conclusion

Right now the memory increase was an absolute success. It seems that 8GB is the perfect amount of memory to have you Diskstation run absolutely smoothly. But 4GB will probably work as well.

Of course I have to see how it goes for another week to be absolutely sure my problems are gone. Updates in the comment. Knock on wood.


comment votes posts level payout commented voted



0
0
0.000
14 comments
avatar

I hated my Synology 1512+, it was great but crazy slow for everything I tried to use it for but file sharing. Mostly due to the really weak CPU.

I ended up building my own NAS and detailed it over 12 posts. Was a fun project.

I featured your post on STEMGeeks.

0
0
0.000
avatar

Until yesterday my CPU was under utilized waiting for memory pages being swapped in and out.

But yes: Synlogy is needlessly under powered.

Posted using Partiko Android

0
0
0.000
avatar
(Edited)

Update 1: When Hyper Backup started memory consumption increased to 2.7GB. That explains why Hyper Backup was on the naughty list.

0
0
0.000
avatar

Hi, @krischik!

You just got a 8.9% upvote from SteemPlus!
To get higher upvotes, earn more SteemPlus Points (SPP). On your Steemit wallet, check your SPP balance and click on "How to earn SPP?" to find out all the ways to earn.
If you're not using SteemPlus yet, please check our last posts in here to see the many ways in which SteemPlus can improve your Steem experience on Steemit and Busy.

0
0
0.000
avatar
(Edited)

Update 2: After one day the system has moved 1.2 GB of memory into the swapper:

image.png

This is suspicious. Memory usage is still at 2.5GB and the swapper should still be empty. I can think of two explanation:

  1. Unused parts of programs like initialisation routines which are used once and then never again. That's not a problem. The unused memory stays in the swapper till next reboot and causes not further harm.
  2. A memory leak: one of the programs doesn't free unused memory. Leaking 1.2GB of memory in 24h, would be a serious problem. A reboot every few days to free memory would be needed.

I'll have to keep a close look at this.

0
0
0.000
avatar
(Edited)

Update 3: Moments was the first service is stopped to stabilise my system. I already did so about 6 month ago. At the time it was only a hunch but now that the system is working normally i can take some proper measurements:

image.png

The display is ordered by memory usage and as you can see Moments right at the top with the highest memory usage and 2nd highest CPU usage.

Moments is using ¼ of the CPU and on a 1GB system ¼ of the system memory. It's clearly not feasible to use Moments on a 1GB system. However with 8GB of memory Moments runs like a charm.

The other thing to notice the Universal Search / System Database combo. A combo because the Universal Search index is stored inside the System Database.

Now that the system is stable I restarted the index and Universal Search has the highest CPU usage and the System Database the 2nd highest memory usage.

Just like Moments the Universal Search / System Database combo would be using ¼ of CPU and system memory on a 1GB system. I would say that using Universal Search is unfeasible on a 1GB system but it's not possible to stop or deinstall Universal Search. All you can do is defer indexing indefinably.

Conclusion: Even with Moments and Universal Search eating up ½ the available CPU the system is running smoothly. I'm looking forward on how fast the system will be when Moments and Universal Search finished there background tasks. Which will probably take a few days.

0
0
0.000
avatar

Update 4: Moments finally finished whatever it was doing and CPU and memory usage is back to normal:

image.png

0
0
0.000
avatar

!giphy-tip 500

0
0
0.000
avatar

@krischik you have received 500 GIPHY from giphy!
Trade the tokens on Steem Engine or send them to @giphy with post in memo for an upvote!

// This tip bot is powered by witness untersatz! //

0
0
0.000