2021年11月

Disk utilizationがあがった原因が分かりません…

CentOS8からAlmaLinuxへの移行後、/dev/sdaのDisk utilizationが6%ほどから18%ほどにあがりました。
おそらく直接的な原因はAlmaLinuxへの移行ではなくて、kernelのVerUPによるものだと思っています。(とてもよくないのですが)1年間kernelを更新しておらず、AlmaLinuxへの移行を契機にrebootしました。
CentOS8とAlmaLinuxのパッケージはほぼすべて一緒なので、移行前後でかわったものはkernelしかないと思っています。

Disk utilizationが100%になっているわけではないので、たぶん、問題ないのだとは思うのですが、サーバーの使い方は何もかわっていないのに、Disk utilizationだけがあがった理由が分かりません。

以下、調べた情報を書きます。
ErogameScapeではmuninでサーバーのリソースを監視しています。
muninのdiskstatsというプラグインに、Disk utilizationという監視項目があります。
Screenshot_1
赤矢印の部分がAlmaLinuxへの移行のためにrebootをしたタイミングです。
Disk utilizationが突然あがっています。
そもそも、Disk utilizationはなんなのかについて、マニュアルを見ると
Linux provides a counter which increments in a millisecond-interval for as long as there are outstanding I/O requests. If this counter is close to 1000msec in a given 1 second timeframe the device is nearly 100% saturated. This plugin provides values averaged over a 5 minute time frame per default, so it can’t catch short-lived saturations, but it’ll give a nice trend for semi-uniform load patterns as they’re expected in most server or multi-user environments.
とのことで…、DeepLで訳すと
Linuxでは、未処理のI/O要求がある限り、ミリ秒間隔で増分するカウンタが用意されています。このカウンタが1秒の時間枠で1000msecに近い場合、デバイスはほぼ100%飽和しています。このプラグインは、デフォルトでは5分間の平均値を提供するので、短時間の飽和を捉えることはできませんが、ほとんどのサーバーやマルチユーザー環境で予想されるような半均一の負荷パターンの傾向を知ることができます。
とのことです。
Munin disk utilization」でぐぐると、Munin disk utilization calculation.という質問がヒットしまして、回答に、
From reading the diskstats plugin source, munin calculates the disk utilization percentage by looking at the total time spent doing IO over a given monitoring period. If the device is spending all it's time doing IO, then it's at 100% utilization. This is somewhat independent of actual IOPS and read/write speeds, as these will have a very access-pattern dependent effect. (I presume you're actually asking how munin calculates the utilization percentage, rather than specifically how to use IOPs and read/write sizes to calculate the same thing)

Munin gets this data from /proc/diskstats. The column in question is the 10th field after the device name (and munin does the usual thing of storing the value the first time it reads it, and the second time it reads it calculating the difference between the old and new values, in order to work out the delta over the monitoring period).
とあります。DeepLで訳しますと
diskstatsプラグインのソースを読むと、muninは所定の監視期間中にIOに費やされた合計時間を見て、ディスク使用率を計算します。デバイスがすべての時間をIOに費やしている場合、利用率は100%になります。これは、実際のIOPSや読み書きの速度とは多少独立していますが、これらはアクセスパターンに大きく影響されるからです。(あなたは、IOPsや読み書きのサイズを使って同じことを計算する方法ではなく、muninがどのように利用率を計算するかを実際に尋ねているのだと思います)

Muninはこのデータを/proc/diskstatsから取得します。問題の列は、デバイス名の後の10番目のフィールドです(そして、muninは、最初に読み込んだときに値を保存し、2回目に読み込んだときには、監視期間中の差分を計算するために、古い値と新しい値の差を計算するという通常のことを行います)。
とのことです。
/proc/diskstatsから、デバイスがI/Oに使用した時間を取得できるので、例えば5分の間にデバイスがI/Oに使用した時間を取得して、デバイスがI/Oに使用した時間 / 5分、とすると5分間のデバイスの使用率が分かるということのようです。
一応、diskstatsプラグインのソースを読んでみます。プラグインのソースは「/usr/share/munin/plugins/diskstat_」を読んでもいいですし、マニュアルのSource Codeというボタンを押しても読めます。
    # Utilization - or "how busy is the device"?
    # If the time spent for I/O was close to 1000msec for
    # a given second, the device is nearly 100% saturated.
    my $utilization = $tot_ticks / $interval;
これが、Disk utilizationを求めているところです。
$intervalは
my $interval = time() - $prev_time;
ですので、現在時刻と1つ前にmuninがデータを取得した時刻の差分です。muninは5分おきに動かしているので、$intervalは、だいたい300となります。
$tot_ticksは
my $tot_ticks = subtract_wrapping_numbers($cur_stats->{'tot_ticks'}, $prev_stats->{'tot_ticks'});
なので、現在のtot_ticksの値と1つ前にmuninがデータを取得したtot_ticksの差分です。
tot_ticksはどこで取得しているかというと、
        @devstat{
            qw(major minor devname
              rd_ios rd_merges rd_sectors rd_ticks
              wr_ios wr_merges wr_sectors wr_ticks
              ios_in_prog tot_ticks rq_ticks)
          }
          = @{$entry};
の部分です。
/proc/diskstatsを取得して、major minor devname…tot_ticks rq_ticksという変数に格納しています。 /proc/diskstatsは、
$ cat /proc/diskstats
   8       0 sda 1329537 16925 80987603 35548923 4020342 216704 112010832 1095361766 154 26533813 1130910690 0 0 0 0
   8       1 sda1 981 0 103554 25718 128 195 2584 9718 0 6755 35437 0 0 0 0
   8       2 sda2 1328484 16925 80880689 35522960 4020214 216509 112008248 1095352048 154 26532460 1130875008 0 0 0 0
 253       0 dm-0 885790 0 80697097 14647953 3995311 0 111499848 1134259478 165 26236727 1148907431 0 0 0 0
 253       1 dm-1 21680 0 177048 158335 64063 0 512504 15535543 0 188377 15693878 0 0 0 0
   7       0 loop0 53 0 988 450 0 0 0 0 0 368 450 0 0 0 0
   7       1 loop1 1632 0 5614 3283 0 0 0 0 0 604 3283 0 0 0 0
   7       2 loop2 16264 0 33416 13069 0 0 0 0 0 2317 13069 0 0 0 0
   7       3 loop3 7558 0 15962 19005 0 0 0 0 0 1144 19005 0 0 0 0
   7       4 loop4 54 0 2406 593 0 0 0 0 0 342 593 0 0 0 0
   7       5 loop5 46 0 938 283 0 0 0 0 0 263 283 0 0 0 0
   7       6 loop6 4 0 8 2 0 0 0 0 0 2 2 0 0 0 0
な感じです。
一番上の行でしたら、majorに8、minorに0、devnameにsda、rd_iosに1329537…と入っていきます。 tot_ticksには、26533813が入ります。
※/proc/diskstatsの内容についてはこちらに記載があります。tot_ticksは「Field 10 -- # of milliseconds spent doing I/Os」です。

    my $utilization = $tot_ticks / $interval;
の、$tot_ticksは単位がmillisecond、$intervalは単位がsecondですので、使用率(%)にするため、
my $util_print = $utilization / 10;
として、$util_printを表示します。
なるほど、表示している内容は分かりましたが、使用率があがった理由はまったく分かりません…
100%ではないし、iowaitも前後でかわっていないので…、特に何かする必要はないかな…と思っています。
Screenshot_2

さくらインターネットの専用サーバ スタンダードシリーズをCentOS8からAlmaLinux8に移行した際のトラブル

さくらインターネットの専用サーバ スタンダードシリーズをCentOS8からAlmaLinux8に移行した際、ネットワークインターフェイスの名前がifconfigとnetwork-scripts配下のファイルで不一致が発生したため、rebootしたらNICがupしませんでした。
結論から書くと、network-scripts配下のファイルを書き換えて再度rebootしました。

[借用しているサーバー]
専用サーバ Fujitsu RX1330 M3 Xeon 4Core (20-04)
※これがリリースされた後、すぐにPHYがリリースされてとても悲しかったです。また、PHYしかOSインストールの選択肢としてAlmaLinuxに対応していないので、とても悲しいです。

AlmaLinuxに移行しrebootした後、NICがupしませんでした。
ifconfigの出力は
[sakura ~]$ ifconfig
eth0: flags=4099  mtu 1500
(中略)
eth1: flags=4163  mtu 1500
(中略)
lo: flags=73  mtu 65536
と、IFの名前が昔のeth0、eth1という表現。
network-scripts配下のファイルは
[root@sakura ap2]# ls -l /etc/sysconfig/network-scripts/
total 12
-rw-r--r--. 1 root root 285 May  2  2020 ifcfg-eno1
-rw-r--r--. 1 root root 138 May  2  2020 ifcfg-eno2
と、eno1、eno2という表現でした。
移行前は問題なかったので…、なぜ問題でなかったのかはさっぱり分からないのですが…、IFの名前をあわせればいいので…、
linux - RHEL7 で NIC の名前を eno1 から従来の eth0 に変更するには? - スタック・オーバーフロー
のとおりに、ifcfg-eth1というファイルを作って
NAME=eth1
DEVICE=eth1
の部分をeno1からeth1に書き換えて再起動し、無事NICがupしました。

/etc/default/grubを見ると
GRUB_CMDLINE_LINUX=" resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap  net.ifnames=0  biosdevname=0 consoleblank=0 nomodeset crashkernel=auto"
となっていて、赤字の設定があると、IFの名前が昔のeth0、eth1という表現になるのがデフォルトで、名前をかえたい場合は、network-scripts配下のファイルの設定で、HWADDR=を指定してあげると、HWADDR=で指定されたNICの名前がNAMEとDEVICEに書かれたものになる…ようなのですが、もともとの設定にはHWADDR=がなかったので、IFの名前がeno1になってちゃんと起動できていたのか分かりませんでした。

専用サーバーを借用するとネットワークの設定は自分でやらないので、トラブルが発生したとき困るなあ…と思いました。
次は借用したら、最初にネットワークの設定関連のバックアップを取得しておこう…と思いました。
また、こんなことが起きることを想定して、借用する場合はコンソール接続ができること、を条件にしているのですが、コンソール接続できてよかったです。使わないときは、何年も使わないのですが…

http://127.0.0.1にアクセスすると、https://127.0.0.1にリダイレクトされる

意図せずhttp://127.0.0.1にアクセスすると、https://127.0.0.1にリダイレクトされる事象が発生しました。結論から書くと、
/etc/httpd/conf.d/le-redirect-erogamescape.dyndns.org.conf
のせいでした。
参照した文書 : 【httpd】リダイレクトの正体を探る | 100%レンタルサーバーを使いこなすサイト

この事象はAlmaLinuxへの移行作業の際に発見しました。※移行作業とはまったく関係ありません。
ErogameScapeはhttpdの応答がなくなった場合、httpdをrestartするスクリプトを動かしています。
ユーザーさんからのアクセスを待機系サーバーに切り替え、サーバーの様子を見ていたところ、なぜかhttpdがrestartを繰り返していました。
おそらく、httpdをrestartするスクリプトが動いているのだと思って確認したところ、たしかにそのスクリプトが動いてました。
httpdが正常化に動作しているかの判断は以下のように書いています。
check=`wget -nv -S --spider -t 2 -T 5 http://127.0.0.1/~ap2/ero/toukei_kaiseki/ 2>&1|grep -c "200 OK"`

if [ $check != 2 ]
then
    echo 'NG'
else
    echo 'OK'
fi

スクリプトのとおりwgetしてみたところ、https://127.0.0.1にリダイレクトされていました。
127.0.0.1は証明書を設定していないので、NGとなり、httpdを再起動していました。
httpをhttpsにリダイレクトする設定はしていないのに、さて…と思って、ぐぐってみると
【httpd】リダイレクトの正体を探る | 100%レンタルサーバーを使いこなすサイト
のとおりで、le-redirect-erogamescape.dyndns.org.confのファイルに書いてあるとおりに動いているだけでした。
記録がないのでなんともですが、自分は
Please choose whether HTTPS access is required or optional.
-------------------------------------------------------------------------------
1: Easy - Allow both HTTP and HTTPS access to these sites
2: Secure - Make all requests redirect to secure HTTPS access

で、2を選んだんですね、たぶん…

Jest did not exit one second after the test run has completed.

NestJSのe2eテストで以下のメッセージが出てテストの応答がとても遅い事象が発生しました。
Jest did not exit one second after the test run has completed.

This usually means that there are asynchronous operations that weren't stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.
この問題は、e2eテストのファイルに以下を追記することで解決します。
  afterEach(async () => {
    await app.close();
  });
上記を書かないと、テスト項目ごとにデータベースへのセッションをはりにいってしまうため、以下のエラーメッセージがでてテストに失敗します。
[Nest] 33348  - 2021/11/05 9:21:04   ERROR [TypeOrmModule] Unable to connect to the database. Retrying (1)...
AlreadyHasActiveConnectionError: Cannot create a new connection named "default", because connection with such name already exist and it now has an active connection session.

記事検索