What's New Qiita

20200619のLinuxに関する記事は4件です。

  • 投稿日：2020-06-19T23:48:10+09:00

xCATでスパコンを作ろう

xCATでBeowulf

世はクラウドである。が、用途によっては手元でガンガン計算機を動かしたいことはある。というか自分の目の前でコンピューターにうなりを上げさせてこそのスーパーコンピューティングなのである。こういう用途に使うのが高性能計算クラスター（High Performance Computing [HPC] Cluster)である。HPCクラスターを実現する方式の一つが（最近あまり聞かない用語であるが）Beowulf である。Beowulfは「フリーUnixベースで、計算専用に用意したノード群を高速ネットワークで接続して実現したHPCクラスター」といったような意味で、この定義であれば、筆者のなじみの深いバイオインフォマティクス界隈の「スパコン」のほとんどがBeowulfであろう。

ここで、バイオインフォマティクス業界でなぜオンプレミスのHPC環境が（いまだ）必要かをもうちょっと詳しく。

第一に、次世代シークエンサーデータ関連の仕事を念頭においた話なのですが、いわゆるembarrassingly parallel1な計算が多いということがある。何も考えず入力を10等分するだけで計算時間が1/10になることが期待できるわけです。このためBeowulf式のHPCクラスタの恩恵を受けやすいこと。第二に、計算速度には寛容でCPUパワーが少なくても待てばいい仕事が多いのに入力データサイズが巨大なためストレージもネットワーク転送量も大きくなりがちなこと。これは、安いCPU代金と高いストレージ・ネットワーク転送量で成り立つクラウド環境とはまったく相性が悪いのである。そして、最悪生データから計算しなおせばいいという特性から、ストレージに絶対の信頼性やら高速アクセス性能など要求しないこと。安くてでかいストレージが必要なのである。第三に、ヒト関連の研究でのプライバシー関連の問題。状況は変わりつつありますが、組織外部や国外にデータを保持することはまだ敷居が高かったりする。このようなわけで、バイオインフォマティクス業界で、オンプレミスのHPCクラスタを持つ（場合によっては自作する）という選択は、2020年でもそれほど間違ったものではないだろう。

さて、オンプレミスのBeowulf型自作HPCクラスターの構築を実現するためにいくつかのソフトウェアパッケージがあるのだが、比較的最新のLinuxディストロをベースにした自由度の高いオープンソースプロダクツで、現在も活発に開発されているものというと、IBMがスポンサーになっているプロジェクトであるeXtreme Cloud Administration Kit (xCAT) https://xcat.org/ が一番有名かなと思われる。

著者は、数年前にxCATでHPCを自作したことがあるが、最近、古いScyld（Penguin Computing社のプロプライエタリなHPCシステム）を新しいxCATで復活させることが必要になったので、あらためてメモ代わりに本稿を書くことにした次第である。xCATのドキュメントは、以前よりは改善したものの、まだ難しい。全部読んで理解してからインストール開始しないとハマりがちな構成になっているような気がする。必要な情報が分散してたり、暗黙に設定を行う高レベルのコマンドと、低レベルのコマンドが衝突したりがあるので一筋縄ではいかない。本稿は、ドキュメントと格闘した試行錯誤の結果なので、ウソや勘違いも多分にありそうだ。とはいえ、こういったメモも参考程度になら意味があるだろう。

xCATは、RedHat/CentOSでも、PowerPCベースのLinuxでも（サポートしていれば）自由に選ぶことができる。筆者のバイオインフォマティクス関連の仕事の場合、「サーバー」といっても時に比較的新しい環境をと要求するオープンソースソフトウェアをソースからビルドする必要があるため、比較的あたらしいUbuntuを使う事にした。プロプライエタリなツールがメインの場合はCentOSベースのほうがより適切かもしれない。

xCATをインストールする

参照URI

ハードウェアとネットワーク

  • Management Node
    • 内部ネットワーク用 NIC 10.54.0.0/16 スイッチングハブに接続
    • WAN用 NIC 192.168.0.0/16 WAN/インターネット側に接続
  • Compute Node（10台）
    • 内部ネットワーク用 NIC 10.54.0.0/16 スイッチングハブに接続
    • BMC/IPMI こちらもスイッチングハブに接続
  • 1000Gbスイッチングハブ

Management Nodeを設定する

xCATがサポートしている最新版Ubuntuということで、Ubuntu 18.04-4 LTSを通法に従いインストールした。だたし実際には最軽量UIを目的に派生版であるLubuntu 18.04-4をインストールした。後述するが、compute node群には、Ubuntu Server 18.04-2を使う必要があった。

