Mailinglist Archive: opensuse-bugs (5344 mails)
| < Previous | Next > |
[Bug 281147] We should increase fs.inotify.max_user_watches to 65536 in /etc/sysctl.conf
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Wed, 6 Jun 2007 09:37:46 -0600 (MDT)
- Message-id: <20070606153746.88C72CC782@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=281147
joeshaw@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpr@xxxxxxxxxx
------- Comment #2 from joeshaw@xxxxxxxxxx 2007-06-06 09:37 MST -------
(In reply to comment #1)
> IMHO this is a BUG in Beagle. Why Beagle does this?
It gets notification of file changes so that they can be indexed in real time.
It's no different from file managers like Nautilus or Konqueror listening for
changes on the directories its viewing.
> This slows down the system e.g. think about a multi users system and more
> then 100 co-workers on such a system. I do not like this kind of workarounds,
> please fix the application its self.
You're conflating two different problems here. Simply setting up watches
doesn't have any real effect on the system performance. It's how the
application uses it. I'm happy to have a conversation on how to improve
Beagle's performance and behavior, but it's a totally orthogonal discussion.
In the specific case of Beagle, with all else being equal, it would make the
system a lot *slower* if Beagle had to continuously recrawl the user's home
directory to watch for changes. Without complete file notification, this is
the only alternative. Inotify was written specifically for this use case.
This problem will eventually come up for any application which needs to watch
changes across a large number of directories, it's not a workaround and it's
not Beagle-specific.
> The question is: why Beagle requires such a large amount of watch points for
> monitoring file system events?
It requires one watch per directory. How many directories you have is entirely
dependent upon how big your home directory is set up, and developers with huge
source trees often hit this limit. You can roughly count the number of
directories to be indexed with this command:
find . -type d | grep -v "^\.\/\." | wc -l
(You may also want to grep out CVS and any dot-directories like .svn)
On my desktop machine, it's 47720 and that's a 104 gigabyte home directory. So
it's a pretty reasonable upper limit, IMO.
As to the 100-user use case you mention, in the unlikely case that there are
that many users with huge home directories such that kernel memory does become
scarce, then the system administrator can edit /etc/sysctl.conf and reduce it.
That's why it's a sysctl and not a hardcoded value in the kernel. But using
that use case to justify not doing it is weak because it's the vast minority of
our users. It may make sense for SLES, and if we could only change it there
(and not also in SLED) then perhaps we should.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
joeshaw@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jpr@xxxxxxxxxx
------- Comment #2 from joeshaw@xxxxxxxxxx 2007-06-06 09:37 MST -------
(In reply to comment #1)
> IMHO this is a BUG in Beagle. Why Beagle does this?
It gets notification of file changes so that they can be indexed in real time.
It's no different from file managers like Nautilus or Konqueror listening for
changes on the directories its viewing.
> This slows down the system e.g. think about a multi users system and more
> then 100 co-workers on such a system. I do not like this kind of workarounds,
> please fix the application its self.
You're conflating two different problems here. Simply setting up watches
doesn't have any real effect on the system performance. It's how the
application uses it. I'm happy to have a conversation on how to improve
Beagle's performance and behavior, but it's a totally orthogonal discussion.
In the specific case of Beagle, with all else being equal, it would make the
system a lot *slower* if Beagle had to continuously recrawl the user's home
directory to watch for changes. Without complete file notification, this is
the only alternative. Inotify was written specifically for this use case.
This problem will eventually come up for any application which needs to watch
changes across a large number of directories, it's not a workaround and it's
not Beagle-specific.
> The question is: why Beagle requires such a large amount of watch points for
> monitoring file system events?
It requires one watch per directory. How many directories you have is entirely
dependent upon how big your home directory is set up, and developers with huge
source trees often hit this limit. You can roughly count the number of
directories to be indexed with this command:
find . -type d | grep -v "^\.\/\." | wc -l
(You may also want to grep out CVS and any dot-directories like .svn)
On my desktop machine, it's 47720 and that's a 104 gigabyte home directory. So
it's a pretty reasonable upper limit, IMO.
As to the 100-user use case you mention, in the unlikely case that there are
that many users with huge home directories such that kernel memory does become
scarce, then the system administrator can edit /etc/sysctl.conf and reduce it.
That's why it's a sysctl and not a hardcoded value in the kernel. But using
that use case to justify not doing it is weak because it's the vast minority of
our users. It may make sense for SLES, and if we could only change it there
(and not also in SLED) then perhaps we should.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
| < Previous | Next > |