Re: TRIM, iSCSI and %busy waves

2018-04-07 Thread Eugene M. Zheganin
Hi, 05.04.2018 20:15, Eugene M. Zheganin wrote: You can indeed tune things here are the relevant sysctls: sysctl -a | grep trim |grep -v kstat vfs.zfs.trim.max_interval: 1 vfs.zfs.trim.timeout: 30 vfs.zfs.trim.txg_delay: 32 vfs.zfs.trim.enabled: 1 vfs.zfs.vdev.trim_max_pending: 1

Re: TRIM, iSCSI and %busy waves

2018-04-06 Thread Warner Losh
On Fri, Apr 6, 2018 at 2:56 AM, Borja Marcos wrote: > > > On 6 Apr 2018, at 10:41, Steven Hartland wrote: > > That is very hw and use case dependent. > > The reason we originally sponsored the project to add TRIM to ZFS was that > in our case without

Re: TRIM, iSCSI and %busy waves

2018-04-06 Thread Warner Losh
On Fri, Apr 6, 2018 at 1:58 AM, Borja Marcos wrote: > > > On 5 Apr 2018, at 17:00, Warner Losh wrote: > > > > I'm working on trim shaping in -current right now. It's focused on NVMe, > > but since I'm doing the bulk of it in cam_iosched.c, it will eventually

Re: TRIM, iSCSI and %busy waves

2018-04-06 Thread Borja Marcos
> On 6 Apr 2018, at 10:56, Borja Marcos wrote: > > P.S: Attaching the graphs that were lost. And, silly me, repeating the same mistakes over and over. http://frobula.crabdance.com:8001/publicfiles/OneBonnie.png

Re: TRIM, iSCSI and %busy waves

2018-04-06 Thread Borja Marcos
> On 6 Apr 2018, at 10:41, Steven Hartland wrote: > > That is very hw and use case dependent. > > The reason we originally sponsored the project to add TRIM to ZFS was that in > our case without TRIM the performance got so bad that we had to secure erase > disks

Re: TRIM, iSCSI and %busy waves

2018-04-06 Thread Steven Hartland
That is very hw and use case dependent. The reason we originally sponsored the project to add TRIM to ZFS was that in our case without TRIM the performance got so bad that we had to secure erase disks every couple of weeks as they simply became so slow they where unusable. Now admittedly that

Re: TRIM, iSCSI and %busy waves

2018-04-06 Thread Borja Marcos
> On 5 Apr 2018, at 17:00, Warner Losh wrote: > > I'm working on trim shaping in -current right now. It's focused on NVMe, > but since I'm doing the bulk of it in cam_iosched.c, it will eventually be > available for ada and da. The notion is to measure how long the TRIMs take,

Re: TRIM, iSCSI and %busy waves

2018-04-05 Thread Eugene M. Zheganin
Hello, On 05.04.2018 20:00, Warner Losh wrote: I'm also having a couple of iSCSI issues that I'm dealing through bounty with, so may be this is related somehow. Or may be not. Due to some issues in iSCSI stack my system sometimes reboots, and then these "waves" are stopped for

Re: TRIM, iSCSI and %busy waves

2018-04-05 Thread Eugene M. Zheganin
Hello, On 05.04.2018 19:57, Steven Hartland wrote: You can indeed tune things here are the relevant sysctls: sysctl -a | grep trim |grep -v kstat vfs.zfs.trim.max_interval: 1 vfs.zfs.trim.timeout: 30 vfs.zfs.trim.txg_delay: 32 vfs.zfs.trim.enabled: 1 vfs.zfs.vdev.trim_max_pending: 1

Re: TRIM, iSCSI and %busy waves

2018-04-05 Thread Warner Losh
On Thu, Apr 5, 2018 at 8:08 AM, Eugene M. Zheganin wrote: > Hi, > > I have a production iSCSI system (on zfs of course) with 15 ssd disks and > it's often suffering from TRIMs. > > Well, I know what TRIM is for, and I know it's a good thing, but sometimes > (actually often) I'm

Re: TRIM, iSCSI and %busy waves

2018-04-05 Thread Steven Hartland
You can indeed tune things here are the relevant sysctls: sysctl -a | grep trim |grep -v kstat vfs.zfs.trim.max_interval: 1 vfs.zfs.trim.timeout: 30 vfs.zfs.trim.txg_delay: 32 vfs.zfs.trim.enabled: 1 vfs.zfs.vdev.trim_max_pending: 1 vfs.zfs.vdev.trim_max_active: 64