今回対象としたマシンの場合、Lubuntuインスートーラー上でマウスカーソルだけ表示されないという症状が出るも、カーネルオプションにnomodesetを指定することで回避できた。Intelグラフィックス機能の無効化らしい。インストール後は、ホスト名設定(scyld.cluster)、WAN側の固定IPアドレスの割り当て、NTP設定、apt upgrade、最小限のユーザー／グループ設定などを済ませる。

xCAT安定版のインストール

sudo su -してから作業開始。
執筆時点での安定版最新版xCAT 2.15.1 (2020年3月6日リリース)を使う。 

# mkdir /root/xCATsetup #特にことわらなければ、すべてここで作業することにする
# cd /root/xCATsetup
# wget \
  https://raw.githubusercontent.com/xcat2/xcat-core/master/xCAT-server/share/xcat/tools/go-xcat \
  -O - >　/tmp/go-xcat
# chmod +x /tmp/go-xcat
# /tmp/go-xcat install            # 今回はxcat安定バージョンをインストール

xCATシステムのデフォルトのインストール先は/opt/xcat。

インストールの検証

# source /etc/profile.d/xcat.sh # PATH設定
# lsxcatd -a # xCATバージョン表示
Version 2.15.1 (git commit ab6295bdc1deb1827922d47755bfc68adec12389, built Wed Mar  4 16:45:39 EST 2020)
This is a Management Node
dbengine=SQLite

# tabdump site　# xCAT内部データベースのsiteテーブルを表示する
#key,value,comments,disable
"blademaxp","64",,
"fsptimeout","0",,
"installdir","/install",,
（以下略）

xCATの設定は、xCAT objectと、xCAT databaseの2つの概念で管理されている。前者は、mkdef, lsdef, chdef, rmdefなどのコマンドで操作する。後者は、tabdump, tabedit, chtabなどのコマンドで操作する。xCAT databaseは実際にはRDB（デフォルトではSQLite）で管理されるテーブルで、オブジェクト群とテーブル群は多対多の関連付けになっているようである。設定の場面に応じて、都合の良いまとめ方で、前者か後者を操作するみたいである。

site objectの設定

Set attributes in the site tableに準じて設定を進める。

# chdef -t site domain="cluster"          # ノード群のドメイン名 scyld.clusterなどの場合
# chdef -t site forwarders="10.54.0.1"    # Compute Node群から見たdefault gateway
# chdef -t site master="10.54.0.1"        # Compute Node群から見たManagement NodeのIPアドレス
# chdef -t site nameservers="10.54.0.1"　 # Compute Node群から見たカンマ区切りでDNS群IPアドレス
# makedns -s                # Management Nodeで動くDNSのイニシャライズ。IPv6関連のwarningが出るが無視。
# nslookup scyld.cluster    # DNS動作確認

networks table の設定

Set attributes in the networks tableに従ってネットワークに関する設定を進める。まずは自動設定を確認。

# tabdump networks
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,mtu,comments,disable
"10_0_0_0-255_255_0_0","10.0.0.0","255.255.0.0","bond0","<xcatmaster>",,"<xcatmaster>",,,,,,,,,,,"1500",,
"192_168_0_0-255_255_0_0","192.168.0.0","255.255.0.0","enp1s0f1","192.168.0.1",,"<xcatmaster>",,,,,,,,,,,"1500",,

今回はDHCPでboot直後のcomputer Node群を、内部ネットワークの10.54.3.1から10.54.3.254の範囲にDHCPを使って割り当てたい。また内部ネットワークは、事前に設定しておいたbond0（ethernet bonding/aggregationを使用）に接続されている。そこで以下のように設定＋DHCPサービス開始をする。

まず、networks tableのnetname（オブジェクト名）が長すぎるので、tabedit network起動されるエディタ上で以下のように修正する。

# tabdump networks
#netname,net,mask,mgtifname,gateway,dhcpserver,tftpserver,nameservers,ntpservers,logservers,dynamicrange,staticrange,staticrangeincrement,nodehostname,ddnsdomain,vlanid,domain,mtu,comments,disable
"clusternet","10.54.0.0","255.255.0.0","bond0","<xcatmaster>",,"<xcatmaster>",,,,,,,,,,,"1500",,
"wan","192.168.0.0","255.255.0.0","enp1s0f1","192.168.0.1",,"<xcatmaster>",,,,,,,,,,,"1500",,

