#48386 RFE dsktune improvements and tuning
Closed: wontfix 6 years ago Opened 8 years ago by firstyear.

As DS has evolved, systems have changed, and dsktune should advise on new settings.

dsktune should:

  • Describe and check partition sizing
  • Check filesystem permissions before the setup tool is run (optional)
  • Advise on journald settings and sizing.

  • Anything else that we feel should be considered.

Dsktune if we give it some attention, could become a diagnostic tool to quickly identify mistuned or misconfigured services, and well help prevent the installation of misconfigured systems.


More issues on dsktune:

On 12/16/2015 04:19 PM, Marcelo Giles wrote:
{{{

dsktune

389 Directory Server system tuning analysis version 23-FEBRUARY-2012.

NOTICE : System is x86_64-unknown-linux3.10.0-229.el7.x86_64 (1 processor).

NOTICE : The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.

WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.

WARNING : The warning messages above should be reviewed before proceeding.
}}}
The first message:
NOTICE : The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds

Can be solved by:
echo "net.ipv4.tcp_keepalive_time = 300" > /etc/sysctl.d/tcp-keepalive-time.conf
systemctl restart systemd-sysctl

The second message:
WARNING: There are only 1024 file descriptors

I've tried:
/etc/sysconfig/dirsrv.systemd
[Service]

uncomment this line to raise the file descriptor limit

LimitNOFILE=8192

But no change.

Then I tried the usual:
/etc/security/limits.conf
* hard nofile 8192

Also no change.

And then there's the /proc/sys/fs/file-max value, which we recommend to
increase to 64000.

cat /proc/sys/fs/file-max
47838

echo "fs.file-max=64000" > /etc/sysctl.d/file-max.conf
systemctl restart systemd-sysctl

Still dsktune complains with WARNING: There are only 1024 file
descriptors...

See also this doc:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Installation_Guide/Preparing_for_a_Directory_Server_Installation-Considerations.html#Platform_Support-File_Tuning

And dsktune calls the value in /etc/security/limits.conf and
/etc/sysconfig/dirsrv.systemd file descriptors.

On 12/16/2015 03:44 PM, Rich Megginson wrote:

/proc/sys/fs/file-max - http://www.faqs.org/docs/securing/chap6sec72.html

/etc/sysconfig/dirsrv.systemd is only for the ns-slapd process, and can only increase the file number limit up to but not over the system limit.

Which one change in either file should update and be read by dsktune?

dsktune should check the system limit. The admin should then make sure that the system limit is high enough, then change /etc/sysconfig/dirsrv.systemd to make sure ns-slapd has a high enough limit.

They are both described as file descriptors but seem to be very different. Which one of them RHDS cares about?

RHDS cares about both - the system limit affects how high the ns-slapd limit can be.

Here is my dsktune output:

{{{
DEBUG : Memory size 0
DEBUG : 0 MB swap configured
DEBUG : /sbin/sysctl -n net.ipv4.tcp_keepalive_time
DEBUG : net.ipv4.tcp_keepalive_time 600000 (600 seconds)
DEBUG : 65536 descriptors (hard limit) available.
DEBUG : 65536 descriptors (soft limit) available.
DEBUG : RLIMIT_DATA (2) max -1 prev -1.
DEBUG : RLIMIT_AS (9) max -1 prev -1.
DEBUG : 447MB available on /
DEBUG : RLIMIT_CORE is 0, 0
DEBUG : replacing with /
DEBUG : file system / matches /opt with options rw
DEBUG : fsmnt /sys != reqdir /opt
DEBUG : mntdir_matches want /opt < input /proc
DEBUG : fsmnt /dev != reqdir /opt
DEBUG : mntdir_matches want /opt < input /sys/kernel/security
DEBUG : mntdir_matches want /opt < input /dev/shm
DEBUG : mntdir_matches want /opt < input /dev/pts
DEBUG : fsmnt /run != reqdir /opt
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/systemd
DEBUG : mntdir_matches want /opt < input /sys/fs/pstore
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/memory
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/perf_event
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/devices
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/cpuset
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/cpu,cpuacct
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/net_cls
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/hugetlb
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/blkio
DEBUG : mntdir_matches want /opt < input /sys/fs/cgroup/freezer
DEBUG : mntdir_matches want /opt < input /sys/kernel/config
DEBUG : replacing / with /
DEBUG : file system / matches /opt with options rw,seclabel,relatime,attr2,inode64,noquota
DEBUG : fsmnt /usr != reqdir /opt
DEBUG : mntdir_matches want /opt < input /sys/fs/selinux
DEBUG : mntdir_matches want /opt < input /boot
DEBUG : mntdir_matches want /opt < input /proc/sys/fs/binfmt_misc
DEBUG : mntdir_matches want /opt < input /sys/kernel/debug
DEBUG : mntdir_matches want /opt < input /dev/mqueue
DEBUG : mntdir_matches want /opt < input /dev/hugepages
DEBUG : mntdir_matches want /opt < input /proc/fs/nfsd
DEBUG : fsmnt /var != reqdir /opt
DEBUG : mntdir_matches want /opt < input /var/lib/nfs/rpc_pipefs
DEBUG : mntdir_matches want /opt < input /boot
DEBUG : fsmnt /srv != reqdir /opt
DEBUG : mntdir_matches want /opt < input /home
DEBUG : mntdir_matches want /opt < input /var/log
DEBUG : mntdir_matches want /opt < input /run/user/1343600009
DEBUG : 447MB available on /

}}}

Most concerning is that we are not checking memory sizes correctly.

I think there are also a number of sysctl to add to the this.

We need to detect when the use has configured the limits in the systemd configuration if present, or the nobody user.

We I'm not sure, but it doesn't look like this works with a prefix either.

I think perhaps dsktune should have the option to take a setup.inf file, and use that to check the exact filesystem mountpoints and their options, and filesystem permissions for the instance.

Future idea: dsktune to get an ldif parser, and to use this to check thread numbers and cachesizing offline?

Should we make dsktune link to libslapd to reuse functions?

This patch cleans up the code to our newer style guidelines, which will make it a lot easier to work with for the changes I plan to make.

Replying to [comment:9 firstyear]:

This patch cleans up the code to our newer style guidelines, which will make it a lot easier to work with for the changes I plan to make.
Could it be possible to give us some indication where the real changes are made? :) For instance, could it be possible to divide the patch into 2 -- one for the essential fix and the other for the indentation? Thanks...

This patch is only the indentation. I haven't done any fixes or logic changes yet. I was waiting for response about some of my ideas and comments in this ticket before I proceeded with the changes.

No wonder... I was going through, maybe one third and could not see some real changes, so I asked... :) If the patch is for the indentation. I give you an ack. Please go ahead and push it.

commit 2aa0be7

To ssh://git.fedorahosted.org/git/389/ds.git
2a9d49a..2aa0be7 master -> master

Clean up dsktune formatting.

Still need to add / develop features.

Per triage, push the target milestone to 1.3.6.

Metadata Update from @firstyear:
- Issue assigned to firstyear
- Issue set to the milestone: 1.3.6.0

7 years ago

@nhosoi Let's rethink for a second. What if instead of fixing dsktune, we shipped with a sysctl.d file that provided settings we think are appropriate?

Additionally, now with our improvements to memory and resource detection, we can automatically be discovering many of these issues. Is dsktune as relevant now? We could roll it into our new python tools/installer instead?

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to new
- Issue close_status updated to: None

7 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus reset (from new)
- Issue set to the milestone: 1.4 backlog (was: 1.3.6.0)

6 years ago

Metadata Update from @firstyear:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

6 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1717

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata