The Mosix HOWTO
Prev	Chapter 12. Other Programs	Next

12.2. mosixview

12.2.1. Requirements for Mosixview

QT > 2.3.0 root rights ! rlogin and rsh (or ssh) to all cluster-nodes without password the MOSIX-tools mosctl, migrate, runon, iojob, cpujob ... (included in every MOSIX distribution)

12.2.2. Documentation on MOSIXVIEW

There is a full HTML-documentation on MOSIXVIEW included in every package (>=0.9). You find the startpage of the docu in your MOSIXVIEW installation directory in the following path: mosixview/mosixview/docs/en/index.html The RPM-packages have their installation directories in /usr/local/mosixview

12.2.3. Installation of the RPM-distribution

Download the latest version of MOSIXVIEW rpm-package for your linux-distribution Then just execute e.g.:
rpm -i mosixview-1.0.suse72.rpm
This will install the all binaries in /usr/bin To uninstall:
rpm -e mosixview
Installation of the source-distribution Download the latest version of MOSIXVIEW and unzip+untar the sources and copy the tarball to e.g. /usr/local/.
gunzip mosixview-1.0.tar.gz tar -xvf mosixview-1.0.tar
Automatic setup-script Just cd to the mosixview-directory and execute
./setup [your_qt_2.3.x_installation_directory]
Manual compiling Set the QTDIR-Variable to your actual QT-Distribution, e.g.
export QTDIR=/usr/lib/qt-2.3.0 (for bash) or setenv QTDIR /usr/lib/qt-2.3.0 (for csh)
Hints : (from the testers of mosixview who compiled it on diffrent linux-distributions, thanks again) Create the link /usr/lib/qt pointing to your QT-2.3.x installation e.g. if QT-2.3.x is installed in /usr/local/qt-2.3.0
ln -s /usr/local/qt-2.3.0 /usr/lib/qt
Then you have to set the QTDIR environment variable to
export QTDIR=/usr/lib/qt (for bash) or setenv QTDIR /usr/lib/qt (for csh)
There is no need to "make clean" and delete config.cache and Makefile because all versions >= 0.6 are already contains "cleaned" source-code. That means there are no precompiled binaries any more and (maybe) less problems to compile by yourself! // (If compiling fails because of not finding qwidget.h, qobject.h or any other header files you have to delete the files config.cache and Makefile and then configure+make. (happens on my RedHat-Cluster)) // After that the rest should work fine:
./configure make
then do the same in the subdirectory mosixcollector, mosixload and mosixview_client.
cd mosixcollector ./configure make cd .. cd mosixload ./configure make cd .. cd mosixmem ./configure make cd .. cd mosixhistory ./configure make cd .. cd mosixview_client ./configure make cd ..
Copy all binaries to /usr/bin
cp mosixview/mosixview /usr/bin cp mosixview_client/mosixview_client/mosixview_client /usr/bin cp mosixcollector/mosixcollector_daily_restart /usr/bin cp mosixcollector/mosixcollector/mosixcollector /usr/bin cp mosixload/mosixload/mosixload /usr/bin cp mosixload/mosixload/mosixmem /usr/bin cp mosixload/mosixload/mosixhistory /usr/bin
And the mosixcollector init-script to your init-directory e.g.
cp mosixcollector/mosixcollector.init /etc/init.d/mosixcollector or cp mosixcollector/mosixcollector.init /etc/rc.d/init.d/mosixcollector
Now copy the mosixview_client binary on each of your cluster-nodes to /usr/bin/mosixview_client
rcp mosixview_client/mosixview_client your_node:/usr/bin/mosixview_client
You can now execute mosixview (cd .. to quit the subdirectory mosixview_client)
./mosixview/mosixview
(do not use the & to force mosixview in the background!) If the "make install" fails just copy the mosixview binary wherever you want or create a symbolic link from /usr/bin/install (or wherever install is) to /usr/bin/ginstall and "make install" again.

12.2.4. the main window