# makehosts -n

これでオブジェクト名をclusternetとwanで参照できる。そして、オブジェクトタイプnetwork、オブジェクト名clusternetを修正する。DHCPが10.54.3.1から10.54.3.254を配布するように設定。

# chdef -t network -o clusternet dynamicrange="10.54.3.1-10.54.3.254"
# makedhcp -n

passwd table の設定

rootアカウントのパスワードを設定

# tabdump passwd
# chtab key=system passwd.username=root passwd.password=root
# chtab ip

Compute Node群の認識と設定

Docs » Admin Guide » Manage Clusters » IBM POWER LE / OpenPOWER以下の記述に従って作業を進める。xCATプロジェクトはIBMの支援を受けている都合、ドキュメントではPowerPCベースIBMマシンを使った説明が記述されているが、ほとんどのユーザーの環境であるLinux on x86_64環境でも作業はほぼ同じである。

まず、Hardware Discovery & Define Nodeを参照。方法の選択肢は手動設定と、自動設定としてMTMS（Machine Type and MAchene Serial）による認識、スイッチングハブへの接続ポート番号による認識、順序依存の認識がある。

今回はcompute node数が10なので、ドキュメントのお勧めに従い、MTMSによる認証を選んでみる。推奨は「BMC/IPMI IPアドレスは、まずDCHP割り当てを受けて、後に別サブネットの静的IPアドレスを設定する」という方法。普通は、BMC/IPMIがDHCPから動的にIPアドレスを得ることが多いかもしれない。ただ筆者の環境では、あらかじめBMC/IPMIの静的IPアドレスを10.54.0.1-10に設定であったので、ドキュメントと少々違うがこれをそのまま使う事にする。

※BMC/IPMI: Intellinget Platform Management Interface (IPMI)のためのマイコンチップがBaseboard Management Controller (BMC)だが、xCATでは用語が混在している。

# bmcdiscover --range 10.54.0.1-254 -u ADMIN -p ADMIN -z -w
# bmcdiscover --range 10.54.0.1-254 -u adimn -p admin -z -w
Writing node-0025901d9c29 (10.54.150.10,Winbond,,admin,admin,mp,bmc,0025901d9c29,,) to database...
node-0025901d9c29:
        objtype=node
        groups=all
        bmc=10.54.150.10
        cons=ipmi
        mgt=ipmi
        mtm=Winbond
        bmcusername=admin
        bmcpassword=admin
（中略）
# lsdef /node-.*
Object name: node-0025901d8c1e
    bmc=10.54.150.3
    bmcpassword=admin
    bmcusername=admin
（中略）

bmcdiscoverはデフォルトでは、passwdテーブルのkey=ipmiの参照するのだが、一部のマシンでは、User/Passwordの組み合わせが違ったり複数あったりいろいろあったので（2020年以降のマシンでは個体ごとに違ったりするようである）、別の組み合わせでbmcdiscoverを2回発行した。ともかくすべてのマシンのBMC/IPMIを認識してxCAT内部データベースに書き込めたようだ。こうやって作った情報をもとに各マシンの静的な設定ファイルを作る。

# bmcdiscover --range 10.54.0.1-254 -u ADMIN -p ADMIN -z > predefined.stanza
# bmcdiscover --range 10.54.0.1-254 -u adimn -p admin -z >> predefined.stanza

エディタでpredefined.stanzaを編集する。

node-0025901d9e23:
        objtype=node
        groups=all
        bmc=10.54.150.1
        cons=ipmi
        mgt=ipmi
        mtm=Winbond
        bmcusername=admin
        bmcpassword=admin

を

cn02:
        ip=10.54.2.2
        netboot=xnba
        mac=XX:YY:ZZ:XX:YY:ZZ
        objtype=node
        groups=compute2,all
        chain="runcmd=bmcsetup"
        bmc=10.54.150.1
        cons=ipmi
        mgt=ipmi
        mtm=Winbond
        bmcusername=admin
        bmcpassword=admin

のように、各compute-nodeについて変更する。ip=10.54.2.2はこのcomputeノードの静的IPアドレスである。これらをまとめて内部データベース似書き込む。ただ筆者の場合、うまく製造番号（serial）情報がとりこめなかった。（IPMIではなく)NICのMACアドレスも手動で書き込んだ。groups=compute2,allおよびchain="runcmd=bmcsetup"も追加した。これで、compute node全体をcompute2で参照することができる。筆者は別のxCATを運用中なのでここは「2」をつけている。

