[[6.7.x] Very slow array concurrent performance]

1 hour ago, Marshalleq said:

Fantastic.  How ever you squeezed that information out of him I'm grateful.  Personally, I didn't think it would be that hard to just post that here.  Either way it's hard to be annoyed at a guy who's profile only brings memories of island holidays and Hawaiian shirts lol.

Agree but this issue has made me review Unraid as the central server that runs most of the houses needs. 

 

This is a pretty big issue, if a copy happens while streaming video the movie just stops. Media streaming and the associated media harvesting and organising dockers is my main reason for unraid. 

 

To not have a single acknowledgement, other than now through a 3rd party, that they are aware of the issue and addressing it is poor form. It's a big issue, it needed those affected to be put at some ease. 

 

I've been around since the 4.x days so I'm acutely aware of what 'released soon' means. I hope we see something normal people 'soon' so I can fend off the wife and kids. 

[Dockers wanting to update, but don't in the end?]

8 hours ago, bluemonster said:

It appears that the docker images --digests --no-trunc command is showing, for whatever reason, the digest of the manifest list rather than the manifest itself for containers pushed as part of a manifest list (https://docs.docker.com/engine/reference/commandline/manifest/#create-and-push-a-manifest-list). I'm not sure if that's always been the case, or is the result of some recent change on the Docker hub API. Also not sure if it's intentional or a bug.

......

I made the change suggested above and my containers are now updating as expected.  Thanks

[Dockers wanting to update, but don't in the end?]

Yeah, not just LSIO, though it would look that way because they have so many that people use.

 

Pihole is another that doesn't update on mine.  The rest are ok.

[[6.7.x] Very slow array concurrent performance]

Thanks guys, it's reassuring to know it's being looked at.

[[6.7.x] Very slow array concurrent performance]

So no news or indication this is being looked at by LT yet.  Does anyone know if it's being looked at or addressed in 6.8?

 

This really is a show stopper.  My server's #1 purpose for most of the family is to stream media.  If that streaming gets interrupted because radarr or medusa has found a new file we wanted then that's isn't good

[[6.7.x] Very slow array concurrent performance]

22 minutes ago, bonienl said:

Nowhere did I ignore or dismiss the issue reported by johnnie.black.

I reacted to the statement that Unraid is ALWAYS slow, which I disagree and hence my example.

 

Pretty sure LT is aware and looking for solutions, please see this statement.

All good.  I wasn't accusing you of ignoring, just wanted to make sure the core issue  is understood.

Yeah, I read that and understand the philosophy, but I wonder if just a simple "Thanks, we've seen the issue, we'll come back when we have something or need more info" would help qwell the fears.  Or even a thread label like "Investigating" or ""Accepted", then they can stay away from posting.

 

Anyway, that's all for another thread.

[[6.7.x] Very slow array concurrent performance]

5 hours ago, bonienl said:

I guess hardware plays a role too.

I have pretty fast drives and with reconstruct write on, I do get satisfying results.

Below a 12GB file copied from my PC (nvme disk) directly to the array over a 10G connection.

It starts of at 1 GBps (10 Gbps) until the RAM caching is full and continues writing at around 140 MBps (1.12 Gbps)

Just to highlight, because you're staff/limetech/closely associated, what you mention aboove ISN'T what this thread is about, its a side discussion.

 

The issue here is that under 6.7, if I am streaming a movie and on another PC initiate a large file copy, the whole system comes to a grinding halt.  Video stops, copy slows, it's unworkable.

 

From my tests when I reach the 2.5 - 3Gb mark of a copy/transfer, the freeze kicks in.

 

It would be handy if LT could acknowledge the thread and issue.

[[6.7.x] Very slow array concurrent performance]

15 minutes ago, Dataone said:

 

Perhaps related?

Possible. I posted a link to this thread in there. 

[[6.7.x] Very slow array concurrent performance]

5 minutes ago, zinderr said:

I asked in the thread below if there is anything specific that needs to happen.  It looks like all you have to do is download the zip, stop the array, copy over the bz* files to /boot and then reboot.

 

 

The only other thing would be to check if you have any specific 6.7 plugins that won't work in 6.6

[[6.7.x] Very slow array concurrent performance]

On 8/21/2019 at 4:33 AM, Marshalleq said:

OK thanks for clarifying. Can you advise what was slow though, other file copying, the GUI etc?

Everything bar the copy. The video I was playing on the HTPB stalled, doing a unraid directory listing on my pc was very slow with the top bar slowly filling. The copy that I triggered via Krusader seemed to be slowed as well. 

 

I really wish the Lime boys would at least acknowledge they are aware of this issue. 

[[6.7.x] Very slow array concurrent performance]

OK, ran some tests.

 

Copied a 1Gb file from cache to array and no video stalling.

Copied a 4.3Gb file and when it got to about 2.8Gb the video stalled.  Then everything was slow for about 35-40secs before it all came good again.

 

So the latest RC doesn't help with this problem.

[[6.7.x] Very slow array concurrent performance]

19 hours ago, Marshalleq said:

Let me know if the beta helps - it'd be great to disprove that theory....

Installed the RC this morning.  Should be able to give a report tonight as to whether it helps..

[[6.7.x] Very slow array concurrent performance]

24 minutes ago, Marshalleq said:

WAF?  I can't see how anyone could ever see a bug that kills services on a server as minor though.

WAF - The most important variable when building a home server used predominantly for media streaming

 

Wife Acceptance Factor

[[6.7.x] Very slow array concurrent performance]

Glad I found this as I thought I was going crazy.  I have the same symptoms where a video stream will hang/freeeze if there is a background write happening on the array.  At first I thought it was a lag spinning up a disk for the write so I have one spin-up group that spins up all disks when even one is up.

 

That didn't solve the problem.  I was about to spend the next weekend with fingers under the hood moving disks from the onboard sata to the LSI2008 SAS-2 card to see if I could find a sweet spot where the errors disappeared.

 

If there have been some changes to address this in the latest Beta/RC, I'll happily try it out and see if it works.  I see it's flagged as minor.  Technically it is, but if you had in WAF to the equation then it's a showstopper.