This picture shows the main application-window of MOSIXVIEW. The function will be explained in the following HowTo. (Click to enlarge)

MOSIXVIEW reads the /etc/mosix.map at startup and builds a raw with a lamp, a button, a slider, a lcd-number two progressbars and a some labels for each cluster-member. The green lights at the left are displaying the MOSIX-Id and the status of the cluster-node. Red if down, green for avaiable. The status can set to autorefresh with the checkbox like the other dynamic objects. If you click on a button displaying an host-name (or ip) a configuration-dialog will pop up. It default shows the MOSIX-Name and some buttons to execute the most common used "mosctl"-commands. (described later in this HowTo) Use the "nslookup-checkbox" to get even hostname+ip in the config-dialog. Do not enable this option if your cluster-nodes only have ip-adresses and no hostnames in DNS! With the "speed-sliders" you can set the MOSIX-speed for each host. The current speed is displayed by the lcd-number. The load-balancing of the whole cluster can be influenced by this values. Processes in a MOSIX-Cluster are migrating easier to a node with more MOSIX-speed than to nodes with less speed. Sure it is not the physically speed you can set but it the speed MOSIX "thinks" a node has. e.g. a cpu-intensive job on a cluster-node which speed is set to the lowest value of the whole cluster processes will search for a better processor for running on and migrate away easily. The progressbars in the middle gives an overview of the load on each cluster-member. It displays in percent so it does not represent exactly the load written to the file /proc/mosix/nodes/x/load (by MOSIX), but it should give an overview. The next progressbar is for the used memory the nodes. I shows the currently used memory in percent from the avaiable memory on the hosts (the label to the right displays the avaiable mem). How many CPUs your cluster have is written in the box to the right. The last line of the main windows contains a configuration button for "all-nodes". You can configure all nodes in your cluster similar by this option. How good the load-balancing works is displayed by the progressbar in the last line. 100% is very good and means that all nodes nearly have the same load.

12.2.5. the configuration-window