# cat predefined.stanzas | mkdef -z

変更があった時は、mkdef -f -zとすることで設定を上書きできる。

rpower compute2 statusでcompute nodeすべての電源状態が表示できればOK。

# tabedit hosts #以下のようにエディタで編集
# tabdump hosts
#node,ip,hostnames,otherinterfaces,comments,disable
"compute2","|\D+(\d+)|10.54.2.($1+0)|",,"|\D+(\d+)|cn($1)-ipmi:10.54.150.($1+0)|",,

Compute Node群でのOSブート方法の選択

Compute Node群にOSを送り込むには、

  1. Diskful Installation
  2. Diskless Installation (Stateless Installation) の２つの方法がある。前者は、各Compute NodeローカルのストレージにOSをインストールしてそこから起動する方法。後者は起動の度にOSイメージ（"netboot" osimage）をCompute Node群に送り込み、その後に起動する。後者であっても各Compute Nodeに接続されたローカルストレージに（たとえばテンポラリディレクトリや頻回アクセスファイルなどを置いて）アクセスすることはできる。この意味ではStatelessといったほうがより正しいかもしれない。

ネットワーク構成が十分な帯域があって、各Compute Nodeに十分なメモリがあるのならば、すべてをManagement Nodeから一括で扱えるiskless Installationが第一選択だろう。

OSイメージの作成

