But it’s compounded by having to deal with version control. Obviously disabling a process by moving it and killing it is not the right way. But it’s not the right way to achieve it. Take a look at the result in the screenshot below: Actually, I had to move that program asside and then kill it – to prevent it from auto restarting. I SSH’d into the NAS, located the process ID for “fileindexd” and killed it. So the next thing to do is disable indexing. You can see the indexing status is still “Indexing”. I only disabled the version control, not the index process. In fact, the re-indexing process continues to use high disk IO. I revisited the resource manager to validate my change. To demonstrate my theory, I have disabled version control as you can see here: The data is changing throughout the day, versions are being added and removed (entering and leaving the retention limits) and that’s causing indexing to continue for ever. Here’s where I theories that the issue is a combination of enabling version control at the same time as enabling indexing on the same data. In other words, 1 version retention versus 32 version retention doesn’t seem to make a different. It didn’t seem to make any different to the high resource utilization. This defaulted to 32 (the maximum) but as a test, I downgraded it to just 3. You can see the version control is enabled. Let’s take a look at the version control settings: So we need to consider there is more than one thing contributing to the high disk IO. But the indexing seems to go on forever (at least, a long time). If indexing was the only issue, we would expect that, if the contents of the disk have been successfully index, then only minor indexing would be needed moving forward. Like I said in the intro to this article, the disks aren’t particularly good which would absolutely be contributing to this high utilization phenomenon.
It’s showing the “disk” and “volume” utilization is extremely high. But why is it running? As the name would suggest, it’s indexing our files to improve search speeds and generally make findings files (by anything or anyone searching for them) faster – more efficient. You can see the resource hog is the “Universal Search” process and the “fileindexd” child process. Coupling that with the Synology insistence on high disk IO for (what would seem like) normal NAS-type work makes for a bad combination. The disks are 3.5 inch mechanical disks that honestly aren’t that great to begin with.
In this example, we’re using the Synology DS720plus model. This article explains the primary reason for high disk utilization on the Synology NAS.
0 kommentar(er)
