Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
KS_LK_AllInOne.docx
Скачиваний:
175
Добавлен:
23.11.2019
Размер:
28.78 Mб
Скачать

4. 6.2.2 Окно migrator. Этот диалог появляется, если кликнуть на каком-либо процессе из окна списка процессов.

Рисунок 4.5 – Окно migrator

Окно openMosixview-migrator отображает все узлы вашего кластера, но предназначен для управления лишь одним процессом. Двойным щелчком на хосте из списка можно заставить процесс мигрировать на этот хост. После этого иконка выбранного процесса сменится на зелёную, означая, что процесс выполняется на удалённой машине.

Кнопка home позволяет отправить процесс на его UHN. В свою очередь, кнопкой best процесс можно отправить на наилучший из доступных узлов кластера. В целом, процесс миграции зависит от нагрузки, скорости, процессоров и того, что openMosix “думает” о каждом узле. Наиболее вероятно, что процесс мигрирует на хост с наиболее мощным процессором и значением скорости. Кнопка kill позволяет моментально уничтожить доступный процесс.

Чтобы временно остановить выполнение программы, просто нажмите кнопку SIGSTOP”, а чтобы затем продолжить – нажмите SIGCONT”. Ползунком, расположенным ниже, вы можете манипулировать приоритетом выбранного процесса (-20 значит очень высокий, 0 – нормально, а 20 – очень низкий).

4. 6.2.3 Управление удалёнными процессами. Этот диалог появляется при нажатии кнопки “manage procs from remote”

Рисунок 4.6 – Окно управления удаленными процессами

Здесь TabView отображает процессы, мигрировавшие на данный хост – т.е. процессы, пришедшие с других узлов кластера и выполняющиеся на машине, на которой запущен openMosixView. Точно также, как и в случае с окном migrator, процесс можно отправить на UHN кнопкой goto home node или на наилучший из доступных узлов кластера (кнопка goto best node).

4.5.3 Использование openMosixcollector

openMosixcollector – это демон, который может быть запущен на любом из узлов кластера. Он журналирует нагрузку openMosix в каталог /tmp/openmosixcollector/*. Затем эти журналы анализируются программой openMosixanalyzer (будет описан далее), что в результате даёт представление о нагрузке, использовании памяти и процессах кластера. Основным журналом является файл /tmp/openmosixcollector/cluster. Помимо него в этом каталоге создаются и другие файлы.

При запуске openMosixcollector записывает свой PID (process id) в файл /var/run/openMosixcollector.pid.

Демон openMosixcollector рестартует каждые 12 часов и сохраняет накопленную историю в файл вида /tmp/openmosixcollector[date]/*. Такие резервные копии создаются автоматически, хотя их можно создавать и вручную.

Существует также возможность записать контрольную точку в историю. В openMosixanalyzer такие контрольные точки обозначаются на графике вертикальной синей линией. К примеру, вы можете создать контрольную точку при запуске задачи на кластере и по окончании этого задания.

Вот расшифровка возможных аргументов командной строки:

openmosixcollector -d // запускает коллектор в виде демона

openmosixcollector -k // останавливает коллектор

openmosixcollector -n // записывает контрольную точку в историю

openmosixcollector -r // сохраняет накопленную историю и начинает новую

openmosixcollector // выводит небольшую подсказку

Этот демон можно стартовать и в виде init-скрипта в /etc/init.d или /etc/rc.d/init.d. Нужно просто создать символическую ссылку в соответствующем уровне выполнения для его автозапуска.

О том, как анализировать созданные файлы журналов, рассказывается в разделе про openMosixanalyzer далее

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]