現バージョンのxCATがサポートするOSは、ls -L/opt/xcat/netboot/*/*.pkglistで出てくるパッケージリストに含まれる必要があるようである。Ubuntuならls -L /opt/xcat/netboot/ubuntu/*.pkglistでみてみると、18.04と18.04-2がサポートされているようである。また、Lubuntuのisoファイルも上手く認識してくれないようなので、ここはおとなしくunbuntu-18.04.2-server.amd64.isoダウンロードしてしてから、osimageを作成する。

# mkdir -p /install/iso
# cd /install/iso
# wget http://releases.ubuntu.com/18.04.2/ubuntu-18.04.2-server-amd64.iso
# copycds ubuntu-18.04.2-server-amd64.iso
# lsdef -t osimage
ubuntu18.04.2-x86_64-install-compute  (osimage)
ubuntu18.04.2-x86_64-install-service  (osimage)
ubuntu18.04.2-x86_64-netboot-compute  (osimage)

ubuntu18.04.2-x86_64-netboot-computeがDiskless installationのためのOSイメージである。このOSイメージに目的に応じたのパッケージ追加などの修正を加えることができる。今回はこうした必要な変更はOSブート後のシェルスクリプト（postscript）で行うことにして先に進む。

# genimage ubuntu18.04.2-x86_64-netboot-compute　# しばらく時間がかかる
# packimage ubuntu18.04.2-x86_64-netboot-compute
# mknb x86_64

最後のmknbコマンドだが、手動での起動は不要のようにも読めるが、これを実行しないとcompute nodeが起動後に最初に読みに行く/tftpboot/xcat/xnba/nets/10.54.0.0_16（および*.elilo, *.uefi)がうまく生成されないようである。

compute node群にOSイメージを設定

# chdef compute2 -p chain="bmcsetup,osimage=ubuntu18.04.2-x86_64-netboot-compute"
# makehosts -n compute2
# makedns -s ; makedhcp -n ; makedhcp -a
# rpower compute2 boot

makedns -s ; makedhcp -n ; makedhcp -aはcompute node起動前に実行し直した方が無難。さて、これでssh cn01でログインできるようならば難の問題もないのだけれど、筆者の環境ではどうもうまくいかなかった。

トラブルシューティング

デバッグ目的に、compute node群のリモートコンソールも使えるようにしておく。makegoconsで設定し、rcons <node>で起動する。rconsの終了は、ctrl-eの後にc.である。

# makegocons 
Starting goconserver service ...
cn10: Created
cn01: Created
（中略）
cn06: Created

# rcons cn01
[Enter `^Ec?' for help]
goconserver(2020-06-19T09:47:14+09:00): Hello 192.168.0.21:41898, welcome to the session of cn01

compute nodeが、getdestinyがらみでとまってしまう場合、たとえばsyslogで

Jun 18 17:10:50 10.54.3.2 [localhost] xcat.genesis.doxcat: Getting initial certificate --> 10.54.0.1:3001
Jun 18 17:11:00 10.54.3.2 [localhost] xcat.genesis.doxcat: Running getdestiny --> 10.54.0.1:3001
Jun 18 17:11:10 10.54.3.2 [localhost] xcat.genesis.doxcat: Received destiny=
Jun 18 17:11:10 10.54.3.2 [localhost] xcat.genesis.doxcat: The destiny=, destiny parameters=
Jun 18 17:11:10 10.54.3.2 [localhost] xcat.genesis.doxcat: Unrecognized directive (dest=)
Jun 18 17:11:19 10.54.3.2 [localhost] xcat.genesis.doxcat: ... Will retry xCAT in 70 seconds

などで先に進まない場合、dhcpやdnsの設定ミスがないか再確認すると解決するかもしれない。tabedit siteなどで入力ミスがないか確認して、makedns -s ; makedhcp -n ; makedhcp -a ; rpower compute2 boot。

また、Compute Nodeが、cat predefined.stanza | mkdef -zで設定した（BMC/IPMIではなく）メインNICに指定したIPアドレスを使わずに、DHCPでアサインされたIPを使用してしまい、

Jun 19 10:20:10 10.54.3.21 [localhost] xcat.genesis.dodiscovery: Beginning echo information to discovery packet file...
Jun 19 10:20:11 10.54.3.21 [localhost] xcat.genesis.dodiscovery: Discovery packet file is ready.
Jun 19 10:20:11 10.54.3.21 [localhost] xcat.genesis.dodiscovery: Sending the discovery packet to xCAT (10.54.0.1:3001)...
Jun 19 10:20:11 10.54.3.21 [localhost] xcat.genesis.dodiscovery: Sleeping 5 seconds...
Jun 19 10:20:11 10.54.3.21 [localhost] xcat.genesis.minixcatd: The request is processing by xCAT master...
Jun 19 10:20:12 scyld xcat[17879]: xcatd: Processing discovery request from 10.54.3.21
Jun 19 10:20:12 scyld xcat[17879]: xcat.discovery.aaadiscovery: (00:25:90:1d:6e:ae) Got a discovery request, attempting to d
Jun 19 10:20:12 scyld xcat[17879]: xcat.discovery.blade: (00:25:90:1d:6e:ae) Warning: Could not find any nodes using blade-b
Jun 19 10:20:12 scyld xcat[17879]: xcat.discovery.switch: (00:25:90:1d:6e:ae) Warning: Could not find any nodes using switch
Jun 19 10:20:12 scyld xcat[17879]: xcat.discovery.mtms: (00:25:90:1d:6e:ae) Warning: Could not find any node for Super Micro
Jun 19 10:20:12 scyld xcat[17879]: xcat.discovery.zzzdiscovery: (00:25:90:1d:6e:ae) Failed for node discovery.
Jun 19 10:20:12 scyld xcat[17879]: xcat.discovery.zzzdiscovery: Notify 10.54.3.21 that its findme request has been processed
Jun 19 10:20:11 10.54.3.21 [localhost] xcat.genesis.minixcatd: The request is already processed by xCAT master, but not matc

Compute NodeがManagement Serverに自分を発見するようにリクエストしても、そのIPアドレスが既知のcompute nodeのそれではないということで拒否される状況では、

# chtab -t node -o cn01 mac="00:11:22:DD:EE:FF"
# makedns -s ; makedhcp -n ; makedhcp -a
# rinstall compute2 runcmd=bmcsetup,osimage=ubuntu18.04.2-x86_64-netboot-compute
# rpower cn01 boot

とあらためてMACアドレスを指定しなおして、DHCPがcn01とそのMACアドレスを見つけて、正しいIPアドレスを割り当てるようにする。その上でrpower compute2 bootをかけると上手くいった。

つづく

これで、一応HPCクラスターが立ち上がるところまで設定できた。xCATが面倒をみてくれるのは、BMC/IPMIによるcompute node群のコントロール、OSのデプロイ、ネットワーク管理、ユーザーアカウント管理をふくめてcompute nodeの管理などまでである。このあと、クラスターの稼働状況を表示するGangliaやジョブスケジューラーSGEなど、準備設定すべきものがいろいろあるので、それはまた別記事として書くことにする。また、本稿に間違いや不明点あれば、ぜひご指摘戴ければありがたい。

  1. 自明的並列、驚異的並列、バカ並列 ……などといった訳があるようである。英語版Wikipediaによるとan embarrassment of richesという「ありあまる財産」「富による『うんざり』」といった皮肉っぽいフレーズに由来するとのこと。もちろん、embarrassingly parallelと言いつつ、実際はありがたく楽々と並列化させてもらうのである。 ↩

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-19T15:38:37+09:00

Go言語でHelloWorldを実行しようとしたらエラーになった

Hello world が出来なかった話

業務でGolangを使用する機会がありました。
本格的には触らなかったので、とりあえず自習しようとしました。

  • とりあえずhello.goを作ってhello worldを表示しようとします。
$ go run hello.go
exec: "C:\\Users\\xxxxx\\AppData\\Local\\Temp\\go-build929698758\\b001\\exe\\hello": file does not exist

ああ？？なんだこれ？hello World で死ぬか？普通？ってなったわけです。

失敗した原因

とりあえず build だけやってみる

xxxxx@xxx MSYS /c/Users/xxxxx/Documents/test/go
$ go build hello.go

xxxxx@xxx MSYS /c/Users/xxxxx/Documents/test/go
$ ls
hello  hello.go
  • バイナリ?が windows のじゃない！！

windowsで実行するなら

$ ls
hello.exe  hello.go

ができるのが正解ですよね～

こうなる原因が環境変数のGOOSでした。

$ env | grep GOOS
GOOS=linux

こうなっていたわけですよ。このGOOS=linuxがいけなかった。
業務中にテキトーに設定したのがいけなかった。
GOOS=linuxって環境変数を設定しているとbuildして作られるバイナリファイルがLinux向けに作られるっぽい？
MSYS2またはgit-for-windows上でなら実行できるのでは？とか思ったのですがエラーでしたね。
てことで、

どうすれば良いのか

GOOSを変えます

$ export GOOS=windows
# cmdだったら以下
set GOOS=windows

をした後に build すると
hello.exe が生成されますよっと。
これで解決。
GOOS=windowsに設定するのが正しいのかは知らない。
もうこの環境変数消した方がいいのかな。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-19T06:41:55+09:00

FIFOについてもう少し

FIFOとは

パイプに名前をつけたものがFIFO。終わってしまった。
ls -l | grep keyword
における | がパイプで、これにファイルシステムグローバルな名前をつけたものがFIFOということになる。性質はパイプと変わらない。上記の例だと

1.grepが起動してパイプのopen(O_RDONLY)でブロッキング
2.lsがパイプをopen(O_WRONLY)で開き
3.lsが出力をパイプにwrite()
4.grepのブロックが解除され、入力をread()
5.lsがパイプをclose()
6.grepがパイプをclose()

みたいな動きになる。open()でブロッキングするのであってread()やwrite()ではブロッキングしない。これは日本語man pagesに書いてあるのだがわかりづらい。つまりこうだ。

seekのきかないファイル（パイプやFIFO）は現在位置から読み込みを開始して、データがない場合はEOFとみなして0を返す。

ゆえにread()ではブロッキングしない。通常はこれで困ることはないが、プロセス間通信でスレッドを立てて、ループでデータの到着を待つような処理をする場合、open()でブロッキングしてCPUの浪費を防ぐ必要がある。しかし人情として、いちいちループ中でopen()/close()はしたくない。read()でブロッキングが可能ならそれがベストだ。

そこでメッセージキュー

POSIXメッセージキューは固定サイズのメッセージを有限個格納できるキューである。作成時にブロッキング属性を付与するため、キューの受信を実行しても（ブロッキングキューであれば）メッセージ到着までブロッキングしてくれる。

なのでスレッドのループ中でメッセージの到着を待つような処理に向いている。パイプのようにSIGPIPEを発生することもなければ、FIFOの両端が閉じるとデータを失うようなこともない（カーネル寿命なのでシャットダウンまでデータを保持してくれる）。

プロセス間のデータ交換

プロセス間通信の方法は、ほかにもセマフォやシグナル、共有メモリなどがあるそうなのだが、データ交換を目的に行う場合はFIFOかキューかドメインソケットになると思う。それぞれ一長一短はあると思うのでいずれまとめてみたい。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2020-06-19T01:02:32+09:00

Linux 基本

基本コマンド

  • ps -as
    • 稼働中のプロセスを見る
  • ps -ef|egrep|[見たいプロセス名]|[見たいプロセス名]|・・・|grep -v grep
  • systemctl status firewalld.service
  • systemctl list-unit-files -t service
    • 全サービスの稼働状況をみる

vim

  • 検索で次のヒットに移動する
    • /で検索した後に「n」
  • 元に戻す [u]
  • 元に戻したのを戻す [Ctrl+r]

mysql

  • 同時接続数のマックス確認
show variables like 'max_connections';

error message対応

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

日付別

タグ一覧