Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-32970

server.xml contains incorrect parameters for threads in the default connector

XMLWordPrintable

      We currently ship Confluence with Tomcat 6, but the default connector still references maxProcessors. This attribute was deprecated in Tomcat 5.5 and no longer exists in Tomcat 6.

      Instead, to control the number of threads that the application can use, you need to specify maxThreads.

      References:
      http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html
      http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
      http://grokbase.com/t/tomcat/users/065aw5k4a8/maxthreads-compared-to-maxprocessors

      Default connector:

      <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" port="10542" 
      minProcessors="5" maxProcessors="75"
      enableLookups="false" redirectPort="8443" acceptCount="10" debug="0" connectionTimeout="20000"
      useURIValidationHack="false" URIEncoding="UTF-8"/>

        1. screenshot-1.png
          screenshot-1.png
          18 kB

            [CONFSERVER-32970] server.xml contains incorrect parameters for threads in the default connector

            Ethan Foulkes added a comment -

            Hi Denise,

            Any idea why my CPU usage always looks like the attached screenshot? I was thinking it was because of this but must be another reason...

            Ethan Foulkes added a comment - Hi Denise, Any idea why my CPU usage always looks like the attached screenshot? I was thinking it was because of this but must be another reason...

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment -

            Hi efoulkes and intersol_OLD,, actually this parameter doesn't control the number of cores used by Tomcat, it's purely the number of HTTP threads that Tomcat will allow. There's some more information regarding the parameter on this page.

            Each incoming request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the maxThreads attribute). If still more simultaneous requests are received, they are stacked up inside the server socket created by the Connector, up to the configured maximum (the value of the acceptCount attribute). Any further simultaneous requests will receive "connection refused" errors, until resources are available to process them.

            In terms of Tomcat using multiple cores, it actually does this out of the box. There's no configuration required for Tomcat to take advantage of a multi-core system. There's some more info here.

            Sorin, regarding Atlassian providing recommendations for the number of threads to allow, we actually provide some guidance for how to baseline and determine your requirements for HTTP threads and database connections in this article. We set defaults in the standalone instances we provide that we expect to work for the majority of customers. The relationship between concurrent load, usage patterns, your database capability and Tomcat threads is very complex, which is why we don't provide preset recommendations for customers beyond the default. We simply wouldn't be able to guess at a value that will work for every different instance - there is no one-size-fits-all solution. What is appropriate for one instance and usage profile would be completely inappropriate for another. If your instance is larger, you may want to consider performing some tuning and modifying those settings to better fit your needs. This is a service that a TAM might provide if there was an indication that an instance could benefit from that kind of tuning, but it's also tuning you can perform for yourself if you think it would be of use. There unfortunately are no defaults we can give, because the values are so instance specific.

            Hope this helps!

            Denise Unterwurzacher [Atlassian] (Inactive) added a comment - Hi efoulkes and intersol_OLD ,, actually this parameter doesn't control the number of cores used by Tomcat, it's purely the number of HTTP threads that Tomcat will allow. There's some more information regarding the parameter on this page . Each incoming request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the maxThreads attribute). If still more simultaneous requests are received, they are stacked up inside the server socket created by the Connector, up to the configured maximum (the value of the acceptCount attribute). Any further simultaneous requests will receive "connection refused" errors, until resources are available to process them. In terms of Tomcat using multiple cores, it actually does this out of the box. There's no configuration required for Tomcat to take advantage of a multi-core system. There's some more info here . Sorin, regarding Atlassian providing recommendations for the number of threads to allow, we actually provide some guidance for how to baseline and determine your requirements for HTTP threads and database connections in this article . We set defaults in the standalone instances we provide that we expect to work for the majority of customers. The relationship between concurrent load, usage patterns, your database capability and Tomcat threads is very complex, which is why we don't provide preset recommendations for customers beyond the default. We simply wouldn't be able to guess at a value that will work for every different instance - there is no one-size-fits-all solution. What is appropriate for one instance and usage profile would be completely inappropriate for another. If your instance is larger, you may want to consider performing some tuning and modifying those settings to better fit your needs. This is a service that a TAM might provide if there was an indication that an instance could benefit from that kind of tuning, but it's also tuning you can perform for yourself if you think it would be of use. There unfortunately are no defaults we can give, because the values are so instance specific. Hope this helps!

            Ethan Foulkes added a comment -

            I think the answers you need may be provided right here Sorin. If you're running Confluence prior to 5.5.4 then the your conf file is still referencing min and max processors instead of threads so it's ignoring whatever number you have in there. Your options would be to either upgrade Confluence or just manually change the conf file to threads yourself. This is the route I would take myself (on a test environment first of course) if I needed the extra CPUs. If you do this successfully please let me know, if your successful and it was easy maybe I'll give it a whirl...

            Best,
            Ethan

            Ethan Foulkes added a comment - I think the answers you need may be provided right here Sorin. If you're running Confluence prior to 5.5.4 then the your conf file is still referencing min and max processors instead of threads so it's ignoring whatever number you have in there. Your options would be to either upgrade Confluence or just manually change the conf file to threads yourself. This is the route I would take myself (on a test environment first of course) if I needed the extra CPUs. If you do this successfully please let me know, if your successful and it was easy maybe I'll give it a whirl... Best, Ethan

            intersol_old added a comment -

            I do have 32 cores on that machine and the current setting is 250. Also I do find really worrying that Atlassian does not provide any documentation regarding which settings to pick based on your configuration. I guess that keep this information secret in order justify the TAM services.

            intersol_old added a comment - I do have 32 cores on that machine and the current setting is 250. Also I do find really worrying that Atlassian does not provide any documentation regarding which settings to pick based on your configuration. I guess that keep this information secret in order justify the TAM services.

            Ethan Foulkes added a comment -

            I've noticed that only 8 of my 16 cores get used so I would imagine this could have a big impact. We don't have any performance problems so I haven't bothered to manually change to threads instead of processors but that seems like the logical thing to do if all your cores aren't being utilized by Confluence.

            Ethan Foulkes added a comment - I've noticed that only 8 of my 16 cores get used so I would imagine this could have a big impact. We don't have any performance problems so I haven't bothered to manually change to threads instead of processors but that seems like the logical thing to do if all your cores aren't being utilized by Confluence.

            intersol_old added a comment -

            Am I wrong or this bug has a huge impact on big / high load instances?

            intersol_old added a comment - Am I wrong or this bug has a huge impact on big / high load instances?

            Matthew Erickson added a comment -

            Test notes

            Built the distribution and started it up. Looks fine. Examined the server.xml file and it looks as expected.

            Matthew Erickson added a comment - Test notes Built the distribution and started it up. Looks fine. Examined the server.xml file and it looks as expected.

            Phong Quoc Le (Inactive) added a comment - - edited

            QA Steps:

            1. Run atlas-mvn clean package
            2. Go to confluence-distribution -> standalone -> target -> atlassian-confluence-X.X.X.zip -> conf -> server.xml
            3. Verify all out of date parameters has been removed and some up to date parameters have been added.

            Removed parameters: className, minProcessors, maxProcessors, maxSpareThreads
            Added parameters: maxThreads, minSpareThreads

            4. atlassian-confluence-X.X.X.zip is Confluence standalone version. It can be installed as https://confluence.atlassian.com/display/DOC/Installing+Confluence+on+Linux+from+Archive+File

            Note: if you have a problem with confluence-licenses.zip, please use the command bellow to build Confluence core on your local first

            scripts/build.rb -i --third-party-licensing

            Phong Quoc Le (Inactive) added a comment - - edited QA Steps: 1. Run atlas-mvn clean package 2. Go to confluence-distribution -> standalone -> target -> atlassian-confluence-X.X.X.zip -> conf -> server.xml 3. Verify all out of date parameters has been removed and some up to date parameters have been added. Removed parameters: className, minProcessors, maxProcessors, maxSpareThreads Added parameters: maxThreads, minSpareThreads 4. atlassian-confluence-X.X.X.zip is Confluence standalone version. It can be installed as https://confluence.atlassian.com/display/DOC/Installing+Confluence+on+Linux+from+Archive+File Note: if you have a problem with confluence-licenses.zip, please use the command bellow to build Confluence core on your local first scripts/build.rb -i --third-party-licensing

              ple Phong Quoc Le (Inactive)
              dunterwurzacher Denise Unterwurzacher [Atlassian] (Inactive)
              Affected customers:
              5 This affects my team
              Watchers:
              10 Start watching this issue

                Created:
                Updated:
                Resolved: