Lower down max_threads

Currently max_threads defaults to 5 * (number of CPU cores). Because
ThreadPool is created in each worker, and max_workers defaults to
(number of CPU cores), the total number of threads is by default
5 * (number of CPU cores) * (number of CPU cores) . In case a node has
24 cores CPU, orchestrator may launch 2880 threads at maximum, which is
too large. (Note that it may even launch doubled number of threads due
to separate workers for rating processing and reprocessing).

Lower down the default max_threads, by getting rid of the factor
dependent on number of CPU cores, to have reasonable cap by default.

Change-Id: I0efbf6b9e5331acc0d9f334cbbe6bebeecc5722a
Signed-off-by: Takashi Kajinami <kajinamit@oss.nttdata.com>

cloudkitty/orchestrator.py

@@ -64,18 +64,16 @@ orchestrator_opts = [
     cfg.IntOpt(
         'max_workers_reprocessing',
         default=multiprocessing.cpu_count(),
+        sample_default=4,
         min=0,
         help='Max number of workers to execute the reprocessing. Defaults to '
              'the number of available CPU cores.'),
     cfg.IntOpt('max_threads',
-               # NOTE(peschk_l): This is the futurist default
-               default=multiprocessing.cpu_count() * 5,
-               sample_default=20,
+               default=16,
                min=1,
                deprecated_name='max_greenthreads',
                advanced=True,
-               help='Maximal number of threads to use per worker. Defaults to '
-               '5 times the number of available CPUs'),
+               help='Maximal number of threads to use per worker.')
 ]
 
 CONF.register_opts(orchestrator_opts, group='orchestrator')

releasenotes/notes/lower-down-max-threads-be7e9fdf8dd45343.yaml

@@ -0,0 +1,5 @@
+---
+upgrade:
+  - |
+    The ``[orchestrator] max_threads`` parameter now defaults to 16, to avoid
+    too many threads in total in node with many CPU cores.