7 Replies Latest reply on Jun 8, 2012 8:50 AM by Zach Leber

    7.0 Data Server Process: Can these kill performance?

      Hi All,

       

      Does anyone know if it's okay to set the number of "data server" processes to zero in Tableau Server 7.0?

       

      Background:

      We use Tableau Server with the 8 core license model. We've been using 6.1 just fine... all published workbooks are in the form of packaged workbooks with built in extracts.

       

      We upgraded to 7.0 and performance suuuuuuuucked. So we tore it out and went back to 6.1.

       

      The only difference that I could see in configuration was the addition of "data server" processes, which did not exist in 6.1. We had set the number of these processes to 8, as we have 8 VizQL processes, and 8 Server Web Application processes. This may have been a very bad idea, and may have been the root of our issue. As we don't use the data server functionality at all, I'm thinking we should make another run at upgrading, with the data server processes set to zero.

       

      Unfortunately the documentation on this is pretty sparse, and I haven't had much luck with Tableau Support (I'm guessing they are still getting up to speed on this too). So I thought I'd test the collective wisdom of the forum.

       

      Anyone know:

      1) if running too many data server processes will kill performance?

      2) if it's safe to run zero data server processes?

       

      Thanks,

      Jamie

        • 1. Re: 7.0 Data Server Process: Can these kill performance?
          James Baker

          There are big differences between 6.1 and 7.0.  You don't want to run zero data server processes - but you don't need to either.

           

          We changed up our process/threading model in 7.0, and the upgrade process takes whatever number of processes you were set to and changes it to 2.  Having more than 2 shouldn't be necessary for most installs.  Having too many can in fact hurt you - I'm suspecting that trying to start 8 is exhausting your physical ram and thrashing your performance via memory paging.  If, using 2 procs, you're experiencing very high memory usage per vizqlserver process, then, if you have enough RAM (>=16GB), you can add more vizqlserver.exes up to 8 to alleviate memory usage per process.  See this KB article: http://kb.tableausoftware.com/articles/knowledgebase/server-processes-down-after-upgrade

          1 of 1 people found this helpful
          • 2. Re: 7.0 Data Server Process: Can these kill performance?

            Thanks James. We'll try that tonight and I'll post the results in the next couple of days.

             

            - Jamie

            • 3. Re: 7.0 Data Server Process: Can these kill performance?
              Zach Leber

              We saw this KB article over the weekend and have just dropped our number of Web, VizQL, and DS processes from 8 to 2, no ill effects seen yet.  We're prepared to increase the number of VizQL processes if production users start running out of memory.

              1 of 1 people found this helpful
              • 4. Re: 7.0 Data Server Process: Can these kill performance?

                Zach,

                Thanks, that's helpful. Just to gauge the size of your deployment, on a given day, what's your maximum concurrent user load like? And do you have an estimate of the size or complexity of your reports? (I.e. do they have 1.5mm rows of data, and multiple table calculations, or are they 10k rows of data, and generally straightforward viz's?)

                - Jamie

                • 5. Re: 7.0 Data Server Process: Can these kill performance?
                  Zach Leber

                  We have about 100 users but the number of sessions per minute peaks around 6.  Our reports are of moderate complexity, often involving multiple data sources joined or related at runtime, each data source ranging from a few thousand to a few hundred thousand rows of data.   Our biggest performance crunch is actually memory exhaustion when users try to render ten-thousand row text tables because they've accidentally or deliberately set their filter settings too wide.  Those giant text tables can run their VizQL process out of memory.  None of our graphical visualizations have this problem because they are aggregating data and taking fewer bytes to render each mark.

                  • 6. Re: 7.0 Data Server Process: Can these kill performance?
                    Zach Leber

                    We recently switched all our users from Server 6.1.7 to Server 7.0.3 and under production load we had sessions running out of memory when using 4 VizQL processes so at tech support and engineering's recommendation we went back to 8 VizQL processes and reduced the vizqlserver.session.expiry.timeout to 10 minutes.  For us it's much more important that each user gets maximum memory than that they get a possible cache hit.  A problem with users sharing processes is that there's a per process limit for memory, so if one user exhausts it, other unsuspecting users are affected.  When we update to 7.0.4 we'll be able to have 4GB per process rather than 2GB.

                    • 7. Re: 7.0 Data Server Process: Can these kill performance?
                      Zach Leber

                      The Server 7.0.4 update (+ 7.0.5 bug fix) improved memory handling in two ways: better in-process memory reclamation and an increase in the maximum memory per VizQL process from 2GB to 4GB.  So we've switched back to a 30-minute timeout for the VizQL processes but stuck with 8 of them because we're still favoring maximum memory per user over possible cache hits.  So far so good.