From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] tools/xenconsoled: Increase file descriptor limit Date: Tue, 17 Feb 2015 09:07:00 +0000 Message-ID: <54E304B4.5080303@citrix.com> References: <1424110674-32223-1-git-send-email-andrew.cooper3@citrix.com> <54E256A8.9040909@terremark.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54E256A8.9040909@terremark.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Don Slutz , Xen-devel Cc: Wei Liu , Ian Jackson , Ian Campbell List-Id: xen-devel@lists.xenproject.org On 16/02/2015 20:44, Don Slutz wrote: > On 02/16/15 13:17, Andrew Cooper wrote: >> XenServer's VM density testing uncovered a regression when moving from >> sysvinit to systemd where the file descriptor limit dropped from 4096 to >> 1024. (XenServer had previously inserted a ulimit statement into its >> initscripts.) >> >> One solution is to use LimitNOFILE=4096 in xenconsoled.service to match the >> lost ulimit, but that is only a stopgap solution. >> >> As Xenconsoled genuinely needs a large number of file descriptors if a large >> number of domains are running, and is well behaved with its descriptors, >> attempt to up the limit to the system maximum. >> >> Signed-off-by: Andrew Cooper >> CC: Ian Campbell >> CC: Ian Jackson >> CC: Wei Liu >> --- >> tools/console/daemon/main.c | 31 +++++++++++++++++++++++++++++++ >> 1 file changed, 31 insertions(+) >> >> diff --git a/tools/console/daemon/main.c b/tools/console/daemon/main.c >> index 92d2fc4..759c061 100644 >> --- a/tools/console/daemon/main.c >> +++ b/tools/console/daemon/main.c >> @@ -26,6 +26,7 @@ >> #include >> #include >> #include >> +#include >> >> #include "xenctrl.h" >> >> @@ -55,6 +56,34 @@ static void version(char *name) >> printf("Xen Console Daemon 3.0\n"); >> } >> >> +/* >> + * Xenconsoled requires one file descriptor for each PV console, which can >> + * easily exceed the default of 1024 if many guests are running. Try to set >> + * the fd limit to the system maximum, falling back to a default of 4096. >> + */ >> +static void increase_fd_limit(void) >> +{ >> + FILE *fs_nr_open; >> + struct rlimit lim; >> + long nr_open = 4096; >> + int rc; >> + >> + rc = getrlimit(RLIMIT_NOFILE, &lim); >> + if (rc) >> + return; >> + >> + fs_nr_open = fopen("/proc/sys/fs/nr_open", "r"); >> + if (fs_nr_open) { >> + fscanf(fs_nr_open, "%ld", &nr_open); >> + fclose(fs_nr_open); >> + } >> + >> + if ((nr_open > lim.rlim_cur) || (nr_open > lim.rlim_max)) { >> + lim.rlim_cur = lim.rlim_max = nr_open; >> + setrlimit(RLIMIT_NOFILE, &lim); >> + } >> +} >> + > I am not sure that Xenconsoled is required to have the CAP_SYS_RESOURCE > capability. With out this, the "soft" (rlim_cur) will most like not be > changed. Does it make sense to include: > > lim.rlim_cur = lim.rlim_max; > rc = setrlimit(RLIMIT_NOFILE, &lim); > if (rc) > return; > > before "fs_nr_open = fopen(..."? It probably does make sense, although xenconsoled cannot realistically run without privilege because of privcmd and /dev/ptmx. I shall respin. ~Andrew