データベース自作PCサーバー作成 5

ずっとデスクに向かってると運動不足なんで、EMSくらいやろうかなって思って買ったやつを、背中に貼り付けて低周波マッサージ器として利用して、すぐ気絶することが、特技になりつつある小堤です。

まじですぐ寝落ちしてる、不眠症なら貼れば寝られる。手刀で首元バシッってきな感じ(経験ないけど)

Linuxの勉強・操作に慣れるため、または、今回のように自宅サーバー作ってみようかなってときに、ダメなら安価で捨ててもいいわレベルのマシンを探してたら、こんなのあるんですね。

早速買ってみました、まだ届いてませんけど。6cm x 6cm ってめっちゃ小さいですねぇ、メモリ6GB、容量128GB、何するかによりますが開発用データベースとか、十分何じゃないだろうか?と思って購入です。そもそも、Linuxインストールできなかったらやだな笑 まぁ過去にBMAXって中華ノートにもUbuntuはいったし問題ないやろ(人柱魂)

法人価格にクーポン適用して、14,650 円。中古のPC漁ってくるよりよいのでは・・・速度求めないだろうし・・。

正直これで、Windows 10 Home がついてくることに不安を覚えますが、中華製品あるあるですかね、消しますけど。

さて、本日は、ロードアベレージについてです。ロードアベレージ聞いたこと有りますか?僕は聞いたことあるけど、なにそれ美味しいの?くらいのレベルで、なんとなくサーバーの負荷状況を示していることは知っていたのですが、今回のデータベースサーバー構築にあたり、必要になったので改めて確認しました。

なぜ、ロードアベレージを確認するのか

Windows、Mac、Linux、OS問わず必ず経験したことがあるであろう

「なんか、マシン重い…. 」

さて、このマシンが重いという現象、何が原因でしょうか。CPUの処理がいっぱいいっぱいになっているのか、ディスクの読み込み・書き込みが待ちになっているのか。明確な理由を把握していますか?

大概は、マシンスペックを向上させることで解決できていると思いますが、どんなに高性能なマシンを手に入れても、使い方によっては、度々発生します。

ロードアベレージとは

ロードアベレージとは、マシン内で、処理(プロセス)がどの程度スタック、糞詰まりしているかを表したのがロードアベレージです。ということなんですが、初めて聞いたときにイメージしにくいのではないかと思うので、よくある例でイメージを掴みましょう。

「銀行に税金払いに行くか、はぁ・・窓口でしかできんのかい!」

ということで、あなたが銀行窓口に税金の振込に行くとしましょう。これが、1つのプロセス(処理)です。僕は銀行に税金を振込に行く処理として、銀行へ向かいます。

「整理券とって座って、呼ばれるまで黙って待っとれ!」

と丁寧に言われます。窓口の番号を見ると810番の人が、呼ばれたところのようです。僕の番号は、830番と書いてあります。

ざっと、20人目ってことだな、結構いるなぁ

はい、この結構いるとは、何を持って得た感想でしょうか。僕の行った銀行は、窓口が2つしかなく、後ろにいるバックオフィス(窓口の後ろにいて業務をしている)の人数も4人、いることが確認できたからです、単純に、10回窓口の受付番号が変わったら自分の番がきそうです、市役所なんかも同じですね。

某銀行では、最近ウェブサイトで現在の窓口業務の混み具合を提供していたり、機械学習等で、今後の混み具合予想などを表示してくれますね。

この、窓口がCPUコア/スレッド、バックオフィスがディスクI/O(読み込み/書き込み)だと考えてみましょう。

お客さんが1名しかいなければ、窓口は空いている。20人待っていると混んでいる。と思うと思います。この混み具合を示したのがロードアベレージです。

ロードアベレージは、topuptimesarコマンドで確認できます。実際に見てみましょう。下記は、topコマンドを実行した時の画面です。

3つ表示されていて、上記ではすべてが 0.00 と表記されています。

uptimeコマンドは、サーバー稼働時間とロードアベレージのみ表示可能です。

[root@localhost] $ uptime
 11:06:59 up 8 days,  4:02,  1 user,  load average: 0.01, 0.04, 0.00

sarコマンドを利用するには、sysstatパッケージが必要なので、必要に応じてインストールします。

[root@localhost] $ dnf install -y sysstat
[root@localhost] $ systemctl enable --now sysstat

sar コマンドを以下のように、すぐ実行しても何も表示されません。sar コマンドを使うと過去のロードアベレージを表示することができるんですね。起動したサービスがsaファイルというファイルに、定期的にサーバーの状態を記録してくれます。それを可視化するためのコマンドがsarです。

[root@localhost]$ sar -q
Linux 4.18.0-305.3.1.el8_4.x86_64 (mariadb2.vlue.io) 06/28/2021 _x86_64_(16 CPU)

11:04:46     LINUX RESTART(16 CPU)

これは、初期設定で、10分間隔で、記録されるようになっているからです。変更したい場合は、/usr/lib/systemd/system/sysstat-collect.timer を編集します。

# /usr/lib/systemd/system/sysstat-collect.timer
# (C) 2014 Tomasz Torcz <tomek@pipebreaker.pl>
#
# sysstat-11.7.3 systemd unit file:
#        Activates activity collector every 10 minutes

[Unit]
Description=Run system activity accounting tool every 10 minutes

[Timer]
OnCalendar=*:00/10

[Install]
WantedBy=sysstat.service
OnCalendar=*:00/10
↓
OnCalendar=*:00/5

に変更しして

[root@localhost]$ systemctl daemon-reload
[root@localhost]$ systemctl restart sysstat

上記で、設定を反映させます。

sar -A

