Number of Processes continuesly rising

[BuddyButterfly]

Hi,

after the migration to freenas I monitor a continuously rising number of processes (this is how it is
called in the reporting chart). In reality this are zfs threads. I discovered the following threads which
make up the biggest portion of the total number:

These are the numbers when I last checked. The image is more current but will have the same portions, I guess.

Code:

[zfskern/zvol pool]  : 720
[kernel/zio_free_iss] : 96
[kernel/zil_clean]    : 64

Out of a total of 1186.

The current situation can be seen in the following chart:

I guess this has to do with zfs keeping one thread per snapshot and that it will reach a maximum if
the snapshots will be destroyed and start to be nearly constant. Is it like this or is there maybe a thread leak?

Thanks a lot.

 

[dlavigne]

I asked our kernel/filesystem guru and he said:

I think user's guess is correct. ZFS creates thread for each ZVOL and apparently each snapshot too. So technically that is not a leak, though
not very good. But in 9.2.1.6 we switched ZVOL to the new "dev" mode, skipping GEOM, and all those threads should disappear.

 

[BuddyButterfly]

I asked our kernel/filesystem guru and he said:

I think user's guess is correct. ZFS creates thread for each ZVOL and apparently each snapshot too. So technically that is not a leak, though
not very good. But in 9.2.1.6 we switched ZVOL to the new "dev" mode, skipping GEOM, and all those threads should disappear.

Nice to hear that this is fixed in 9.2.1.6. When will this release be available for upgade?
What does "new "dev"" mode mean? Will it also solve the issue that name length of devices is limited to 63 characters?
With this limitation, one can not place volumes in arbitrary dataset nodes as the path will easily break this limit and result in the problem I
have described here:

http://forums.freenas.org/index.php...ol-pool-auto-20131006-010000s1-error-6.21675/

 

[Ericloewe]

Nice to hear that this is fixed in 9.2.1.6. When will this release be available for upgade?
What does "new "dev"" mode mean? Will it also solve the issue that name length of devices is limited to 63 characters?
With this limitation, one can not place volumes in arbitrary dataset nodes as the path will easily break this limit and result in the problem I
have described here:

http://forums.freenas.org/index.php...ol-pool-auto-20131006-010000s1-error-6.21675/

9.2.1.6 RELEASE should be available within 10 days or so.

 

[DrKK]

I asked our kernel/filesystem guru and he said:

I think user's guess is correct. ZFS creates thread for each ZVOL and apparently each snapshot too. So technically that is not a leak, though
not very good. But in 9.2.1.6 we switched ZVOL to the new "dev" mode, skipping GEOM, and all those threads should disappear.

Dru, can you tell us more about the "dev" mode? Or point us to a resource?

 

[dlavigne]

That's the term he used, and I think he is referring to the fact that the changes are in TrueOS (meaning that any changes sent upstream to FreeBSD are in HEAD, the development branch of FreeBSD).

The fixes he did addressed the GEOM limitations that were the reason this note is in the Guide:

In theory, a zvol and a file extent should have identical performance. In practice, a file extent outperforms in reads/writes but this is only noticeable at 10 GB Ethernet speeds or higher. For high performance, file extents are recommended at this time. Future changes to FreeBSD's zvol code will increase its performance.

There were quite a few commits that did this. Most of the amotin changes on this page were part of it: https://github.com/trueos/trueos/commits/feature/unified_freebsd?page=3.

 

[dlavigne]

I'm not sure about the 63 character thing. If you are still hitting that barrier in 9.2.1.6, please create a ticket and post the issue number. I don't see where a ticket was ever made, at least not from the referred to forum post.

 

[BuddyButterfly]

I'm not sure about the 63 character thing. If you are still hitting that barrier in 9.2.1.6, please create a ticket and post the issue number. I don't see where a ticket was ever made, at least not from the referred to forum post.

eraser found the solution in the mentioned thread:

Not sure if I am looking at the correct list of error numbers, but according to the sys/errno.h file for FreeBSD, error 63 is ENAMETOOLONG - "File name too long".

 

[BuddyButterfly]

That's the term he used, and I think he is referring to the fact that the changes are in TrueOS (meaning that any changes sent upstream to FreeBSD are in HEAD, the development branch of FreeBSD).

The fixes he did addressed the GEOM limitations that were the reason this note is in the Guide:

In theory, a zvol and a file extent should have identical performance. In practice, a file extent outperforms in reads/writes but this is only noticeable at 10 GB Ethernet speeds or higher. For high performance, file extents are recommended at this time. Future changes to FreeBSD's zvol code will increase its performance.

There were quite a few commits that did this. Most of the amotin changes on this page were part of it: https://github.com/trueos/trueos/commits/feature/unified_freebsd?page=3.

Best explanation can be found here: https://www.mail-archive.com/svn-src-all@freebsd.org/msg82617.html

 

[BuddyButterfly]

Please set this topic to "solved" (as well as the other topic related to this...). Can't do this myself :-(