Adding a profiling page

Author: aplopez

src/contents.rst

@@ -12,6 +12,7 @@ Table of Contents
    contrib/debugging-sssd
    contrib/coding-style
    contrib/running-tests
+   contrib/profiling-sssd
 
 .. toctree::
    :caption: Fundamentals

src/contrib/profiling-sssd.rst

@@ -0,0 +1,94 @@
+Profiling SSSD
+##############
+
+Getting Ready
+*************
+
+There are several tools allowing us to profile an application. We will focus on
+perf_ which seems to be the one that works best with SSSD.
+
+.. _perf: https://perf.wiki.kernel.org
+
+First you need to install the ``perf`` tool:
+
+.. code-tabs::
+
+    .. fedora-tab::
+
+        # dnf -y install perf js-d3-flame-graph
+
+    .. ubuntu-tab::
+
+        $ sudo apt install linux-tools-common linux-tools-generic
+
+
+Make sure SSSD's and its dependencies' debug information is available, either
+by using ``debuginfod``, or by manually installing the debug information packages:
+
+.. code-tabs::
+
+    .. fedora-tab::
+
+        # dnf -y --enable-repo=fedora-debuginfo --enable-repo=updates-debuginfo \
+        install sssd*debuginfo libsss_*-debuginfo samba-client-libs-debuginfo \
+        libldb-debuginfo libtevent-debuginfo libtalloc-debuginfo glibc-debuginfo
+
+More information on `Debug Symbol Packages`_ for Ubuntu.
+
+.. _`Debug Symbol Packages`: https://documentation.ubuntu.com/server/reference/debugging/debug-symbol-packages/
+
+It is possible that SELinux prevents ``perf`` from monitoring your process.
+If that happens, you can create the required rules or temporarily disable selinux:
+
+.. code-block:: console
+
+    # setenforce Permissive
+
+
+Profiling
+*********
+
+The simplest way to profile one of the SSSD's daemons is to attach the profiler
+to the process while it is running.
+
+Once SSSD is running and ready to be profiled, identify the PID of the process
+you want to monitor (``sssd_ssh``, ``sssd_nss``, ``sssd_be``, etc.), start the
+``perf`` command in the background, launch the operation you want to profile
+and stop the profiling after the operation completes:
+
+.. code-block:: console
+
+    # PID=$(pgrep -f 'sssd_be --domain LDAP')
+    # perf record --pid=$PID --call-graph=dwarf -e cycles:u &
+    # id user1002@LDAP
+    # kill %%
+
+This will create a ``perf.data`` file in your current directory. It is
+recommended to process this file in the same machine, so that the debug
+information matches perfectly the installed binaries. You can later move the
+results to another host.
+
+The ``-e cycles:u`` argument tells ``perf`` to only monitor the CPU cycles the
+application consumes in user space. The kernel will not be profiled. Check the 
+``perf-record(1)`` man page for more options that might be useful in you
+particular case.
+
+Generating the Reports
+**********************
+
+We will create two types of reports: a text report and a flame graph to be seen
+in a web browser. But before doing that, it is necessary to update ``perf``'s
+cache of debug information:
+
+.. code-block:: console
+
+    # perf buildid-list
+    # perf report -g > report.txt
+    # perf script report flamegraph
+
+The files ``report.txt`` and ``flamegraph.html`` contain the reports, are
+self-containerd, and can safely be moved to another host.
+
+Other reports are available. You can learn about them in the ``perf-script(1)``
+man page.
+