CentOS 7 初期設定でやっておきたいこと(随時更新予定)

CentOS 7をインストール後にやっておきたいこと

CentOS 7をインストールした後に、そのまま使うには面倒なところがありますよね。
そこで、インストール後にやっておきたいことを幾つか記録しておこうと思います。
私の個人的な趣向もありますので、皆さんの環境に合わせて参考になれば幸いです。

なお、CentOS 7自体のインストール方法については、他を参照してください。
以前に書いた様な覚えもありますが、インストール方法に関しては割愛します。

さて、本題のインストール後に行ておきたい初期の設定に関してですが、この記載内容は適宜更新します。
よって、初期の段階でご覧になられた方は、これだけじゃ足りないじゃないか!?と思われる方もいらっしゃるかと思います。
参考情報ですから、基本はあまり期待しないでくださいね。

bashを使いやすくしておこう!

CentOS 7のシェルはbashが基本となっており、昔に比べると随分使いやすくなりました。
昔と言いましても10年以上昔の話なので、ご存知ない方も多いかと思いますが。。。(^^ゞ

VPSなどプロバイダが提供されている環境では、既に独自の設定が為されているところもあり、自分でインストールした場合とは異なったりします。
既に設定が為されている場合もあるようなので、必要ない場合もありますが、コマンドの補完を行ってくれるようにしておきたいです。

コマンドの補完

bashのコマンドを補完してくれる機能は、インストールされた環境によりまちまちであったりします。
まったく補完がされないことを前提に設定を行います。

まずは大文字/小文字を含めた補完を行ってくれる機能を有効にします。
rootユーザとして作業を進めます。
ホームディレクトリに以下のファイルを作成します。

この1行だけのファイルが重要なんです!
/etc/inputrcに記載しても良いはずです。

有効にするにはログインし直すか、以下のコマンドを実行してみてください。

これで反映されると思います。反映されない場合は、再度ログインし直してみてください。
大文字/小文字も含めたコマンドの補完が行われるようになっていると思います。
例えば、以下のコマンドを自動的に保管されるはずです。

ここまでは序の口です。更に補完機能を強化したいと思います。
続いて、以下のコマンドを実行してbashの補完機能を更に強化するパッケージをインストールします。

これを入れることで、コマンドのオプションなどが補完されるようになるんです。
例えば、systemctlのオプションをタブキーを使って補完することが出来る様になります。
ただし、インストール後に再度ログインを行う必要があります。

aliasについては好みがありますから、.bashrcにaliasを適当に追加しますが、今夏何時でbash周りは終わりかな?

ファイルの平均サイズ計算・最大・最小サイズの確認 for Linux

備忘録のつもりで平均だけを計算する簡単なメモにしようと思ったのですが、最大値も出してみようか?最小値もとかやってみたのです。
今更ながらawkの有り難味を感じながら。。。。w(←今更awkかよ!?)

Linux環境で 指定フォルダー以下にある特定ファイルの 以下の情報を調査します。

  • ファイルの平均サイズ
  • ファイルの最大サイズと最小サイズ

ファイルの平均サイズ

解り易いように、lsの部分を少し展開してみたコマンドは以下の通りです。

findやlsコマンドで個々のファイルサイズを表示させて、そのサイズ部分だけをawkで抜出し、合計値(s)を計算するのとそのファイル数(n)をカウント。
最後に合計値(s)/ファイル数(n)で平均値を計算しています。

合計値を取りたい場合には、ファイル数(n)で割らなければ良いだけです。
一定期間のファイル数やファイルサイズなども、findで探すファイルを限定することで計算出来ますね。
※ファイルサイズが0のファイルもファイル数としてカウントされます。

ファイルの最大サイズと最小サイズ

ファイルの最大サイズと最小サイズを確認するコマンドは以下の通りです。

少し細工をしています。取り出したファイルのサイズが0の時はそのサイズを無視しています。

合わせ技!

大したことはありません。ただ単純に、上記の両方を一気に計算してしまおうという話です。
ただし、ファイルサイズが0のファイルは無視します。つまり、平均ファイルサイズの対象からサイズが0のファイルは除かれますので、上記の方法とは少し異なります。

こんな感じです(^^♪
しばらく使わないとすぐに忘れてしまうので、備忘録大事ですねw

WordPressに「いいね」ボタンを追加

WordPressに「いいね」ボタンや「ツイート」ボタンを追加しようと思います。
幾つか方法があるのですが、私が面倒くさがりなので、プラグインで対応しました。
簡単に追加出来ちゃったのですが、問題が・・・「いいね」になって欲しいボタンが「Like」になっていました。
対応を行いましたので、簡単に紹介します。

プラグインの追加

使用したプラグインは「WP Social Bookmarking Light」です。
WordPressでプラグインを追加してください。

「設定」→「WP Social Bookmarking Light」で設定画面が表示されます。

図1 WP Social Bookmarking Light初期設定画面

「Like」→「いいね」に変更する。


「Like」を「いいね」に変更するには、英語表記を日本語表記に変更する必要がありました。

FBタブを選択し、以下の画面を表示します。

図2 FB設定画面

既に変更してありますが、Localeの項目を「en_US」(デフォルト)から「ja_JP」(日本語)に変更し、「変更を保存」とします。

以上で設定完了です。
やってみると簡単だったのですが、この設定が見つからなくてしばらく放置していました。
私の様に悩んでいる人は少ないと思いますが、ご参考までに。

Apache(Webサーバ)のチューニングとベンチマーク

ここでは、Apache HTTP Serverのチューニングとベンチマークに関してまとめます。

Apacheのベンチマーク

Apacheの性能はサーバの性能にも左右されますが、Apacheの設定内容によっても変わってきます。
最近のサーバはそこそこ速くなっているので、デフォルト設定のままでもそこそこ速く動いてくれるのですが、それでもアクセス集中対策を考慮するにはサーバのApacheのチューニングも必要になります。

さて、チューニングの方法は説明する前に、性能測定の方法について説明します。

Apacheの性能測定には、ab(Apache Bench)コマンドを使用します。

色々なサイトでも紹介されていますが、基本的なコマンド操作は以下の様になります。

-n 数値  : リクエストの総数
-c 数値  : 同時接続数

指定したURLに対し「リクエストの総数」分のリクエストを行います。並列して接続するため、「同時接続数」を指定することが出来ます。

試しにabコマンドを叩いてみます。(URLは適当です。)
※絶対に他人のサイトを指定しないでください。DoS攻撃とみなされる可能性があります。負荷試験の一種なので、対象のサーバに高負荷を与えることになります。

ここで注目したいのは、以下の2点です。
Failed requests: 0
Requests per second: 134.39 [#/sec] (mean)

「Failed requests」でリクエストがフェールになった回数をカウントしています。Failが発生しない様に調整する必要があります。

では、調整の仕方を見ていきましょう。

Apacheのチューニング

Apache 2.2系と2.4系ではチューニングの設定が少し異なります。パラメタの名称が一部変更になっているためです。
以下にそれぞれのパラメタ設定例を示します。
ただし、この設定内容は環境により異なりますので、ご自身のサーバ環境によって値を調整してみてください。

Apache2.2系のチューニングパラメタ

Apache 2.2系のチューニング方法を以下に紹介します。今更感はあるのですが、最も効果的な結果が得られたのがこの環境だったので敢えて事例紹介します。

対象ファイル:/etc/httpd/conf.d/httpd.conf

viなどで開いて編集してください。

こちらがデフォルト状態の設定状態です。

こちらが設定変更後の値です。

StartServers1起動時に生成される子サーバの数
MinSpareServers1アイドル状態で待機している
子サーバの最小数
MaxSpareServers5アイドル状態で待機している
子サーバの最大数
ServerLimit10MaxClientsに指定できる上限値
MaxClients10同時接続可能なクライアントの数
MaxRequestsPerChild4000子サーバが処理できる
リクエストの総数

デフォルトの状態では、StartServersが「1」になっていたので、最初の接続に掛かる時間が遅くなる傾向にありそうです。
また、MaxClientsが「10」しかないため同時に処理できるリクエストの数が少なく、こちらも処理が遅くなる傾向にあったようです。
変更後の値に設定し、以下のコマンドでWebサーバを再起動します。

Webサーバの再起動が完了したら、コマンドを実行して動作を確認してみましょう。

主要な内容については以下の通りです。

Failed requests: 0
Requests per second: 601.08 [#/sec]

「Requests per second」の値が134.39→601.08に変化しており、1秒間に処理で来ているリクエストの数が大幅にアップ(約4.5倍)しました。

と、ここで問題です。
MaxClientsを適当にしていしましたが、子サーバ(プロセス)が使用するメモリを考慮して計算しないと、実装メモリよりも多くの子サーバが起動してしまうことになってしまいます。
そうなると、スワップ領域まで達し、最終的にもメモリ不足に陥ることになります。
まず、httpdプロセスがどれ位のメモリを使用しているか?そして、PHPを使用しているならば、PHPの利用するメモリも考慮する必要があります。
実際にサーバ上で動作する際に必要となるメモリ量も気に掛かります。

面倒ですよね。
色々な方が作られている様ですが、MaxClientsを自動計算してくれる仕組みがあります。
その方法について、次に説明を行います。

MaxClientsの自動計算

MaxClientsを自動計算する方法について記載します。
Apache Web Service(Webサーバ)は、並列処理を実現するために複数子サーバを起動して、同時に複数のクライアントから要求されるリクエストに対応します。
その最大値をMaxClientsで指定します。

理論的には、httpd(子サーバ)が利用するメモリとPHPが利用するメモリで1つのクライアントから要求される処理を行うとして、システムのメモリを割ることで値が得られる感じです。
この時、システムでそれ以外に使用するメモリも考慮する必要があり、意外と面倒な計算と情報収集を行うこととなります。

それを自動化してくれる仕組みが以下のサイトにあるスクリプトになります。

https://github.com/richardforth/apache2buddy

apache2buddyを利用してMaxClientsを計算させるには、以下のコマンドを実行し、表示される情報を利用します。

コマンドは以下に記していますが、上記のURLで示されたサイトに記載がありますので(英文ですが)、そちらを参考にされることをお勧めします。(本記事が古くなると使えなくなりますが、上記サイトはメンテナンスされていますので)

重要な箇所は以下の一文です。

Your recommended MaxClients setting (based on available memory) is between 33 and 37. <——- Acceptable Range (10% of MAX)

httpdを再起動した直後などは正確な数値が得られない場合がありますので、本来は24時間程度運用した状態で数値を計算することが望ましいです。

上記の例では、MaxClientsの値として33~37が望ましい値として提示されています。

正直、実験を行ったサーバでは、長時間のヒートランを行っていなかったのでこの値が示されましたが、本来であればもっと少ない値が得られるのではないかと思います。

これを元に、先程示したhttpd.confに記載されている以下の値を調整します。

StartServers
MinSpareServers
MaxSpareServers
ServerLimit
MaxClients
MaxRequestsPerChild

最後に、Webサーバの再起動を行えば設定が反映され安定した動作になると思います。こまめにチェックするというよりも、ある程度時間を空けてチェックすると良いと思います。

apache2buddy以外にも自動計算や手動計算の手法が幾つか紹介されています。
自分に合った方法を見つけることが重要です。
今回の手法は、Linux上での手法となります。Windows上での計算は難しいかな?

incronで起動したプロセスがdefunct(ゾンビ)で残る障害対策

CentOS 7上で2018年12月頃にincronでバグが発生した。

psコマンドを叩いてみると、「defunct」で示されるゾンビプロセスが大量に発生している!

当然のことながら放置すればシステムは暴走しかねない状況にある。
さて、どうしたものか?と思いながら、ゾンビプロセスを殺そうと試みるもkillコマンドでプロセスを殺すことが出来ない。
何故だろう?とその親プロセスを見てみると「incron」が親になっている。

そうこうしている間にもゾンビは増え続けているではないか!?

incronを殺す・・・と言ってkillする必要はないので、以下のコマンドを実行してincronを再起動させてみる

ここでプロセスを確認してみる。

発生していた「defunct」は一掃されゾンビプロセスは綺麗にその姿を消していた。

原因はどうやら「incrond」にあるらしいことまでは、これで特定出来たのだがどうにかならないかと思いながらインターネットを検索するもそれらしき情報がヒットしない。。。しばらくして辿り着いたのが以下のRedHat Bugzillaだった。

https://bugzilla.redhat.com/show_bug.cgi?id=1656939

どうやらincrondのバグが確認されているらしい。
対処方法は、古いソースを入手してリコンパイル&インストールすることになる様だ。当然、現在のincrondを削除しなければならない・・・ということは、設定をメモして云々・・・・(嫌だ!)

そうこうしている間にも、defunctは増え続けていた。
以下のコマンドを実行すると、その数が解る。

出力された数値の左端がその数です。

考えたこと

幾つか対策を考えた

  1. ソースからビルドしてインストールし直す。
  2. 古いバージョンに戻す。
  3. 定期的にincrondを再起動してその場凌ぎをする。

1.ソースからビルドしてインストールし直す

この方法、一見確実な方法である様だが、後にincrondが更新された時にyumで出来要することが出来なくなってしまう。セキュリティホールなどの対応が疎かになってしまう可能性もある。
メンテナンス性が悪いんだよね。出来ればバグ修正が成されたバージョンが提供されるまで待ちたいところなのだが、私の環境下では緊急を要する状況にある。
だめだぁ~( ゚Д゚)

2.古いバージョンに戻す。

では、古いバージョンでは問題が発生していなかったので、バージョンを戻してやろう!
ということで、以下のコマンドで戻せるかチェックしてみる。

残念ながら、古いバージョンのincronは使えそうにない。
もし存在してくれていれば、こんな感じで対応が出来る。

実際やってみると解るが、今回の場合は古いバージョンが存在せず、結果「なにもしませんでした」という寂しいコメントが最後に記されるだけです。

3.定期的にincrondを再起動してその場凌ぎをする。

結局この方法に辿り着きました。

incrondにより生成されたゾンビプロセスは、incrondを再起動することにより削除されていましたので、crondでincrondを定期的に再起動してやることにしました。

まずはcrontabを起動して、定期的にコマンドを実行します。

これで、深夜0時00分にincrondが再起動します。

最後に

この現象は、CentOS7でしか発生していないみたいで、CentOS 6では古いバージョンが使えわれており問題は発生しない感じです。

また、incrondという特殊なパッケージを使っているので、この件に関して悩んでいる人は少ないでしょう

次のバージョンアップで更新されるでしょうし、需要は少ないと思っています。

とは言え、私の備忘録代わりに残しておきます。