1 2 3 4 Previous Next 55 Replies Latest reply on May 3, 2017 11:00 AM by erik lundberg Branched to a new discussion.

    Server Administrator Rockstars, we’d love to hear from you!

    Kitty Chou

      To view the recording of this event, visit: Dev Office Hours: Server Deployment & IT Administration - YouTube

       

      Hello Tableau Server and IT Admin Community!

       

      Does your primary jobs involve deploying Tableau Server, worrying about server installs, upgrades, authentication, high availability, security? You have the ear of the Product Managers and development teams that work in this space. We are excited to start this discussion forum to cover anything Server Deployment and Administration related. We're open to questions, comments, insights, feedback, and enhancement requests about working with all versions of Tableau Server.

       

      Our team will be checking in on this thread regularly for the next week, responding to any and all questions. We will be then be doing a LIVE "office hours" on April 20th to give you a chance to ask your questions or give us feedback in person.

       

      We can’t wait to hear from you!

       

      Aruna Balasubramanian and Kitty Chou

      Senior Product Managers

       

      Message was edited by: Tracy Rodgers to update with the event recording

        • 1. Re: Server Administrator Rockstars, we’d love to hear from you!
          Jeff Strauss

          Wow, where do I start?  Seriously, thanks for setting this up!

           

          One that is top of mind right now is data Extracts.  Many extracts are pulled from our DW environment.  We would love to be able to have more transparency into % of extract duration that is SQL fetching the data vs. import / optimization / etc.  Right now, it just shows total duration.  Then we can make an argument that the import is quite fast in relation to the SQL and perhaps the underlying structures need to be tuned.

          3 of 3 people found this helpful
          • 2. Re: Server Administrator Rockstars, we’d love to hear from you!
            Toby Erkson

            Let me prefix this with the following:

            I am not a server-educated person.  My background is script & application programming and, naturally, BI report development from cradle to grave.  It is quite possible that my concerns reflect that of a newb and I'm fine with being called out on that if this is stuff that all server-specific IT people understand.  From my view, Tableau is meant to be easy to use and Desktop is successful with that for business users, however, my experience with Server is that it's not so simple.

             

             

            When studying for the Tableau Server associate exam I took a server admin class as part of my preparation.  We got some good materials to help us better understand Tableau Server and I was able to capture two items:

            Server 9.3 component diagrams from admin class

            Server Admin. 9.2 class - Component Functions

            There is also some information scattered in the Server Administrator Overview guide and if one is vigilant in reading the Server & Online Administration forum then there can be the occasional nugget of info (Re: Are there any alternative Tableau Backup & Restore approaches? ~Mark Wu).

             

            So what's my point?  Not enough in-depth Tableau Server knowledge, particularly around the internal workings.  If someone wants to know how to do something in Desktop there are exactly 1.2 jazillion-billion forum posts, YouTube videos, and bloggings to help them.  The distribution of Tableau Server knowledge, particularly the inner-workings, is magnitudes smaller.

             

            Example:  My current dilemma is how to setup my Server environment that is not only a core upgrade but also a distributed upgrade (1-node to 2-nodes) in an efficient and most-likely-to-succeed manner.  Much of my processes placement (# of backgrounders, VizQL, Cache Servers, etc.) are WAGs because I don't know how Server works.  What exactly is involved when a viz is displayed on a browser?  What exactly is involved when a published data source is used in a scheduled extract?  What exactly is involved when a subscription is triggered?  These are simply some examples that go through my mind, I'm not looking for these specific questions to be answered here.  If I knew how things worked internally I could then have a better idea on how to set up my Server(s) for my particular situation since everybody's situation is different.

             

            Having to use the defaults and then tune along the way doesn't seem efficient to me, particularly when bringing down the production server would need to be done after-hours and results measuring would have to wait until the next day.  Using a QA environment is okay for those lucky to have a large virtual environment where their Server resides but having a physical environment mirroring production could very well be cost prohibitive.  Ideally I could install a backup of my production server (1000's of users and vizes) on the QA server and see what happens, tuning as necessary (with 5 minute restarts every time ), but what about those pesky subscription emails -- can I have those execute but just not get emailed (again, thinking out loud here)?

             

            Our technical sales rep. was helpful in that he told me the processes will look for available cores, even across nodes.  Cool!  The same goes for using memory if I understood correctly.  So while I now know I don't have to have X number of cores here and Y number of cores there, how does that affect the other resources on the nodes when other processes are running?  For example, for extract-heavy environments put Backgrounders on their own node.  Okay.  But how many cores & RAM should be on that specific node per Backgrounder so its work doesn't impact other processes (VizQL Server, Application Server, Data Server, and Data Engine) with the given total CPUs and RAM one is working with?

             

            My intention wasn't for this to have been a rant but an expression -- with real-life examples -- of my frustration in wanting to learn Server better so I can make the most out of what we have to give my customers the best Tableau experience they can get.

            4 of 4 people found this helpful
            • 3. Re: Server Administrator Rockstars, we’d love to hear from you!
              Paul Hardman

              As an "accidental" Tableau Server admin, firstly I must give kudos to the Server Dev team for creating a product that mostly stays up all by itself without the need for constant monitoring and massaging - and when it does decide to "have a moment" it will generally come back without a panicked phone call from one of my users.

               

              However I would like to see some improvements in the area of user management.  I know it's not cool, cutting edge stuff that makes a difference to the user herself - but without it, they wouldn't be a user at all, right?

               

              My current frustration is this.  Annie manages Bob, and gets a new hire, Charlie.  Annie submits a request to me saying "Can you please set Charlie up with a new user account on Tableau Server, and he should have the same access as Bob."

               

              So off I go to the Users tab, and do the following:

               

              1) Search for Bob, look up Bob's assigned groups and note them down

              2) Add new user Charlie and give him the appropriate access level

              3) Search for Charlie, go in and pick out the groups he needs access to, and save it.

               

              What would be amazing is, right under that "Interactor / Publisher" dropdown in the Add New User dialog, would be a checkbox that said "Copy access level from..." and a user selector. I'm sure that plenty of server admins would thank you forever!

               

              Paul

              5 of 5 people found this helpful
              • 4. Re: Server Administrator Rockstars, we’d love to hear from you!
                Eric Axelrod

                All good points here.

                 

                Off the top of my head I have 1 big ask.

                 

                The ability to:

                • Kill an extract refresh that is running
                • Remove an extract from the queue which is waiting

                 

                It's not often when we need to do it, but it's currently a real pain when we need to take load off the database server.  Prior to version 10 it was easy to ifentify and kill a backgrounder process in Windows Process Explorer to get an extract to stop.  Starting in v10 Tableau Server processes are a lot more durable -- they automatically restart themselves if they die.  So if there are 10 extracts running or in queue and someone needs to stop all database queries then it becomes a multi-hour ordeal to kill-wait-kill-wait for each extract refresh task to make sure it stays dead.

                 

                It should really be much easier to cancel running & queued tasks.

                 

                Eric Axelrod

                President & Chief Architect

                www.digr.io

                2 of 2 people found this helpful
                • 5. Re: Server Administrator Rockstars, we’d love to hear from you!
                  Eric Axelrod

                  Something else that would be hugely helpful -- improved monitoring.

                   

                  Integrate something like Tabmon directly into Tableau Server so teams don't have to install and maintain a different app.  Even basic RAM, CPU, and Disk I/O stats would be hugely helpful.  What would make it even better is the ability to trace those server resources down to an individual process or task.

                   

                  And we could also user richer data available 'as part of' the Postgres repository.  Basic info like view load times would be great without having to dig into log files.  Perhaps implement a NoSQL database alongside Postgres to store log data?

                   

                  Eric Axelrod

                  President & Chief Architect

                  www.digr.io

                  2 of 2 people found this helpful
                  • 6. Re: Server Administrator Rockstars, we’d love to hear from you!
                    aruna.bala

                    Thank you Jeff for the feature request and for the context on the problem you are trying to solve. Really appreciate your feedback on a major challenge you face today.

                     

                    Thanks for engaging with us and with the community.


                    Regards,

                     

                    Aruna Balasubramanian

                    • 7. Re: Server Administrator Rockstars, we’d love to hear from you!
                      aruna.bala

                      Thank you Paul. Totally understand the need for having permission templates. As you can imagine this comes up a lot. I know this is on our radar for things to improve. Really appreciate your presenting your particular use case.

                       

                      Thanks for engaging with us.


                      Regards,

                       

                      Aruna Balasubramanian

                      • 8. Re: Server Administrator Rockstars, we’d love to hear from you!
                        aruna.bala

                        Thank you Eric for the feedback. We understand this is a challenge for many of our customers just like you and this is certainly something we will be look at.

                         

                        Regards,

                         

                        Aruna Balasubramanian

                        • 9. Re: Server Administrator Rockstars, we’d love to hear from you!
                          Kitty Chou

                          Hi Toby Erkson,

                           

                          Thanks so much for your feedback on this.  It does seem that we don't have as much in depth knowledge of the internal workings of Tableau Server that is readily available to IT Administrators and is a challenging problem.  Because Tableau Server is a somewhat tightly-coupled system, for any particular scenario there can be many different processes that our involved and there is not a one-size fits all answer for how to scale out Tableau Server.

                           

                          Here are two good resources which you may or may not have been aware of that talk a little bit more about the server architecture as it relates to scalability and high availability

                          https://www.tableau.com/sites/default/files/whitepapers/scalability_deep_dive_0.pdf

                          https://www.tableau.com/sites/default/files/whitepapers/high_availability_10.0_0.pdf

                           

                          We'll also look at publishing additional resources to the Server Administrator community in the future with more in-depth server information.

                           

                          Cheers,

                          Kitty Chou

                          Product Manager

                          1 of 1 people found this helpful
                          • 10. Re: Server Administrator Rockstars, we’d love to hear from you!
                            Kitty Chou

                            Hi Eric Axelrod,

                             

                            Re: your comment on improved monitoring for Tableau Server.  This is absolutely something that we have been talking a lot about internally and a request we often hear from the Server Admin community.  We have some features in our pipeline that should address some of the suggestions you have around having monitoring RAM, CPU, etc. usage. 

                             

                            For your request to have data around view load times, have you checked out the built-in Administrative views?  In particular, the Stats for Load Times and Performance of Views reports may provide the data that you are looking for.  If these aren't sufficient or aren't meeting your needs, we'd love to hear more and understand why.

                             

                            Thanks again for your feedback!

                             

                            Cheers,

                            Kitty Chou

                            Product Manager, Tableau Server

                            • 11. Re: Server Administrator Rockstars, we’d love to hear from you!
                              Trevor Toll

                              This is a great idea. Thank you for putting it together!

                               

                              At the top of our wishlist:

                              1. Ability to kill a pending or in progress extract
                              2. We use TabCMD to queue extracts when our data warehouse dependencies have finished their nightly refresh and it has been a huge help in delivering timely data, however, TabCMD does not allow us to specify a priority of the extract and sends all of them through at the highest possible priority. This ends up causing #3....
                              3. Our users are often frustrated that Tableau is not delivering their subscriptions on time. It is because our backgrounder threads are getting hammered with long running Priority 1 TabCMD extracts for most of the morning so no subscriptions have the chance to run. It would be AMAZING to have a backgrounder thread just for subscriptions. Even better would be the ability to assign certain extract refreshes to certain backgrounders so we could have a fast lane for quicker running extracts.
                              4. Better Error Logging. It would be very helpful to have something like LogShark as a stock option for the product. It would be great to have better insight into what users are getting errors on which workbooks and how often.

                               

                              Thanks again,

                              Trevor

                              3 of 3 people found this helpful
                              • 12. Re: Server Administrator Rockstars, we’d love to hear from you!
                                Eric Axelrod

                                Kitty Chou,

                                 

                                Thanks for the reply.  I think this is going to be a very productive Dev Office Hours.

                                 

                                For your request to have data around view load times, have you checked out the built-in Administrative views?  In particular, the Stats for Load Times and Performance of Views reports may provide the data that you are looking for.  If these aren't sufficient or aren't meeting your needs, we'd love to hear more and understand why.

                                 

                                We use these built in administrative views regularly.  However they don't provide adequate detail to drill into 'the cause of the problem'.  When we are investigating why a workbook is 'slow' we often need VizQL process level data.  Things like request/response times for individual quickfilters, dashboard actions, Data blending operations, etc.  The HTTP_REQUESTS Postgres repository table does contain each and every mouseclick which triggered a request for each of these actions, and it's not terribly difficult to figure out what's what for lots of those actions, but it doesn't contain the response record -- so there is no way to calculate duration.

                                 

                                An administrator without this information would need to resort to tediously interacting with all of the interactive elements on a dashboard (with ?refresh=false) to isolate the non-performant ones.  And then doing it many times over the course of a day to isolate VizQL bottlenecks that could be caused by nothing more than other user requests to other workbooks at the same time.

                                 

                                That's why we regularly need to go to the logs.

                                 

                                Often we find the 'slowness' in a dashboard can be tied to a single action or a single calculated field.  The hard part is finding the one element which is causing the issue.

                                 

                                And on a related note -- it's rather common to have to resort to the logs to see the actual SQL (v.s. the SQL you see when you select 'convert to custom SQL' in the datasource editor) which a published datasource sent to a database.  One of the things we see often is users not correctly using date math operations in a datasource.  For example, using "[Date A]-[Date B]" instead of "datediff([Date A],[Date B])".  In some cases this causes fatal database errors.  And more often than not you don't know which column caused the issue in which row in your 100 million row x 100 column dataset.  (Oracle is particularly bad about the ambiguity of it's error messages.)  Oracle will give errors like 'numeric overflow' without indicating the row number, the key values, what the input values were which caused the overflow, or even the datatype of the input values.  So we have to resort to manually looking through 10 billion data points (and since the Query won't run against the database we can't use Tableau for this) to try to find a single erroneous date, integer, or decimal cell.

                                 

                                Another reason why we regularly need to go to the logs.

                                 

                                Eric Axelrod

                                President & Chief Architect

                                www.digr.io

                                • 13. Re: Server Administrator Rockstars, we’d love to hear from you!
                                  Eric Axelrod

                                  I second Trevor Toll

                                   

                                  1. We use TabCMD to queue extracts when our data warehouse dependencies have finished their nightly refresh and it has been a huge help in delivering timely data, however, TabCMD does not allow us to specify a priority of the extract and sends all of them through at the highest possible priority. This ends up causing #3....

                                   

                                  The only way around this is to refresh the extract with a tabcmd runschedule instead of a refreshextracts.  The problem with runschedule is that we can't run it in synchronous mode -- meaning we can't make tabcmd the process wait for the extract to complete before it returns a success.  This also means we can't add a secondary ETL process after the Extract runs via tabcmd, since you won't know when or if it completed.

                                   

                                  This takes me back to my above comment about killing backgrounder processes.

                                   

                                  Scenario - this is particularly bad in Microsoft SQL Server:

                                  • If Extract A is kicked off by tabcmd (using runschedule so we can use priorities)
                                  • Another ETL process needs to run after the extract
                                  • Extract A is still running when the ETL kicks off.
                                  • Extract A fails
                                  • We now need to restart our ETL which started after Extract A
                                  • If we don't kill the backgrounder which is running Extract A we end up with a database deadlock.

                                   

                                   

                                  So, we get to choose between

                                  • Database deadlocks which could cause either ETLs or Tableau extracts to fail, or
                                  • Clogging our backgrounders and our Database server with priority 1 extracts (which don't need to be priority 1).

                                   

                                   

                                  Eric Axelrod

                                  President & Chief Architect

                                  www.digr.io

                                  • 14. Re: Server Administrator Rockstars, we’d love to hear from you!
                                    Pradeep D

                                    HI,

                                     

                                    Issue:

                                    I have published an extract form of connected data source on to Tableau server. It has one excel sheet on share drive and one table from Netezza DB. While a schedules refresh is run on server, I am getting error "com.tableausoftware.nativeapi.dll.DataSourceException: Unable to materialize temporary table".

                                     

                                    Suggested solution: We are using UNC path for excel sheet as suggested but we are getting the same error again.

                                     

                                    We are publishing this workbook from tableau desktop which is not on Tableau Server machine.

                                     

                                    Any ideas on resolving this issue ?

                                    1 2 3 4 Previous Next