ここ何年もうちの部隊最大の懸案事項となっていたのが、録画用マシン「ユリア」の後継機増設である。
ユリアはCore 2 Quad 6600のPCで、この夏で13年の稼働になる。しかも、ほぼ24時間×365日×13の稼働だったのだ!!!!寿命のないPCなどあるはずはない。本来想定すべき稼働限界など、石器時代ほど昔に過ぎている。
工場で機械を制御するようなPCで、何十年も稼働を続けていて移行もできないものがあるということを聞いたことがある。もはやそのような世界に片足を突っ込んでいる。
もともと5月の連休は録画予定に空きができやすいところ、緊急事態宣言中で自宅にこもっているしかない。言い換えれば後継機構築の最大かつ最後のチャンスだ。本番予定日と予備日で合計24時間の作業時間を確保したものの、これでも完了するか自信はなかった。
ところが実際のところ、最低限ケーブルをつないで録画できるところまでは5時間くらいで終わった。当初とてつもなく苦労したのはチャンネルの設定である。再三チャンネルが消えたり表示が変になったりした。現状動いている設定をコピーしてくることができたので大幅に時間が短くなった。
新型コロナウイルス解析のプロジェクトが開始されて以来、Folding@home(本記事ではF@Hと略す)の参加者が増えすぎ、課題不足で待たされることが多い。直近ではましになっているものの、新型コロナウイルス解析が始まった3月いっぱいと4月中旬は、本当にひどかった。
F@Hのクライアントは、課題不足で取得に失敗が続いた場合、リトライの待ち時間が倍々ペースで長くなっていく。(それ以外の原因の場合でも同様)これが大問題で、初回のリトライは1分後だが、10回も連続で失敗したら1時間といった待ち時間になる。仕事中か寝ている間、人間が監視できない時間は、全く課題を取得できず、マシンが遊んでいるという事態が多発する。
ここで、F@Hのスロットの停止・再開をすると、この待ち時間がリセットされて、また1分前後の待ち時間から再開できる。
マスクの争奪戦にも似たような状況である。課題は常時少しずつ入荷している。しかし課題が不足している状況には変わりなく、入荷したら、待ち構えている猛者たちにすぐに全部持っていかれる。漠然と動かしているだけでは、いつまでたっても課題を入手できない。
そこで、何らかの方法で課題取得待ちを判定して、待ち状態なら上記のタイマーのリセットをするようなことができないかと漠然と考えていた。するとすでに同じことを考えた人がいた。
Folding@homeでWorkUnitを得られずにシステムリソースを遊ばせてしまう状態を回避する
F@HにはFAHClient APIがあり、Telnetで接続してAPIをたたくことができる(デフォルトでポートは36330)。このAPIを使えば、各スロットの状態を把握、上記の停止・再開もできる。
上の記事の方はrequest-wsを投げてその結果をexpectを使って判定しているが、queue-infoを使ってqueueの状態を取得・解析すれば、待ち状態をより的確に判定できそうだ。大筋では以下のような感じだ。
queue-infoを使うと、advanced controlの画面でWork Queueの情報として見られるものがすべて得られる。Work Queueの情報から、StatusがDownloadかつNext Attemptがある程度以上なら、待ち状態と判定できる!さて、Next Attemptの時間の表記は、1分未満ならSS secs、1分以上1時間未満ならMI mins SS secs、1時間以上ならHH hours MI minsという感じ。まともに解析するのは極めて難しそうだ。'min'を含んでいれば1分以上とみなしてスロット停止・再開するという、荒っぽい判定にする。
Telnetの自動実行は、echoでTelnetに食わせたいコマンドを出力して、Telnetにリダイレクトすればよい。まるでコロンブスの卵だ。(続けてコマンドを実行させる場合は、間に適切にスリープを入れる。)
そしてこれをcronで一定間隔で実行する。
ここまでわかれば実装は難しくはない。
これで、ようやく枕を高くして寝ることができる。
課題待ちのときにpause→unpauseするシェルスクリプト(fahcheck.sh)
課題待ちを判定するpythonスクリプト(fahqueue.py)
F@Hのクライアントは、課題不足で取得に失敗が続いた場合、リトライの待ち時間が倍々ペースで長くなっていく。(それ以外の原因の場合でも同様)これが大問題で、初回のリトライは1分後だが、10回も連続で失敗したら1時間といった待ち時間になる。仕事中か寝ている間、人間が監視できない時間は、全く課題を取得できず、マシンが遊んでいるという事態が多発する。
ここで、F@Hのスロットの停止・再開をすると、この待ち時間がリセットされて、また1分前後の待ち時間から再開できる。
マスクの争奪戦にも似たような状況である。課題は常時少しずつ入荷している。しかし課題が不足している状況には変わりなく、入荷したら、待ち構えている猛者たちにすぐに全部持っていかれる。漠然と動かしているだけでは、いつまでたっても課題を入手できない。
そこで、何らかの方法で課題取得待ちを判定して、待ち状態なら上記のタイマーのリセットをするようなことができないかと漠然と考えていた。するとすでに同じことを考えた人がいた。
Folding@homeでWorkUnitを得られずにシステムリソースを遊ばせてしまう状態を回避する
F@HにはFAHClient APIがあり、Telnetで接続してAPIをたたくことができる(デフォルトでポートは36330)。このAPIを使えば、各スロットの状態を把握、上記の停止・再開もできる。
上の記事の方はrequest-wsを投げてその結果をexpectを使って判定しているが、queue-infoを使ってqueueの状態を取得・解析すれば、待ち状態をより的確に判定できそうだ。大筋では以下のような感じだ。
- Telnetでqueue-infoを取得しファイルにリダイレクト
- queue-infoを解析して、対象スロットが課題取得待ちかどうかを判定
- 課題取得待ち状態のスロットに対して、Telnetでpause→unpause実行
queue-infoを使うと、advanced controlの画面でWork Queueの情報として見られるものがすべて得られる。Work Queueの情報から、StatusがDownloadかつNext Attemptがある程度以上なら、待ち状態と判定できる!さて、Next Attemptの時間の表記は、1分未満ならSS secs、1分以上1時間未満ならMI mins SS secs、1時間以上ならHH hours MI minsという感じ。まともに解析するのは極めて難しそうだ。'min'を含んでいれば1分以上とみなしてスロット停止・再開するという、荒っぽい判定にする。
Telnetの自動実行は、echoでTelnetに食わせたいコマンドを出力して、Telnetにリダイレクトすればよい。まるでコロンブスの卵だ。(続けてコマンドを実行させる場合は、間に適切にスリープを入れる。)
そしてこれをcronで一定間隔で実行する。
ここまでわかれば実装は難しくはない。
これで、ようやく枕を高くして寝ることができる。
課題待ちのときにpause→unpauseするシェルスクリプト(fahcheck.sh)
#!/bin/bash # if FAHClient is not running, do nothing ps aux | grep FAH | grep -v grep > /dev/null 2>&1 if [ $? -ne 0 ]; then exit 0 fi # get queue info ( echo "open localhost 36330"; sleep 1; echo "queue-info"; sleep 1; echo "quit" ) | telnet > fahqueue.log # analyze queue info for slot 00 /usr/bin/python3 fahqueue.py 00 # pause and unpause if slot 00 is waiting if [ $? -ne 0 ]; then echo 'request a WU for slot 00' ( echo "open localhost 36330"; sleep 1; echo "pause 00"; sleep 10; echo "unpause 00"; sleep 1; echo "quit" ) | telnet else echo 'slot 00 is working' fi # analyze queue info for slot 01 /usr/bin/python3 fahqueue.py 01 # pause and unpause if slot 01 is waiting if [ $? -ne 0 ]; then echo 'request a WU for slot 01' ( echo "open localhost 36330"; sleep 1; echo "pause 01"; sleep 10; echo "unpause 01"; sleep 1; echo "quit" ) | telnet else echo 'slot 01 is working' fi
課題待ちを判定するpythonスクリプト(fahqueue.py)
#!/usr/bin/python3 import json import sys path = '/home/yourname/fahqueue.log' queueinf = '' skip = True with open(path) as f: for s_line in f: if s_line.startswith('['): skip = False if s_line.startswith(']'): queueinf += ']' skip = True if skip: continue queueinf += s_line print(queueinf) args = sys.argv slot = args[1] queue = json.loads(queueinf) request = True for work in queue: print(work['id']) if work['slot'] != slot: continue if work['state'] == 'RUNNING': print('running') request = False break if work['state'] == 'DOWNLOAD' and 'min' not in work['nextattempt']: print('retry soon') request = False break print(request) if request: sys.exit(1) else: sys.exit(0)
LXDE環境でさらに予想外のトラブルに遭遇した。
マウスカーソルが消える。
前もって断っておくと、筆者固有の、二重の意味で特殊な環境で発生したことであり、ほかに出くわした人がいるかどうかも定かではない。
Ubuntu系統のLinuxでマウスカーソルが消える現象は、検索してみると例はある。14.04~16.04あたりまで事例が多いようで、18.04の例はあまりなさそうだ。検索されたどの対処方法も、筆者の環境では役に立たなかった。
筆者の環境では4K解像度のディスプレイを使っているが、解像度をフルHDにして使っている。というのは、4KディスプレイをフルHD4面に分割して(これはディスプレイの機能)1台につき1面を使い、最大4台の画面を同時に表示させている。
LXDE環境でも当然画面解像度をフルHDに設定した。
すると、表示される範囲は確かにフルHDになるものの、4Kの画面があると思われているようなのだ。つまり、マウスカーソルは消えるというより画面外に飛んでいる。ただし、一度消えるとどのように動かしても戻ってこない。ウィンドウも画面の端に現れることがあり変だと思ったところから、およその見当はついた。
とすれば有効な対処は一つだけで、4K解像度のままで使い続けることだ。本来フルHD21インチの領域に4K表示、LXDEという軽量さが身上の環境にディスプレイスケールなどというしゃれた機能があるはずもなく、見づらい。それでもマウスカーソルが消えたら全く使えないので、何とか使える状態ではある。
ところで、同じディスプレイでLXDEを別PCにインストールしたことはあり、その時にはこのようなトラブルはなかった。そのPCの環境との違いは、やはりGPUを2枚さしているか1枚だけかである。すなわち本件の教訓は
マウスカーソルが消える。
前もって断っておくと、筆者固有の、二重の意味で特殊な環境で発生したことであり、ほかに出くわした人がいるかどうかも定かではない。
Ubuntu系統のLinuxでマウスカーソルが消える現象は、検索してみると例はある。14.04~16.04あたりまで事例が多いようで、18.04の例はあまりなさそうだ。検索されたどの対処方法も、筆者の環境では役に立たなかった。
筆者の環境では4K解像度のディスプレイを使っているが、解像度をフルHDにして使っている。というのは、4KディスプレイをフルHD4面に分割して(これはディスプレイの機能)1台につき1面を使い、最大4台の画面を同時に表示させている。
LXDE環境でも当然画面解像度をフルHDに設定した。
すると、表示される範囲は確かにフルHDになるものの、4Kの画面があると思われているようなのだ。つまり、マウスカーソルは消えるというより画面外に飛んでいる。ただし、一度消えるとどのように動かしても戻ってこない。ウィンドウも画面の端に現れることがあり変だと思ったところから、およその見当はついた。
とすれば有効な対処は一つだけで、4K解像度のままで使い続けることだ。本来フルHD21インチの領域に4K表示、LXDEという軽量さが身上の環境にディスプレイスケールなどというしゃれた機能があるはずもなく、見づらい。それでもマウスカーソルが消えたら全く使えないので、何とか使える状態ではある。
ところで、同じディスプレイでLXDEを別PCにインストールしたことはあり、その時にはこのようなトラブルはなかった。そのPCの環境との違いは、やはりGPUを2枚さしているか1枚だけかである。すなわち本件の教訓は
- デスクトップ環境を使う以上、ディスプレイも含めて調査・検証機と本番機が同じ環境の必要がある
- 本番機がGPU2枚であるから、調査・検証機もGPU2枚の必要がある