We have been experiencing recurring Tableau Server degradation on our production environment running Tableau Server 2025.3.3.
We have observed multiple service crashes and the server occasionally enters a degraded state.
- Mainly Vizdata Native service instances have entered an error state
- VizQL Server instances have also experienced crashes, although they recover and come back up
- Windows Event Viewer shows the following application errors:
- vizdataservice.exe crashed with exception code(access violation) with jemalloc identified as the faulting module.
- run-vizqlserver.exe crashed with exception code(heap corruption) with ntdll identified as the faulting module
- The crashes have occured at different times, across multiple Tableau processes
We have reviewed some of the service logs and crash files, but we have not yet identified a definitive root cause. We are investigating whether this could be related to Tableau Server build, a shared dependency, memory management, data source activity or any other underlying issue.
Questions:1. Has anyone experienced similar recurring crashes or degraded status on Tableau Server?
2. Could these errors be related to a product build, a specific workload or a shared dependency?
Any suggestions or similar experiences would be greatly appreciated.
Thank you in advance!
#Tableau Server
honnestly a .3 maintenance release is not optimal. Could be a bug or undesired effect. You should test the latest maintenance release of 2025.3 and compare.
That being said, you are not sharing much information about your server host and topology and load pattern. Tableau Server is designed to consume from 95% to 100% of all available resources (CPU / RAM / Disk drive) in case some heavy or expensive load is triggered. So to administrate a Tableau Server properly, ideally you should have monitoring in place that tells you at the moment of the crash, how many users were connected, how much CPU and RAM was being consumed by each Tableau process, and how much space there was left. Then you can understand where is the pain point. If you don't have any monitoring in place, a good start would be to load the TS logs into Logshark utility:
