日記2020年1月10日金曜日zabbixの設定画面で、大量のグラフ項目を表示するわたしは普段システムの監視にzabbixを使っているのですが、ずっと不満点がありました。ディスカバリで生成される大量のグラフ項目のせいで、目的のグラフが見つけられないという問題です。zabbixの管理画面では、アイテムやトリガーなどは絞り込み検索ができるのですが、グラフだけは絞り込みができず、表示される最大件数の1000件を超えてしまうことがありました。この1000件制限を緩和したく調べてみたところ、データベースのconfigテーブルのsearch_limitカラムに記録されていました。パフォーマンス的な理由で制限が掛けられているのだと思いますが、わたしのところでは増やしても問題は感じませんでした。これWebUIから変更できないんですよね。アカウントの設定画面にあった「ページあたりの表示行数」を増やしても、1ページの表示件数が増えるだけで1000件制限は変わらず最大ページ番号が縮むだけでした。換気、足りてますか?わたしは季節に関係なく頭が痛くなったりする事があるのですが、そういうときは大抵乾燥が酷いときだったりします。部屋にぶら下がっている湿度計を見ると50%を下回っていて、慌てて加湿機を動かします。加湿をしても効果が無いときがあり、他になにがあるだろうかと考えたところ、換気が足りていないのではないかというのを思い出しました。息苦しいとか頭がクラクラするとかいうのは感じたことがありません。実際にどのくらい換気が足りていないのか、測ってみないことには分からないということで、arduinoとCO2センサーを組み合わせて測ってみました。unoと、CO2センサー「MH-Z14A」、気温湿度気圧センサー「BME280」です。結線とソースコードはググったら出てくるでしょう。CO2センサーはMH-Z19が欲しかったのですが、Amazonでもどこも海外発送ばかりで、到着まで2週間掛かるということだったので、国内のAmazon倉庫から発送できると書かれていたMH-Z14Aにしました。arduinoのEthernetライブラリを使って自宅のサーバに計測値を投げてファイルに保存し、zabbixからファイルを読み取るという仕組みにしています。2000ppmをトリガーにして、Slackへ通知を送信。はまった部分としては、計測値を投げる処理を1分に一回にすると、なぜか処理が止まってしまうため、30秒に一回にしています。keepaliveあたりのなにかなのか、調べ切れていません。二酸化炭素濃度は、自然界でだいたい400ppm、よく換気されている部屋で1000ppm以下、2000ppmからは換気が必要だそうです。実際「建築物における衛生的環境の確保に関する法律」でも1000ppm以下にすることが求められています。実際に測ってみて分かったこととしては、意外と簡単に2000ppmに達するということです。14畳ほどの広さのリビング・ダイニング・キッチン一室。古い建物で、外の風が強いときなどはドアの下から風が入ってきて寒いぐらいなのですが、穏やかな天気の時は意外と密封度は高いらしいです。冬場は、この部屋で小型のガスファンヒーターをつけています。6畳用だったか、8畳用だったか忘れてしまいましたが、能力からすると不足気味の機械なのですが、2時間ぐらいで400ppmから2000ppmぐらいまで上がります。冒頭で頭がクラクラしないなんて書きましたが、もっと高い濃度で発生するもので、それより前に作業の能力などにも影響が出てくるそうです。見かける注意書きも、死亡事故なんていうぐらいだから「うっ、苦しい」みたいなことになるレベルを想定してしまいますが、じわじわと身体を蝕んで気が付いたときには手遅れということにならないよう、早め早めの換気が必要ですね。追記arduino用ユニバーサル基板を買ってきて、組み立ててみました。EthernetシールドのLAN端子がかなり大きくて、基板を切る必要がありましたが、これでブレッドボードと違って蹴飛ばしても配線が外れる心配が無くなりました。zabbixでシステムの状況はモニタリングしているのだが、それを外部に公開する仕組みを用意していなかった。zabbixのページをそのまま公開したくなかったので、必要な情報だけ抽出して表示できる仕組みが欲しかった。SNSでつぶやいてみるとUptimeRobotというサービスを紹介してもらえた。設定してみたところ、格好良い稼働状況ページが出来上がったのだが、うちのシステム上、ウェブサーバとデータベースが分離しており、データベースを使う処理は動かないが、ウェブサーバだけで完結する処理は動くという状況があり得て、その表示がしにくいなと感じた。そこで、やはり自前で処理を作るかと、ついでに使ったことのなかったVueも試しに取り入れてみた。普段仕事でもまだまだjQueryを使うことが多く、また思い付いたサービスを個人で作るときにも早く公開したくて慣れているjQueryを使ってしまうことが多い。今回は急ぐものでもなかったので、サンプル程度しか動かしたことのなかったVueを使ってみた。いっても、やはりサンプルの継ぎはぎではあるのだけど。処理自体は問題無くできて、さて公開するかというところで問題があった。稼働状況ページは、自分が管理しているシステムの中で動かしてしまうと、一緒に落ちたときに肝心の状況が見えなくなってしまうので、公開ページは別のサービスで動かしたかった。最初に選んだのがS3で、ここでは静的サイトを公開する情報も整っていたので簡単に設定して公開。あとはネームサーバとして使っているCloudflareでCNAMEを張ってやれば動くだろうと考えていた。実際に公開してみたところ、httpでは繋がるのだが、httpsでは接続ができなかった。S3の公開では、「https://S3ドメイン/バケット名/」だとhttpsが使えるのだが「https://バケット名.s3ドメイン」ではhttpsが使えない。Proxyを有効にしていたら、オリジンサーバーがhttpでも使えたような記憶があったのだけど、どうも上手く行かないので間にCloudFrontを挟んでhttpsでも繋がるようになった。ページの作りとしては、zabbixから出力したSLAの情報をS3に5分毎にアップロードし、静的ページ側でそれを読み込んで表示する。CloudFrontは読み込んだ情報をキャッシュしてしまうので、いつまでも古い情報が表示されてしまうのだ。CloudFrontの設定にも用意されているので、TTLの設定を5分にしてみたり、クエリが付いていたらキャッシュしない設定にしたり、キャッシュをクリアしてみたりしたのだが、どうにも解消できなかった。結局Netlifyで静的ページ部分を配信しつつ、データはS3から読み込むという仕組みで解決した。Pagesで配信しようと考えてしまい、5分毎にコミットとプッシュをしたら怒られそうだなと思って頭の中からGitHubを使うことを取り除いてしまっていた。大枠の仕組みが完成したので、これを応用して、zabbixに入力したメンテナンス情報を各サービスで表示したり、自動でメンテモードに切り替えたりもできるだろう。今はデータベースを止めるメンテナンスがあるときに、各サービスのcronを止めたり、フラグを立てたりと手動で処理してアクセスが止んだのを確認してから作業したりしているので、この辺りも自動化してしまいたいと考えている。プログラム2019年1月27日日曜日PostgreSQLのshared_buffers設定とZFSのARCの関係を調べたいつも個人のプロジェクトではPostgreSQLを使っており、自宅サーバで大きいデータベースを運用しています。最近まではmdadmで組んだRAID-5の上に、ext4でファイルシステムを作って、その中にデータベースのテーブルスペースを置いていました。最近ZFSを使い始め、同じようにRAID-Zでファイルシステムを作ってテーブルスペースを置くようになりチューニングを再確認していたのですが、少し気になることが出てきたので調べてみました。PostgreSQLのshared_buffers設定PostgreSQLの設定には、shared_buffersというものがあり、搭載されているメモリから共有メモリを確保して、PostgreSQLの各プロセスが利用しています。この値は1GB以上のRAMを載せた専用データベースサーバを使用している場合、shared_buffersに対する妥当な初期値はシステムメモリの25%です。shared_buffersをこれよりも大きな値に設定することが有効なワークロードもあります。PostgreSQLはオペレーティングシステムキャッシュにも依存するため、shared_buffersにRAMの40%以上を割り当てても、それより小さい値の時より動作が良くなる見込みはありません。資源の消費より)とあり、あまり大きくしても効果が無いとまで書かれています。実際にext4でテーブルスペースを管理していた時は、この設定でhtopをみると搭載メモリの利用状況を示すバーの約25%が緑色、約75%が黄色となり、キャッシュが有効に働いていることが確認できました。ZFSのARC設定ZFSにはARCと呼ばれるメモリ上のキャッシュ機構を持っています。これは空きメモリから使用され、ディスクから読み出した際にARCにも格納され、同じデータの読み出しが発生した場合はディスクを参照せずここから読み出すことによって高速化を行います。ZFSを開発したSunのエンジニアが、MySQLで使う場合のチューニング指標としてZFS上でMySQL/InnoDBを利用する場合、利用されるキャッシュにはいくつかの階層が存在します。InnoDB自身がバッファプールを持っていますし、ZFSにはARCがあります。それらのキャッシュは個別に何をキャッシュまたはフラッシュすべきかということを判断するようになっています。それらが同じデータをキャッシュするというような状況が生じてしまうこともあるでしょう。InnoDB内でキャッシュすると、データへたどり着くまでにより短い(そして高速な)コードパスで済むでしょう。InnoDB内でキャッシュミスが生じれば、例えそのデータがARCに存在していたとしてもダーティページのフラッシュが生じてしまうことになります。これは不要な書き込みを生じさせる原因となります。ARCは利用可能なメモリの容量によって(自)動的に縮退・拡張しますが、単にそれを制限する方がより効率的です。我々が実施したテストでは、ZFS内でキャッシュするよりInnoDB内でデータをキャッシュしたほうが7〜200%の性能向上が見込めることを確認しています。違いが分かるエンジニアのためのMySQL/InnoDB/ZFSチューニング!より)と紹介されています。このため、データベースでZFSを利用する場合ARCのキャッシュ情報はallではなくmetadataのみをキャッシュするように設定するという紹介をあちこちで見かけます。鵜呑みにして設定わたしもこれを読んで同じように設定していたのですが、思った以上にパフォーマンスが上がらず、はてどうしたものかと悩んでいました。気が付いたのが、htopで表示されるメモリの使用状況バーは搭載メモリの25%だけが緑でキャッシュが全く使われていない状況でした。メモリの25%しか使っていない状態でした。いうことは、ext4ではOSの標準設定によりキャッシュが働いているからshared_buffersを増やさなくても良いということなのですが、ZFSでキャッシュを最低限にしている場合、shared_buffersを確保した方がいいのではないか?ということです。そこで、PostgreSQLにおいてZFSを使用する場合、shared_buffersを増やしたときと、ARCのすべてキャッシュするときのベンチマークを取ってみました。以下の環境でテストを行いました。1,576,528,895(データベースサイズは約1.5GB)設定変更後に再起動。benchで60秒間のベンチを回して、その後5回分のトランザクション数を記録テストパターンは以下の4種類です。794ZFSのキャッシュをした方が良いという結果になりました。パターン2はパターン4と同じになるかと思ったのですが、パターン1よりは性能が良いがパターン3より性能が出ないということで、やはりshared_buffersの設定は増やしすぎても効果が無いようです。パターン3とパターン4でも差がないことからshared_buffersを増やすぐらいならARCに回した方が良いという結果になりました。MySQLでZFSを使うシーンに出会っていないので、今回はPostgreSQLの設定だけですが、やはり実際に測ってみないと分からないものだなと感じました。683大した有意差が見られず、また128Kの方が成績が良かったことから、うちでも8Kにしていたのを128Kに戻しました。ARCが効きやすいレコードサイズの設定があるのかと思って検索してみたりしたのですが、それらしいドキュメントは見つけられませんでした。ソースをあたるしかなさそうです。2018、18日目です。おさこの作品は、まだ人類が母なる惑星、地球にいた頃に書かれたものだ。人類が宇宙に進出し、多くの星々をネットワーク接続するアウターネットになる前の、地球を覆い尽くしていたネットワークでの出来事がオムニバス形式で綴られたものだった。作中では管理者でもない人達が、それぞれ自分たちの価値観で物事を仕切りはじめ、コミュニティが崩壊していく話があった。個人を大切にするという考え方が、自分勝手と誤った解釈になり、共同体に所属する一個人でしかないという前提を忘れさせてしまうのか、そのような動きになる例を道徳の授業で習ったことを思い出した。わたしはこの作品を読んで、人類の歴史は繰り返すものなのだと感じた。ルール、これらはそれぞれのグループが築いてきた歴史に基づいたものであり、各グループは構成する人員の入れ替わりに合わせて信条が変化してきたものだ。人はそれぞれ考え方が微妙に異なり、完全に同じ考えを持つ人間は存在しない。それは同じ条件式と学習結果を与えられたコンピュータだけだろう。地球で文明を持ち始めた頃の人類は、各々が役割を分担することで、一人あたりの生活コストを下げ、文化を成長させてきた。人はお互い微妙に異なる考えや価値観を擦り合わせ、許容できる者同士で集まって生活しているのだ。これはネットワークにおいても同じことが言える。アウターネットになった現在でも、サービスは宇宙空間に分散したサーバー上で実行されているし、そのサーバーはエネルギーを得るためにどこか恒星系に所属している。これはアウターネットでの活動も、何らかの制約に縛られるということだ。なんの制約にも縛られたくないという人達もいるようで、アステロイドベルトの公宙域にサーバーを置いている人もいるようだが、警備ロボットなどでかなりの費用が掛かっていると聞いた。この作品でも語られていたように、自由とはコストが掛かるもので、何かを守るためにはお金であったり、人的リソースであったり、とにかく力が必要となる。わたしは大金持ちになったら、ぜひ自分のサーバーを打ち上げてみたいと思った。現代では人類の活動範囲が広がってしまい、みんな同じような生活となってしまっているので、きっと共有サーバーで他の人達とアウターネットを使っていくことになるのだろうなと思っている。相手への敬意を忘れず、自分に合う活動領域を見つけたいと感じた。エスペラント語でTerpomoってポテトの意味らしい。2018、14日目です。分散SNS、2年目ともなると、だいたい概念を理解して、なんとなく使い方の勘所が掴めてきましたよね。去年4月の右往左往していた時期が懐かしいです。分散SNSということで運営の権限を分散させるだけでなく、マストドン以外の実装としてPleroma、Misskey、microblog.pubなんてのも出てきました。実装も分散されているのにお互いが会話ができる、バベルの塔を壊すべく言語を乱した神様もビックリでしょう。今ならバベルの台地も作れそうです。2017でマストドンのフォロー状態可視化ツール「フォローリンク」を書きました。マストドンアドベントカレンダーでした。去年フォローリンクを作ったときはマストドン専用だったのです。実装が複数あるのに、どうしても注目を集めたということで人口の多いマストドンがさらに注目されてしまうのは仕方がない部分があるかと思います。APIの実装なども先行している部分がありますね。分散SNSという仕組みがあるのだから、どうせなら特定の実装に依存せず、みんなで使えるようにしたいということで、ActivityPubでデータを取得するようにしてPleromaに対応しました(あ、Misskeyで動作確認してない)。ActivityPubでも、実装によってデータの持ち方が違って、若干揺らぎがあるのが辛いところですが、テキストで入っているかオブジェクトで入っているかなので、扱いに慣れてくると問題なさそうです。今年、もう一つサービスを公開しました。ログ蓄積サービス「notestock」です。何ができるかというと、まあサイトを見てもらうのが手っ取り早いのですが、簡単に書くと日付別にまとめて表示したり、検索ができます。実はnotestockの前にMastoDaysというサービスを公開していました。特定の日付のマストドンユーザーページを開くツールだったのですが、名前から分かるとおりマストドン専用でした。実装を意識しないでツールが使えるというのは、なかなか使い心地が良いです。上手く疎結合にしていろいろなツールの選択肢が広がると良いですね。いうことで、本当にマストドンでなければいけないツールでない限り、できるだけいろいろな実装に対応していると嬉しいねという話でした。ここまではコミュニティのインフラ的な話だったのですが、もう一つコンテンツ的な部分の話も。ときどき流れてくるハッシュタグ「マストドン○○」とか「○○マストドン」みたいなやつ。あれが流れてくると、他の実装の人って、参加していいのか迷うというか、参加するにしてもちょっと乗り切れない感じがありますよね。気持ちいい」んでしょうね。あと、ゲーム機は全部ファミコンと言うみたいに、分散SNSを指す言葉としてマストドンが使われてしまっているところもわりと有る気がします。このへん、先ほども書いたように先行プロダクトとして仕方ないのかなぁと思うところもあるのですが。えすえぬえす」と10音もあると、なんかまどろっこしい感じになってしまいます。ここは略語としてよく使われる四文字を探し出し「ぶんさん」を使って「分散○○」みたいな感じはどうでしょうか。この場合は後ろに分散を付ける「○○分散」はちょっと意味が伝わりにくくなる気がします。ここまで書いて、別に分散SNSを表すハッシュタグを付けなくても、単純に「○○」だけ付ければ良いんじゃないかと気が付いてしまったのですが、たぶんこの辺りって「マストドン(分散SNS)にいる仲間達」みたいな帰属意識から生まれるものなのかなぁと思ったりもしました。ハッシュタグを付けるときに、少しマストドン以外の存在も思い出して欲しいなという提案と、なんか呼びやすい略称は無いですかね?という問いかけでした。今年もやって来ました。いろいろなアドベントカレンダーが始まる日です。して書き始めたアドベントカレンダーなのですが、参加したカレンダーが問題なのです。2018」わたしの?いいえ、ねそ氏の一人アドベントカレンダーなのです!どういうことやねん。上のリンクからアドベントカレンダーが参照できますが、いきなり一番バッターと二番バッターが他人ですよ。氏は自分のアドベントカレンダーで三番四番と野球なら良い打順を持っていくわけです。このアドベントカレンダーも何を書こうか迷いました。一人の定義とはなんなのか掘り下げようか、百合アドベントカレンダーにしてしまおうか、ねそ氏について有ること無いこと書こうか。初日ですので、あんまり変な方向性に持っていくのもよろしくなかろうと、とりあえず経験談でも。前座というか一番バッターですしね。実はわたしも2015年にやったんですよ。このときは一人アドベントカレンダーではなく、いろんな種類のアドベントカレンダーに25日分参加するというものでした。2015)このときは11月頭に計画を立てて、記事を書き始め、1日に3本ぐらい書いたり全く進まない日があったりで、常に10日分ぐらいストックを溜める感じで書き進めていきました。ストックがある分、まだ追い詰められ感は少なかったのですが、かなり厳しかったですね。仕事をしていても記事のことを考えてしまうような状況でした。考えると、土日の分を他人に託してしまうというのは、かなり斬新なアイデアかと思います。氏の記事がどんな風になるのか、今から楽しみですね。こんな感じで良い感じのヒットになったでしょうか。氏の登場まではしばらくありますが、次はえじょねこ氏の記事をお楽しみください。(1)ブログ村にほんブログ。