-
Posts
3,707 -
Joined
-
Last visited
-
Days Won
6
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Report Comments posted by Vr2Io
-
-
7 hours ago, trott said:
I have to manually setup queue_depth in CLI for each disk like below
Good for know depth still 1
-
35 minutes ago, Marshalleq said:
PCI Express 2.0 supports 500MB/s.
It is 1x lane speed, so 8x will be 4GB/s, so each disk have ~500MB/s used bandwidth for 8 disks.
-
51 minutes ago, Marshalleq said:
I'd be interested in knowing what your configuration is. my drives are mainly on a Dell PERC310 in IT mode
Not special, 16 disks, most are WD shuck disk, mix 5400 and 7200 rpm. All connect thr a SAS blackplane to LSI 9207-8i IT in pcie3.0 x8, but confirm no different if connect to 9211 IT (pcie 2.0). Direct pcie from CPU. Change with different platform aslo same speed, no much different on with or without parity.
Yes, must be reconstruct write mode.
-
8 hours ago, Marshalleq said:
53MB/s - yes it's slow, it's always been slow, even with Seagate enterprise capacity disks - seems to be an overhead of the unraid parity.
It should another issue cause this.
-
8 hours ago, Marshalleq said:
Right, so initial testing with the release candidate 6.7.3-rc2. To test I played a plex video, preloaded many gigabytes of files to a cached share. Invoked the mover manually, added an additional copy of another large set of files from a disk to the cache and with all this going simultaneously I don't seem to have any issues. The wa (io wait) in top only get's up to 8.0 instead of 20.0 under the previous kernel. (Gotta edit that as I think I wrote 0.20 which was incorrect, it was 20. Also my write speed (from HDD to SSD) is about normal at 53MB/s - yes it's slow, it's always been slow, even with Seagate enterprise capacity disks - seems to be an overhead of the unraid parity.
This is my first and only test so far (I'll try tomorrow when someone is watching plex on the Apple TV in the lounge where the issue was visible today) I'd be interested if anyone else can test though, by upgrading to 'next' - there are very very few changes in it so it should be quite safe.
If the problem goes away for you I'd say very lucky we are. Otherwise we shall need to investigate further. Fingers crossed!
The problem should only happen if one writing session simultaneous with another read/write session in disk array, it shouldn't happen in cache pool or UD for my test.
If problem haven't trigger, then disk array read write speed should be expected from 190MB/s to 90MB/s for spinnder disk in disk array, no matter have parity or not.
-
This not Unraid fault, clone disk have same UUID.
-
8 hours ago, opentoe said:
I've kept it on RECONSTRUCT.
Yes, set it in disk setting rather in go file.
Your setting "Tunable (nr_requests):" was set to 8 only. Default was 128, I simple set all tunables by 10x.
If you want got smooth transfer curve, pls try disable "Tunable (enable Direct IO):" at "Global Share Settings page".
Some comment on your test result
- You have 32GB RAM, so data usuallly cache a lot and queuing write to array. When you stop file transfer, it still in queuing and will affect the observe result, you need waiting for while.
- You have many disk, so you also need confirm System-HBA-Disk have enough bandwidth, and the test on other Windows machine haven't much meaning, because those access was single disk, not reconstruct write with all disk.
-
2 hours ago, ken-ji said:
Have you tried following this in the NFS rules?
Thanks, but I just report the rule won't copy if apply 'write setting to' .
-
Changed Status to Solved
-
15 minutes ago, johnnie.black said:
I was also using btrfs, but I use tunable settings that are considerably higher than defaults, that would explain why I wasn't seeing the problem.
Yes, thanks again for your testing.
-
57 minutes ago, johnnie.black said:
Can't reproduce this on my test server with a 20GB file, can you gives us more detail on the hardware used, mainly board/CPU? Just in case I have something similar where I can try.
Note with thanks, I make some change of disk 1 (disk) and disk 4 (SSD) from BTRFS to XFS, then XFS disk problem gone. But BTRFS disk still slow.
Next, I try adjust all tunable stripes from DEFAULT by 10x ( also try 2X have improve ), and problem seems completely gone.
So, for all BTRFS disk system, should change all DEFAULT tunable stripes setting ?
How LT would handle, which haven't problem on 6.6.7 ?
-
Changed Status to Closed
-
Sure all disks have a single large 24GB file only and not dashboard display issue.
Below are the test make, 6.7rc then restore back to 6.6.7
time cat /mnt/disk1/D/1 > /dev/null ( Disk connect to LSI )
time cat /mnt/disk4/D/4 > /dev/null ( SSD connect to onboard SATA )
-
Changed Priority to Annoyance
-
Yes, issue only on 6.7-rc series, I have make bug-report for easy followup.
Pls have check, this issue have reproduce at 3 different PC platform.
-
31 minutes ago, limetech said:
Are you talking about having 3 or more devices being read in parallel? If so you can try increasing
Tunable (md_num_stripes)
on Settings/Disk Settings if your use case requires this.
Actually problem not only happen on parallel read, performance also low even only 1 disk access at a time.
In 6.7RC, I got slow problem on
- Rsync file between 2 Unraid
- Hash file by Checksum suit / FIP locally
- .....
-
Thanks for the update.
"Hopefully last release before 6.7.0 stable. "
Does LT ack low performance on some situation of disk operation ?
e.g.
cat /mnt/disk'x'/xxxx > /dev/null
I test by above, in 1 disk / 2 disk / 3 disk and got abnormal throughput, suffer this issue in whole 6.7RC but no problem on 6.6.7, thanks
-
11 hours ago, johnnie.black said:
One more data point, it doesn't happen to me with btrfs disks, only with xfs.
Seems a bigthrough, xfs related.
-
2 Unraid ( Intel / AMD ) update, both found array read performance drop, for example "cat <file> > /dev/null" ..... all disk relate operation slow down a lot, never got this before.
-
Note and thanks all.
3 hours ago, limetech said:At present 'emhttp' keeps track of spinning status based on "last I/O time"
That are different as I think Unraid will keep track the active/idle status of disk and determine need command out spindown or not again.
I understand and agree if keep track disk status may cause unnecessary spinup and create another problem. Different disk type/model/firmware also have different behavior.
-
Also upgrade to 6.6.0, have one time user/disk share unavailable, stop array faild too. No this problem in all 6.6 RC. Keep monitoring and parity need further check/sync.
-
XHCI should work but failed at device side, XHCI driver update issue in 6.6rc1 ?
[ 30.917042] usb usb6-port4: attempt power cycle
[ 32.189079] usb 6-1: new SuperSpeed USB device number 5 using xhci_hcd
[ 32.202160] usb-storage 6-1:1.0: USB Mass Storage device detected
[ 32.202696] scsi host3: usb-storage 6-1:1.0
[ 102.443495] usb 1-5: USB disconnect, device number 2
[ 109.781040] usb 1-5: new high-speed USB device number 5 using xhci_hcd
[ 110.008870] usb-storage 1-5:1.0: USB Mass Storage device detected
01:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset USB 3.1 xHCI Controller [1022:43ba] (rev 02)
Subsystem: ASMedia Technology Inc. Device [1b21:1142]
Kernel driver in use: xhci_hcd06:00.0 USB controller [0c03]: ASMedia Technology Inc. Device [1b21:2142]
Subsystem: ASUSTeK Computer Inc. Device [1043:8756]
Kernel driver in use: xhci_hcdYou have several XHCI controller in your system, if I am correct TR / Ryzen should have a USB come from CPU ( but MFG may not use it ). Does all have same problem ? Suggest try differnet USB port too.
-
Fine. But I just in remote not local. Try later. Thanks
-
Same issue, previous was black theme.
BTW, call trace found, relate above issue ?
Could I quick fix by command line first ?
[ 50.175109] Call Trace:
[ 50.175116] do_stop+0x45/0xab [md_mod]
[ 50.175121] stop_array.constprop.17+0x77/0x9c [md_mod]
[ 50.175125] md_proc_write+0x1223/0x163d [md_mod]
[ 50.175129] ? walk_component+0xc2/0x249
[ 50.175133] ? proc_reg_open+0xdf/0xf9
[ 50.175135] ? proc_i_callback+0x13/0x13
[ 50.175138] ? _cond_resched+0x1b/0x1e
[ 50.175141] ? dput+0x33/0xfc
[ 50.175144] ? path_put+0xd/0x16
[ 50.175146] ? path_openat+0xb2d/0xc07
[ 50.175149] ? current_time+0x11/0x54
[ 50.175151] ? do_filp_open+0x83/0xa9
[ 50.175153] proc_reg_write+0x41/0x5f
[ 50.175156] ? proc_reg_poll+0x54/0x54
[ 50.175159] __vfs_write+0x2e/0x12e
[ 50.175161] ? do_renameat2+0x114/0x423
[ 50.175164] vfs_write+0xc3/0x166
[ 50.175167] ksys_write+0x58/0xa6
[ 50.175171] do_syscall_64+0x57/0xe6
[ 50.175175] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 50.175177] RIP: 0033:0x14a7a6fc8e81
[6.7.x] Very slow array concurrent performance
in Stable Releases
Posted
If NVMe was PT, it won't help even set any command for it.