As DS has evolved, systems have changed, and dsktune should advise on new settings.
dsktune should:
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: {{{
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]
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.
/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?
attachment 0001-Ticket-48386-Clean-up-dsktune-code.patch
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
@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
Metadata Update from @mreynolds: - Custom field reviewstatus reset (from new) - Issue set to the milestone: 1.4 backlog (was: 1.3.6.0)
Metadata Update from @firstyear: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.