Matlab on Windows 2008 Terminal Server

1 view (last 30 days)
Nick Steven
Nick Steven on 12 Feb 2014
Commented: Tobias Hoffmann on 9 Oct 2014
Dear all,
We are running Matlab 2011a on a shared Windows 2008 Terminal Server (TS for short). The users login to the TS from their workstations using Microsoft Remote Desktop. The TS is a physical box (8 Core(s) x 4 2260MHz), 250GB memory.
Typically we have 5-6 users of Matlab active on the system at any one time. The users edit and debug their Matlab code through the Matlab GUI. For heavy calculations we provide a cluster of Blade servers running MDCS - so the users can offload and get decent performance.
On an apparently sporadic basis the Matlab GUI users report that the Matlab GUI becomes unresponsive - i.e. clicking on menus and typing in the command-window is slow. I have dome some performance tracing on the system at the time the users report the problem - my empirical observations have been: - Overall system CPU and memory usage at the time the problem occurs are within "reasonable" bounds - i.e. no more than 25% - There will be 4 or 5 MATLAB.EXE processes running (one per user) - and maybe one of them will be consuming 20GB memory because the one user is doing some kind of big array manipulation. On average the others are consuming a few hundred MB each. CPU consumption no more than 2-3%. - Other aspects of the remote desktop (e.g. Windows Start Menu, Notepad, MS Office Applications, SAS Enterprise Guide, Eclipse etc) behave quite responsively - and do not seem to be impacted even though Matlab is frozen.
As a test, I fired up several 5 MATLAB GUI sessions in parallel, and in each one launched a calculation that is manipulating a large array (80MB) and in a 6th MATLAB GUI session tested the responsiveness of the GUI. Sure enough performance dies - even though on the system overall, CPU and memory are hardly used.
My current take on the situation:
My understanding of the MATLAB GUI is the software (MATLAB.exe) is little more than a Matlab MDCS worker running in GUI mode - or conversely a MDCS worker is MATLAB.EXE running in non-GUI mode.
When we first built the MDCS compute cluster we did it on a 32 core W2K8 application server - and found that once you got beyond 6 cores being occupied by (e.g.) a parfor loop that is making intensive manipulation of arrays, matrices etc, we ran into a bottleneck caused by contention on L3 cache. Hence we got around this by basing our cluster on many smaller 12-core Blade servers. and we run no more than 6 workers per server.
I am wondering if we are seeing a similar L3 contention issue on the Terminal Server - and maybe the answer is to move to several smaller terminal servers. But the fact that other applications peform fine when Matlab is the one hanging / going slowly makes be doubt this.
We are already in conversation with Mathworks to discuss the problem. Although the installation notes for Matlab state that Windows 2008 is supported - Mathworks support take the line that they have never really tested Matlab GUI running on a shared Terminal Server. To be fair they are helping us to look into the problem nevertheless.
My questions to the forum are:
  • Is anyone else out there running Matlab on a shared Terminal Server similar to what we are doing?
  • If yes, have you encountered similar performance issues to what I describe where Matlab just hangs from time to time?
  • Did you manage to find a workaround?
Thanks in advance.
Cheers,
Nick Steven.
Zürich, Switzerland
  1 Comment
Tobias Hoffmann
Tobias Hoffmann on 9 Oct 2014
Hi Nick,
also here in Zurich and stumbling precisly over same problem. Mathcad bench is ranging below windowsXP on a 80 Core 256 GB XEON machine - ok virtulaized in KVM w2k8r2 32 Cores / 32 GB ram assigned.
Any tip how to improve appreciated ...
Best & have a nice day Tobias

Sign in to comment.

Answers (0)

Categories

Find more on Startup and Shutdown in Help Center and File Exchange

Products

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!