I have struggle a bit with my preferred tool to understand where the profiling data is stored these days, as it has changed quite a bit from the initial release of the tool in version 6.0 SP3 (this dates by quite a bit now).
It started a few month ago when one of my customer had some issues. We noticed that clearing the profiler was very slow. Going at data rates of just a MiB per second.
I was trying to locate the buffer files, as the profiler versions early from 7.1 used to store the data in a zero-impact buffer file. But this was not yielding any results. I could see from the Windows folder some temp files being written but not much else.
It continued with another customer last week, and today whilst I was opening a 16GiB buffer file it all came clear. I started by cleaning up a local drive to have enough space to old the file and do a local import. After copying the full file at a rate of 375 Mbps (still it took ~10 minutes) I thought I had done most of the hard work. I opened the profiler, selected the buffer file, and I saw the import progress running at a meager 5~8MiB per second.
I then referred the issue to my best friend on Windows aka Sysinternals Procexp.exe and it promptly showed me that the IO stream on the profiler matched the network stream. But wait, where was this stream going to? Only one option: my SQL server, as I run a centralized instance for all of my test systems.
And this is it. The missing link: somehow since 7.1 the Altiris profiler stores its data inside the SQL server. I couldn't see this previously as I have some standalone SQL instances (that was needed to run a system without Internet access for reasons I won't detail here) but the featured images shows it all:
Now, I guess I was right in cancelling the 64 GiB profiler trace file import I received last week, as my SQL server threw an exception processing this 16GiB file (with not enough space in the system drive where SQL is installed, whilst the inserts were happening inside the Altiris database on another drive with plenty of space).
This will require a little more digging, but I can't help asking myself what benefit do we have exporting data from a file on the local system to the SQL in term of performance and scalability?