This dialog will popup if an "cluster-node"-button is clicked. If your all cluster-members have DNS-hostnames the "nslookup"-option in the main-window can set to "enabled". The hostname and the ip-adress will be shown, otherwise only the MOSIX-name will be displayed. The MOSIX-configuration of each host can be changed easily now. All commands will be executed per "rsh" or "ssh" on the remote hosts (even on the local node) so "root" has to "rsh" (or "ssh") to each host in the cluster without prompting for a password (it is well described in a beowulf documentation or on the HowTo's on this page how to configure it). The commands are:
automigration on/off quiet yes/no bring/lstay yes/no exspel yes/no mosix start/stop

If the MOSIXVIEW-client is properly installed on the remote cluster-nodes click the "remote proc-box"-button to open the MOSIXVIEW-client (proc-box) from remote. xhost +hostname will be set and the display will point to your localhost. The client is executed on the remote also per "rsh" or "ssh". (the binary mosixview_client must be copied to e.g. /usr/bin on each host of the cluster) The MOSIXVIEW-client is a process-box for managing your programs. It is usefull to manage programs started and running local on the remote nodes. The client is also described later in this HowTo. If you are logged on your cluster from a remote workstation insert your local hostname in the edit-box below the "remote proc-box". Then the MOSIXVIEW-Client will be displayed on your workstation and not on the cluster-member you are logged on (maybe you have to set "xhost +clusternode" on your workstation). There is a history in the combo-box so you have to write the hostname only once.

12.2.6. the migrator-window

This dialog will popup if process from the processbox is clicked.

The MOSIXVIEW-migrator window displays all nodes in your MOSIX-cluster. This window is for managing one process (with additional status-information since version 0.7). By doubleclicking on an host from the list the process will migrate to this host. After a short moment the process-icon for the managed process will be green, which means it is running remote. The "home"-button sends the process to its home node. In this example the process already running local. With the "best"-button the process is send to the best avaiable node in your cluster. This migration is influenced by the load, speed, cpu's and what MOSIX "thinks" of each node. It maybe will migrate to the host with the most cpu's and/or the best speed. With the "kill"-button you can kill the process immediatly. To pause a program just click the "SIGSTOP"-button and to continue the "SIGCONT"-button. With the renice-slider below you can renice the current managed process (-20 means very fast, 0 normal and 20 very slow)

12.2.7. managing processes from remote

This dialog will popup if the "manage procs from remote"-button beneath the process-box is clicked This TabView displays processes that are migrated to the local host. The procs are coming from other nodes in your cluster and currently computed on the host mosixview is started on. Similar to the two buttons in the migrator-window the process is send home by the "goto home node"-button and send to the best avaiable node by the "goto best node"-button.

12.2.8. advanced-execution

If you want to start jobs on your cluster the "advanced execution"-dialog may help you.

Choose a program to start with the "run-prog" button (fileopen-icon) and you can specify how and where the job is started by this execution-dialog. There are several options to explain. the command-line You can specify additional commandline-arguments in the lineedit-widget on top of the window. how to start

-no migrationstart a local job which won't migrate
-run homestart a local job
-run onstart a job on the node you can choose with the "host-chooser"
-cpu jobstart a computation intensive job on a node (host-chooser)
-io jobstart a io intensive job on a node (host-chooser)
-no decaystart a job with no decay (host-chooser)
-slow decaystart a job with slow decay (host-chooser)
-fast decaystart a job with fast decay (host-chooser)
-parallelstart a job parallel on some or all node (special host-chooser)

12.2.9. the host-chooser

For all jobs you start non-local simple choose a host with the dial-widget. The MOSIX-id of the node is also displayed by a lcd-number. Then click execute to start the job. the parallel host-chooser You can set the first and last node with 2 spinboxes. Then the command will be executed an all nodes from the first node to the last node. You can also inverse this option.

12.2.10. the MOSIXVIEW-client

This process-box is really usefull for managing the processes running on your cluster. (MOSIXVIEW-client and the "local proc-box" are the same; you should install it on every cluster-node)

This processlist gives an overview what is running where. The second column displays the MOSIX-node ID of each process. 0 means local, all other values are remote nodes. Migrated processes are marked with a green icon and nonmoveable processes have a lock. By doubleclicking a process from the list the migrator-window will pop-up for managing e.g. migrating the process. If you click on the "manage procs from remote" button a new window will come up (the remote-procs windows) displaying the process currently migrated to this host. There are also options to send the remote processes away.

12.2.11. the MOSIXCOLLECTOR

The MOSIXCOLLECTOR is a daemon which should/could be started on one cluster-member. It logs the MOSIX-load of each node to the directory /tmp/mosixview/* These history log-files analyzed by MOSIXLOAD, MOSIXMEM and MOSIXHISTORY (as described later) gives an nonstop overview of the load, memory and processes in your cluster. There is one main log-file called /tmp/mosixview/mosix.load. Additional to this there are additional files in this directory to which the data is written. At startup MOSIXCOLLECTOR writes its PID (process id) to /tmp/mosixcollector.pid. It won't start if this file exist! The MOSIXCOLLECTOR-daemon restarts once a day (depending on when started) and saves the current history to /tmp/mosixview[date]/* These backups are done automatically but you can also trigger this manual. There is an option to write a checkpoint to the history. These checkpoints are graphically marked as a blue vertical line if you analyze the history log-files with MOSIXLOAD or MOSIXMEM. For example you can set a checkpoint when you start a job on your cluster and another one at the end.. Here is the explanation of the possible commandline-arguments:
mosixcollector -d//starts the collector as a daemon mosixcollector -k//stops the collector mosixcollector -c//stops the collector and deletes the history-files mosixcollector -n//writes a checkpoint to the history mosixcollector -r//saves the current history and starts a new one mosixcollector -help//print out a short help mosixcollector -h//print out a short help
You can start this daemon whith its init-script in /etc/init.d or /etc/rc.d/init.d. You just have to create a symbolic link to one of the runlevels for automatic startup. How to analyze the created logfiles is described in the following MOSIXLOAD-section.

12.2.12. MOSIXLOAD

This picture shows the graphical Log-Analyzer MOSIXLOAD

With MOSIXLOAD you can have a non-stop MOSIX-load history. The history log-files created by MOSIXCOLLECTOR are displayed in a graphically way so that you have a long-time overview what happened and happens on your cluster. MOSIXLOAD can analyze the current "online" logfiles but you can also open older backups of your MOSIXCOLLECTOR history logs by the filemenu. The logfiles are placed in /tmp/mosixview/* (the backups in /tmp/mosixview[date]/*) and you have to open only the main history file "mosix.load" to take a look at older load-informations. (the [date] in the backup directories for the log-files is the date the history is saved) The start time is displayed on the top/left and you have a full-day view in MOSIXLOAD (24 h). If you are using MOSIXLOAD for looking at "online"-logfiles (current history) you can enable the "refresh"-checkbox and the view will auto-refresh (or use the manual refresh-button). The load-lines are normally black if the load of one node is smaller 50. If the load increases to >50 the lines are drawn yellow and red if load is higher 80. These values are MOSIX-informations. MOSIXLOAD gets these informations from the files /proc/mosix/nodes/[mosix ID]/load. The X-button of each nodes calculates the nodes avarage MOSIX-load. Clicking it will open a small new window in which you get the avarage load-value and a graphic which displays it coloured (black ok, yellow critique, red alert). If there are checkpoints written to the load-history by the MOSIXCOLLECTOR they are displayed as a vertical blue line. You now can compare the load values at a certain moment much easier.

12.2.13. MOSIXMEM

This picture shows the graphical Log-Analyzer MOSIXMEM

With MOSIXMEM you can have a non-stop memory history similar to MOSIXLOAD. The history log-files created by MOSIXCOLLECTOR are displayed in a graphically way so that you have a long-time overview what happened and happens on your cluster. MOSIXMEM can analyze the current "online" logfiles but you can also open older backups of your MOSIXCOLLECTOR history logs by the filemenu. The logfiles are placed in /tmp/mosixview/* (the backups in /tmp/mosixview[date]/*) and you have to open only the main history file "mosix.load" to take a look at older load-informations. (the [date] in the backup directories for the log-files is the date the history is saved) The start time is displayed on the top/left and you have a full-day view in MOSIXMEM (24 h). If you are using MOSIXMEM for looking at "online"-logfiles (current history) you can enable the "refresh"-checkbox and the view will auto-refresh (or use the manual refresh-button). The displayed values are MOSIX-informations. MOSIXMEM gets these informations from the files

/proc/mosix/nodes/[mosix ID]/mem.
/proc/mosix/nodes/[mosix ID]/rmem.
/proc/mosix/nodes/[mosix ID]/tmem.

The X-button of each nodes calculates the nodes avarage MOSIX-mem. Clicking it will open a small new window in which you get the avarage mem-value. If there are checkpoints written to the load-history by the MOSIXCOLLECTOR they are displayed as a vertical blue line. You now can compare the load values at a certain moment much easier.

12.2.14. MosixHistory

MOSIXHISTORY displays the processlist from the past MOSIXHISTORY gives a detailed overview which process was running on which node. The MOSIXCOLLECTOR saves the processlist from the host the collector was started on every minute and you can browse this log-data with MOSIXHISTORY. You can easy change the browsing time in MOSIXHISTORY by the time-slider. The rest is nearly similar to MOSIXLOAD and MOSIXMEM. MOSIXHISTORY can analyze the current "online" logfiles but you can also open older backups of your MOSIXCOLLECTOR history logs by the filemenu. The logfiles are placed in /tmp/mosixview/* (the backups in /tmp/mosixview[date]/*) and you have to open only the main history file "mosix.load" to take a look at older load-informations. (the [date] in the backup directories for the log-files is the date the history is saved) The start time is displayed on the top/left and you have a full-day view in MOSIXHISTORY (24 h).

Prev	Home	Next
mexec	Up	mpi