TS-419P smbd and flush-9:0 acting up

[schumaku]

I notices this problem on my TS-419p as well. I realized it started occuring after i enabled the anti virus option a while back. Disabling this option made the NAS a lot faster and more responsive again.

AV does not do anything in the effective data stream - however the active AV scan as scheduled it's very intensive on the processor and the disk I/O while active.

Very high activity of the flush-processes can point to a problem of physically writing to the RAID, respectively to one or multiple disks.

[OZs]

We found the issue,
- When used disk volume space is over 90% and the RAM space is less than 192 MB, the NAS write performance will drop to 6.96MB/s or less...

TS-639, 6x2 TB (no SMART problem), and more than 700 MB free RAM, but only 5-50 GB free HDD space, and the problem exists. So, RAM is not a factor, only the free HDD space. It is "funny", that I have 50 GB free space, but I have to write a 8 GB file with 0-10 MB/sec speed. And this problem is known for years, but no solution.

[KillerDAN]

I with a QNAP412 running 4x 2TB in RAID 5 and just got hit by this today with +800G free space.

Is this issue still present ? This is completely inadmissible.

[schumaku]

Already operating on QNAP OS v3.7.1?

[KillerDAN]

Already operating on QNAP OS v3.7.1?

No. I see no reason for it from reading the release notes.

Is it corrected in 3.7.1, or earlier ?

Or is this the standard CSR response? Please upgrade to the latest release, even if I do not wish any of the new features and memory eating "hogs".

[schumaku]

Or is this the standard CSR response?

Pretty rough for the first or second post here, isn't it? As the title says: This is a community forum. If all you want to do is bashing - don't waste our time.

[Major Bug Fixes]
...
- Fixed the slow write speed when the system would take a long time to find free blocks with large amount of data stored on the NAS
...

[KillerDAN]

Or is this the standard CSR response?

Pretty rough for the first or second post here, isn't it? As the title says: This is a community forum. If all you want to do is bashing - don't waste our time.

As is, we are all used to it and nothing is new, no bashing here but yours.
If you want to prove a point, don't do it by doing what your are criticizing.

[Major Bug Fixes]
...
- Fixed the slow write speed when the system would take a long time to find free blocks with large amount of data stored on the NAS
...

Hardly clear enough to upgrade just on that. Also no mention for CPU usage caused by flush process running.

Anyone else on this thread gone trough this upgrade ?

[schumaku]

Well, technicallly smbd is handing the obvious file acces protocol, and flush is handling the cache resp. writing data to the disk ... so there is a direct relation bwetween the CPU lod dof the two processes while writing to the physical storage in any case.

Yes, this "smbd vs. flush-x:x" is not explicitly mentioned, and also not word of the resulting the high CPU load - bust most likley, this should explain:

http://forum.qnap.com/viewtopic.php?f=1 ... 70#p271929

[Subject]
QNAP’s response to online community discussions regarding abnormal file system performance

[Symptom Observation]
When the volume is filled with large amount of data, the Turbo NAS might encounter sudden write performance drop. After removing some files to free out available free volume space, the performance could become normal again.

[Analysis]
In QNAP Turbo NAS firmware version from v3.2 to v3.6, it might take a long time to find the free blocks to write files when the large amount of files are stored in the Turbo NAS. Therefore, users could encounter slow write performance under this circumstance.

[Solution]
Users who encounter similar scenarios are strongly advised to upgrade to the Turbo NAS firmware 3.7.1 or a later versions. According to QNAP lab’s verifications, upgrading to the new firmware versions could solve the abnormal write performance.
In real life operations, other known facts could also cause slow performance, including bad blocks on the hard drives, very little free space left on the disk volume, or fragmented data.
If upgrading to the new firmware versions does not help, please send us an email at [performance at qnap dot com ] or contact QNAP Support. We will be pleased to assist you.
QNAP Support: http://www.qnap.com/en/index.php?lang=en&sn=4574

The symtoms can become visible on the ARM NAS models, just like on x86, too.

[KillerDAN]

Well, technicallly smbd is handing the obvious file acces protocol, and flush is handling the cache resp. writing data to the disk ... so there is a direct relation bwetween the CPU lod dof the two processes while writing to the physical storage in any case.

I actually, at the current time, have no need for smbd, as all processes are running withing the QNAP box itself, and every time flush runs, everything is taken to a grin level of decay...

In the meantime Customer Support answered my ticket with the short, blunt, not at all colorful explanation not even close for what you and other provided in this thread...

Please update your NAS F/W to 3.7.1 than test again.

While I wait for others previously on this thread to share some insight should they have upgraded to 3.7.1, I will disable all Microsoft Networking components for the time being.

[schumaku]

Any process writing to the disk can and will have issues in this situation - it's a Kernel issue that was addressed, wich cna lead to high CPU load when attempting to write to the storage volume.

... every time flush runs, everything is taken to a grin level of decay...

Exact observation of the issue addressed.

[KillerDAN]

After disabling Microsoft Networking things did not change much.
I was forced proceeding with the upgrade, rather than deleting files, or being left with a unusable system.

Upgraded to version: Version 3.7.1 build 20120615

Issue is solved !

I have since increased my disk usage and still with no performance impact noticeable:

Filesystem Size Used Available Use% Mounted on
/dev/ram0 32.9M 15.3M 17.6M 46% /
tmpfs 32.0M 120.0k 31.9M 0% /tmp
/dev/sda4 356.5M 283.9M 72.5M 80% /mnt/ext
/dev/md9 509.5M 115.2M 394.3M 23% /mnt/HDA_ROOT
/dev/md0 5.4T 5.0T 385.5G 93% /share/MD0_DATA
tmpfs 32.0M 0 32.0M 0% /.eaccelerator.tmp

Also in general everything seems more smooth and fluid.

[pwilson]

This issue just appeared for me today. Cant understand why.

There are no [flush-x:y] processes on TS-x09.

All ARM-based NAS users should avoid operating their QNAP NAS on v3.4.0...v3.4.2 and upgrade to v.3.4.3 instead using the manual firmware upgrade process from the Linux NAS as shown here: http://wiki.qnap.com/wiki/Manually_Updating_Firmware .

I dont have any TS-X09 models, only the TS-419P. However I will try a manual update to 3.4.3 from 3.4.2 to see if it makes any difference. flush-9:0 is there as im looking at it right now.

The current firmware for the TS-419P is v3.7.1. Why would you upgrade to 3.4.x, when 3.7.1 is the current firmware?

[dulcifium]

Did this ever get solved? It's not clear from my reading of the thread. I have this issue on 3.8.1 with about 80% disk usage on a RAID-6.

[KillerDAN]

Yes it did since version 3.7.1 on my post of Jul 16, 2012 2:41 pm.

Currently running 3.8.1 Build 20121205 also whiteout this issue.

[rumknapser]

No, it DID NOT.
I'm running 3.8.3 Build 20130426
Having about 20GB of 7TB free.
NAS is super slow :-(