とすると、システムの様々な情報を記録してくれていることが確認できますので、ロードアベレージ以外でも活用できそうですね。

さて、ロードアベレージは、左から 直近1分間、5分間、15分間 のロードアベレージが表示されています。そして、このロードアベレージは、1.0が100%、つまりちょうど良く忙しい、だが余裕はない状態を示します。上記の場合だと、めっちゃなんもしてない、暇ですって感じですね。

そして、システムが稼働している状態で 0.7 が適正なようですが、よくある使い方、条件によることは言うまでもありません。30%余力あるぜ!っていう状態で保てていると良いっていう感じですね。

では、この0.00 や 1.00などの数値はどの様に算出されているのでしょうか。

CPU負荷と、ディスクI/O負荷

その前に、僕のUbuntu上でのtop見てください。

2.45, 2.57, 2.79

1超えてるやんけ!忙しそうやんけー!!

でも、特に重くないんですよね。この値、1スレッド=1.0でみて良さそうです。今使っているUbuntuのCPUは、6コア12スレッドなんですけど、12.0まではOKっと考えて良さそうです。CPU%のところが100%超えるのもコレですね。

コア技術がなく、1CPUだけの時代は、1.0で見ていたみたいですが、デュアルCPUでも2.0ってことか。並行処理性能は、スゴイ進化しましたねぇ。CPUクロックも5Ghzは到達できないって言われてた(通常利用では耐えられない)気がするんですが、最近のCPUでブーストクロック5Ghzって出てきてますよね。先日リンクを貼ったCPUランキングで見てみると、古いCPU(中古のPC)買うより、安めの最新買った方が性能良さそうっていう印象になるくらい、性能伸びてますねぇ。

さて、このロードアベレージ。どの様に算出されているかというと、CPU負荷とディスクI/O負荷を足したものです。

なんやそれ・・・

って僕は最初なったんですが、確認していけば大した話ではなく理解できると思うので復習がてら。

CPU負荷とディスクI/O負荷は、vmstatコマンドで確認できます。

実行すると、下記のように表示されます。

左の rb を見ます。

r:The number of processes waiting for run time.
b:The number of processes in uninterruptible sleep.

rが実行待ちのプロセス数、bがI/O待ちプロセス数を示すようです。先の銀行の例では、窓口待ちの人数がr、バックオフィス待ちの処理件数がbって感じですかね。ロードアベレージの値は、直近1分間の場合、このrとbを足して、60(秒)で割った値です。5分なら300、15分なら900ですね。

「最近、忙しい?」

って聞いてる感じですね。

おわりに

ロードアベレージの確認方法がわかったところで、今回の自作サーバーのSSD性能は、前回確認できました。とはいえ、ディスクI/Oに余力があっても、CPU負荷が過多になるとロードアベレージは上がり、8コア16スレッドの場合、16.0を超えてしまっては、ディスクがいくら早くても、遅くなったり最悪サーバーが応答しなくなってしまいます。

次回は、MariaDB / MySQLのストレージエンジンについて確認をして、ロードアベレージを確認しながら、ディスクI/Oの余力を確認していきたいと思います。結果からいってしまうと、テーブル構造によるとはいえ、チューニングを行い、1つのテーブルで2億レコードを入れても、瞬時に目的の検索が行えるようにはできました。データベースのハードウェアに応じた設定も、ある程度指針になるテンプレートがあれば楽ですし、パーテショニンングもテーブル設計時に終わらせておくべきですしね。

今回やりたいのは、このチューニングももちろんですが、余っているディスクI/Oをうまく活用して、ストレージエンジンのSpiderを使って、さらに高速化したい企んでいます。書き込み性能のスケールできる構成を組むのも目的です。

また、OLAPという分析系の検索が不得意なんですね、RDBMS。MariaDBも例外ではなく、ElasticSearchを使ってみたり、ClickHouseを使ってみたり、列志向といわれるDBと連携したり、いろいろチャレンジしている情報を見ますが、MariaDBもColumnStoreというデータベースがあります。こいつは列志向のデータベースで集計処理とか速いですし、スケールもしやすいなどのメリットがあるのですが、最近このColumnStoreがストレージエンジンとして搭載されました。

ColumnStoreを利用するには、MariaDBとは別なサーバーとして設置するっていう感じなのですが、MariaDBにストレージエンジンとして、ColumnStoreを導入できることで、集計系の処理用にテーブルを用意して扱うことができます。また、別データベースの場合、データ挿入時に集計用にデータを格納しないといけない処理を、MariaDB内で完結できるので(トリガー処理とかレプリケーションとか)管理もしやすいし、何より障害ポイント増えなくていいかな?って思ってます。

だんだん下準備が終わってきました。

最後はバックアップ方針までやって、このパックで構築して始めればOK!最小構成まで落とすことも可能(予算などの影響)金ぶちこめばスケールできるも可能、それ以上になってきたらクラウドサーバー、特にMariaDBの場合、SkySQLというサービスがあるので、ライセンスのことも気にせずエンタープライズ版が使えますし、MaxScaleも使えちゃいますので、任せていくなどの、データベース環境のステップアップが明確になっていったらいいかなぁと思っています。

地味に、何度もデータベース作り直して実験してたどり着いているので、そのまとめに近いのがこの記事たちなんですが、正直・・・

「仕事でやりたくねぇ・・・」

って感想です笑

それは、単純にここまでの道のりで、パフォーマンスチェックから、この先のチューニング、バックアップ運用方針まで決めるのをゼロからやってたからです。ある程度2021年現在での鉄板パターンとして、後は、プロジェクトに応じて調整していくっていうものに慣れば良いかなと思っています。

最後までたどり着けるんだろうか笑

では、また。

最新の更新を
プッシュ通知で購読しよう