ittserver as root, but
ittserver has problems accessing files. Why is that?
Remote data collection is the ability to:
collect data on one machine (the Remote Agent system)
configure collection and view the data on another machine (the controlling system)
The VTune™ Performance Environment enables you to launch applications and perform data collection on Remote Agent systems. The Remote Agent system only needs a small subset of the VTune™ Performance Environment product files. You can perform data collection on a number of Remote Agent systems, each running a different supported operating system.
For remote data collection, two systems are required:
Client system running on a Microsoft* Windows* operating system, which configures and manages Activities, and displays data collection results
Server system running on a Linux* operating system, the Remote Agent, which handles the remote data collectors and sends the results to the client system for display
The following scheme shows the relationship between the components on these systems:
Windows* <-+-> ittserver <---> collector1.so ... . . collectorN.so
Client in VTune(TM) | server data collectors
Performance Environment |
|
|
<-- Windows* --> | <----------------------- Linux ---------------------------------->
The Remote Data Collection Server ittserver is a shared component of Intel(R) Thread Profiler and Intel(R) Thread Checker. Before starting the remote data collection server, configure your Linux* system properly. See product Release Notes for configuration requirements.
Remote data collection procedure as shown above follows these steps:
At startup, ittserver initializes all its data collectors and begins listening for requests on a specified IP port 50002.
The Windows* client sends a message to the server and waits for reply.
The server dispatches that message to the remote collector and then continues listening for more requests from the Windows* client.
After finishing the current activity run the collector notifies the server, which in turn notifies the Windows* client. If requested, the server also sends data resulting from the task back to the Windows* client.
The Windows* client displays the resulting data for your analysis.
Each collector has its own set of requirements. If a collector's requirements are not met, or if an error occurred during a collector's initialization, then the server may continue to run, but access to the collector is disabled.
Thread Profiler remote data collection works in the following way:
In the Thread Profiler on Windows*, specify the Linux* application on which to perform Thread Profiler remote data collection, the desired Thread Profiler instrumentation level, and other configuration options.
Thread Profiler on Windows* forwards the information to the Thread Profiler remote data collector running on the Linux* system.
The Thread Profiler remote data collector instruments the application and all libraries used by the application on the Linux* system. The instrumentation produces a new set of binaries representing the instrumented application and places them in the Thread Profiler remote collector cache directory.
The instrumented application is run. During its execution, Thread Profiler data is collected.
Upon successful completion, data generated during the Thread Profiler remote data collection is transferred to the Thread Profiler on Windows* for you to view and analyze.
In Thread Profiler for Windows*, click the red stop button.
kill -9 <PID>. If you interrupt data collection, Thread Profiler might not display complete Activity results.
In your Windows* terminal, consider the screen where ittserver was running. You may have pressed Ctrl-S or clicked a mouse to select another mode in the Windows* terminal.
Make sure that the ittserver is not suspended: press Ctrl-Q or ESC.
Avoid suspending ittserver output. Doing so can cause the application to hang until you restore normal ittserver output.
One of the methods to stop a running application is to send a special signal to the processes of the application. The default signal is SIGUSR2, but if this signal is already used by the application, specify an alternative signal number, which can be handled by applications in the __Bistro_Exit_Signal__ environment variable. Signal numbers may be found in <bits/signum.h> standard header file.
Two potentially different directories are used on the Linux* system to store temporary data.
Thread Profiler remote data collector cache directory. The default location is /tmp/tp_<windows_login>_cache.
You can change the default in the Thread Profiler on Windows*, Configure->Options->Intel® Thread Profiler->Collector->Cache Directories.
ittserver data directory. The default locations are <current directory>/.bistro_server and <current directory>/.bistro_temp.
Both directories must be writable.
No. Currently, the Thread Profiler remote data collector ignores the duration setting.
You can pass environment variables to an application on Linux* in one of the following ways:
ittserverSet any environment variables required by the application.
Start ittserver.
In Thread Profiler for Windows*, go to the Advanced Activity Configuration dialog box and under Application/Module Profiles, select the application and then click Configure. The General dialog box appears.
Click Advanced, deselect Use default environment, and enter environment variables in the form "VARIABLE=value" (for example, "FOO=3").
Click OK to save your settings.
Write a shell script that sets the variables and runs the application.
In Thread Profiler on Windows*, configure your Activity by specifying your shell script as the application to launch and define an executable name as the module of interest.
If you set an environment variable that is intended to change default paths for dynamically linked libraries, such as LD_LIBRARY_PATH or LD_ASSUME_KERNEL, you must do so before starting ittserver.
Verify that the following conditions are met to launch a Linux* application:
Application is in a location that is accessible to a user launching ittserver.
Application is executable by a user launching ittserver.
Application is not a command-line application that expects interactive user input.
If the application was built with an Intel compiler, source iccvars.csh or iccvars.sh or source ifortvars.csh or ifortvars.sh as appropriate.
ittserver as root, but ittserver has problems accessing files. Why is that?If the files are located on a networked file system (for example, through NFS*, AFS*, or Samba*), then restrictions may exist on root access to those files or directories containing those files. Check with your system administrator for details.
If the application was built with an Intel compiler, source iccvars.csh or iccvars.sh or source ifortvars.csh or ifortvars.sh as appropriate.
It is highly recommended that ittserver be run as a non-root user. If multiple users need to use ittserver, then add those users to a special group and make sure that the relevant files and directories can be accessed by members of the group. Then run ittserver as one of the non-root members of the group.
Currently, the matching of Thread Profiler data to source is done in Thread Profiler on the Windows* side. When Thread Profiler encounters a reference to a Linux* source file for the first time, it prompts you for the location of where to retrieve the file. Retrieve the file in one of the following ways:
Manually copy it from Linux* to Windows*. The file location must follow the Windows* filename syntax, for example, DRIVE:\path\to\sourceFile.
Export the remote Linux* file system through NFS*, AFS*, Samba*, or similar. The file location must follow the appropriate Windows* filename syntax, for example, \\linuxMachineName\path\to\sourceFile if not mapped to a DRIVE: <letter>, or DRIVE:\path\to\sourceFile contact your system administrator for details.
Once Thread Profiler matches the source against Thread Profiler data, the tool caches the source location. Subsequent use of the same source will re-use the cached location. If Thread Profiler detects that the binary has changed, or if the cached source location for that binary has been cleared, then the Thread Profiler again prompts you for the location of where to retrieve the source file.
The source location cache can be cleared by going to the Configure->Options->Directories->File Association dialog box in the VTune™ environment on Windows*.
No. Currently, only one application may have a Thread Profiler remote data collection session. This single application must be specified inside the application in the module of interest field in the Application/Module Profile Configuration dialog box.
No. Currently, multiple users on a Linux* system cannot perform Thread Profiler remote data collection at the same time. Users must coordinate their Thread Profiler remote data collection sessions at different (non-overlapping) times on the same Linux* system.
Information in this document is provided in connection with Intel products. No license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted by this document. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS, INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. Intel products are not intended for use in medical, life saving, or life sustaining applications.
This FAQ document for Thread Profiler, and the software described herein, is furnished under license and may only be used or copied in accordance with the terms of the license. The information in this document is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Intel Corporation. Intel Corporation assumes no responsibility or liability for any errors or inaccuracies that may appear in this document or any software that may be provided in association with this document.
Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them.
Intel SpeedStep, Celeron, Dialogic, i386, i486, iCOMP, Intel, the Intel logo, Intel386, Intel486, Intel740, IntelDX2, IntelDX4, IntelSX2, Intel Inside, the Intel Inside logo, Intel NetBurst, Intel NetStructure, Intel Xeon, Intel XScale, Itanium, MMX, MMX logo, Pentium, Pentium II Xeon, Pentium III Xeon, and VTune are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
Copyright © 2000 - 2006, Intel Corporation, All Rights Reserved.
* Other names and brands may be claimed as the property of others.