こんにちは、いなむーです。 今回はapacheのMPM（マルチプロセッシングモジュール）について、再度色々勉強したものをまとめておこうと思います。 （誤りがありましたらご指摘ください！） また、今回はMPMと言いつつも、preforkモデルの取り扱いが多いので、preforkに焦点をあてて調べていきます。 参考にしたサイトはこちら。 apache公式ドキュメント MPMとは 公式ドキュメント引用 スレッドを使わず、先行して fork を行なう ウェブサーバを実装しています。 スレッドセーフでないライブラリとの互換性をとるために、 スレッドを避ける必要のあるサイトでは、このモジュールの使用が適切でしょう。 あるリクエストで発生した問題が他のリクエストに影響しないように、 個々のリクエストを単離するのにも、最適な MPM です。 親となるプロセスをpre”事前”にfork”分岐”（複製）するのがprefork式です。workerでは、プロセスをforkせずにスレッド同士でメモリなどを共有するので、効率的に処理が行える反面、問題のあるリクエストがあった場合に、共有しているスレッド同士も影響が発生します。それを避けるのに適した方式がpreforkだと書かれています。 各ディレクティブについては様々なサイトで既に書かれていますが、自分用に残しておきます。 StartServers < ul> 起動時に生成される子サーバプロセスの数 動的に制御される MaxSpareServers アイドル状態のサーバープロセス数の最大個数を設定アイドル状態なので、リクエスト処理していないプロセスです。 リクエストが増えると、MaxClientsまでプロセスをforkしていきます。 アイドル状態のプロセスが、MaxSpareServersよりも多い状態になった場合は、その値までプロセスをkillしていきます。 MinSpareServers アイドル状態のサーバープロセス数の最低個数を設定これもアイドル状態なので、リクエスト処理していないプロセスです。 アイドル状態のプロセスがこの値よりも少なくなったら、プロセスは最高で1秒につき1個の割合で新しい子プロセスを生成するようです。 ServerLimit MaxClientsに設定可能な上限値 ServerLimitはデフォルトが256。 256よりも大きい値を設定する場合は、Maxclientsディレクティブよりも上に記述する必要がある。 workerモデルの場合に、ThreadsLimitと組み合わせてMaxClientsに設定可能な値を設定する。preforkの場合はServerLimitとMaxClientsの値をべつべつに設定する意味がないので、同じ値を設定しておくと良いように思います。### MaxRequestPerChild 個々の子プロセスが稼働中に扱うリクエスト数の上限 子プロセスがMaxRequestPerChildの値だけリクエストを受け付けると、プロセスからは終了する。各プロセスの遷移はこちらのメルカリのエンジニアさんが6年前に書かれた内容が大変分かりやすいです。 http://blog.nomadscafe.jp/2010/09/apachestartservers-minmaxspareservers-maxclients.html こちらに書かれている通り、forkはリソースを大変消費するため、StartServers,MaxSpareServers,MinSpareServersは値を同じにしておくと良さそうであるということには、納得と理解ができました。 しかしながら、MaxClientsについては、気になる記述があります。 正確にはMaxClientsではなく、ServerLimitで、 公式ドキュメント引用 このディレクティブを使用する際は特に注意してください。 ServerLimit が必要以上に大きな値に 設定された場合は、余計な未使用共有メモリが割り当てられます。

はてなブックマークを見ていたところ、下記エントリーを発見しました。 [blogcard url=https://tech.aucfan.com/rm-rf-retrieval/] 彼は新卒研修時に誤って消してしまったファイル郡を自力で復元したという強者のようですが、インフラ屋さんとしては、使うことがなかったとしても（使いたくない。。。）、知っておいて損は無いなと思い、全く同じように検証してみました。 まずは事前に準備しておきます。 環境　CentOS6 ファイルシステム ext4 ext3,ext4にのみ対応しているようです。xfsは非対応の様子というか復元不可能？ $ yum -y install e2fsprogs-devel これが無いとコンパイル時に怒られます。 extundeleteをダウンロードして、ホームディレクトリへ保存しておきます。 コンパイル手順です。 $ tar xfvj extundelete-0.2.4.tar.bz2 $ mkdir ~/mytmp $ ./configure --prefix=/home/kazuma/mytmp Configuring extundelete 0.2.4 Writing generated files to disk $ make && make install make -s all-recursive Making all in src extundelete.cc:571: 警告: unused parameter ‘flags’ Making install in src /usr/bin/install -c extundelete '/home/kazuma/mytmp/bin' $ ls -l ~/mytmp/bin/extundelete -rwxr-xr-x 1 kazuma kazuma 1187055 4月 10 23:53 2016 /home/kazuma/mytmp/bin/extundelete 以上でコンパイルが完了です。

今日、自宅のNASのファームウェアのアップデートをしたところ、DLNAサーバーとして利用していたmediatombが起動しなくなりました…orz もともとmediatombは自宅サーバーがNASをNFSマウントしてまして、その配下の音楽ファイルをmediatombでスキャンしていたのもあり、どうやらNASの再起動とともにおかしくなってしまった様子。 そこで調べたら解決できたのでメモとして残しておきます。  ちなみにmediatombのインストール手順については下記を参照してください。 [blogcard url=”http://wiki.inamuu.com/index.php?mediatomb%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB”][/blogcard]  まず、気が付いたのはタブレットからmediatombが見えなかったときに気が付きました。 自宅サーバーのログを調べてみると could not load correct lastID (db not initialized?) こんなエラーが出ておりました。そのまま、/etc/init.d/mediatomb startを実行してもどうやら起動していない様子。 調べてみると、下記サイトにDBデータを削除しろとのこと。 参考にしたURL どうやらmediatomb自体はスキャンしたデータをDBに保存しているだけで、アプリケーションの起動自体はDBは要らないようです。 上記サイトではSQLiteを利用した想定だったので、私の場合はMySQLで同じことをしました。 # mysqldump -u root -p mediatomb | gzip > mediatomb.`date +%Y%m%d`.sql.gz # mysql -p mediatomb -e “show tables” | xargs -IARG mysql -p mediatomb -e “drop table ARG” 上記SQLでmediatombデータベース内のテーブルをすべて削除しています。 テーブルごとにパスワードを入力する必要があるので、面倒であれば-pの後にパスワードを直接書いてしまった方がよいかもしれません。 ※パスワードの入力履歴を削除したければ.bash_historyから削除するか、そもそもシェルスクリプトにしてしまうのもありかと思います。 テーブルを消した後に、/etc/init.d/mediatomb start を実行したところ、ログには 2016-02-06 22:51:34 INFO: Configuration check succeeded. 2016-02-06 22:51:34 INFO: database doesn’t seem to exist.

経緯 最近読んでいる「プロのためのLinuxシステム・10年効く技術」にRedhat6以降からcgroupというリソース制御の仕組みが利用できるようになったのを拝見しました。 また、ペパボ福岡支社のインフラエンジニアの方の「次世代ホスティングの話し」にもcgroupのことが書かれていたので、せっかくなので検証してみることにしました。  パッケージのインストール # yum install libcgroup # chkconfig cgconfig on # service cgconfig start  事前確認 ddでチェックしてみます。2GBのファイルを作成してみます。oflag=directでキャッシュを無効にしています。 # dd if=/dev/zero of=test.img bs=1K count=2000000 oflag=direct # top <–別シェルで実行 Tasks: 127 total, 3 running, 124 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 2.4%sy, 0.0%ni, 0.0%id, 94.0%wa, 2.4%hi, 1.2%si, 0.0%st Mem: 1020176k total, 305056k used, 715120k free, 6540k buffers Swap: 1036284k total, 0k used, 1036284k free, 128060k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

経緯 ECCUBEを利用しているサーバーでペイジェントモジュールを利用していたところ、ペイジェントより、12月からモジュールサーバーのSHA2対応をするという通知が送られてきました。 素のCentOS6系でyumでPHPやらOpenSSLをインストールしている場合は、ペイジェントモジュールの証明書ファイルの差し替えのみでOKのようですが、CentOS5系でOpenSSLやPHPをyumでインストールした場合はソースからコンパイルが必要になります。 理由としては、CentOS5系のPHPにはすでにOpenSSLのモジュールが組み込まれており、yumでインストールされたOpenSSLをいくらアップデートしても、PHPの方には影響が無いという理由があります。 また、OpenSSLはCentOS5系の標準だと、openssl-0.9.8eまでしかアップデートできません。 なお、openssl-0.9.8e-18で下記のような記述がありますが、 * Thu Mar 10 2011 Tomas Mraz <tmraz@redhat.com> 0.9.8e-18 <pre> - add SHA-2 hashes in SSL_library_init() (#676384)</pre> デフォルトでは有効ではないようで、sha2がデフォルトで使用できるようになっているのはopenssl-0.9.8o以降からのようです。 なので、OpenSSLを0.9.8o以降でコンパイルし、それを指定する形でPHPもコンパイルが必要です。 その手順を下記に記載しますので、参考になると嬉しいです。 ※慣れていない場合はVagrantなどを活用して、何度か手順を確認しつつ、ご自身のサーバーに合った方法に書き換えていただけると良いかと思います。 バックアップ # cd /etc/ # cp -p php.ini php.ini.`date +%Y%m%d` # cp -rp php.d php.d.`date +%Y%m%d` # cp -rp /usr /usr.`date +%Y%m%d` 事前にインストール # yum install bzip2* libcurl* curl-devel pcre* db4-devel libjpeg* libpng* freetype* gmp* libc-client-devel openldap-devel mysql-devel ncurses-devel unixODBC-devel postgresql-devel sqlite-devel aspell-devel libxslt libxslt-devel net-snmp net-snmp-devel flex krb5-devel httpd-devel

最近サーバーの移行案件が増えてまして、一ヶ月で何台かやらなくていけず、残業ばかりの私です。 そんな中数ヶ月前からAnsibleを導入したのですが、Ansibleの運用に伴って、良かった点と悪かった点を書いてみます。  良かった点 やはりOSのセットアップやミドルウェアのセットアップが格段に楽になりました。 新規でサーバーのセットアップを実施する場合はもちろんですが、後から特定のミドルウェアの導入が必要になった場合に、最低限の基本的なセットアップをAnsibleで流し込めたりします。 また、1時間くらいの作業を10分くらいに短縮できてるので、時間短縮になってるのと、Ansible実行中は他の作業ができるのでとても効率化がはかれます。 加えて、設定に統一性が生まれるので、同じ構成のサーバーが簡単につくれるのと、何かあった時に構成の理解に時間が要さなくなります。 他には、複数台のサーバーにデプロイできるので、複数台のサーバー上で動いている不要なサービスを止めたり、パッケージのアップデートしたり、特定のシェルスクリプトを流しこんだり、とにかく作業が効率的になります。  悪かった点 トラブルが発生すると(なぜか実行できないとか)、Ansibleのトラブルシューティングに時間がかかり、効率が悪くなることです。 また、◯◯を実行するのに、当たり前ですがAnsibleを実行するための設計書であるplaybookの書き方を調べる必要がありますし、playbookで使用できるAnsibleのモジュールはとても便利ですが、動作の癖を知らないと面倒になる場合があるので、その辺の学習コストはどうしてもあがります。  まとめ ツールは良し悪しですし、他にもChefやPuppet、itamaeなどもありますのでAnsibleに固執することなく自分にとって使いやすいところだけ利用できたら良いですね。  以上。  

昨日はとあるサーバーの移行に伴ったトラブルの対応をしてました。 そのシステムはMovable Typeで記事が作られて、WordPressで一つのシステムが動き、ECCUBEでメルマガ管理して、資料検索はnamazuというサーバーでした。 CentOS5 32bitからCentOS6 64bitへのジャンプアップでしたので、ミドルウェアはパッケージ管理でしたがなかなかにトラブルに見舞われました。 そのなかでも一際目立ったのがnamazuによる資料検索。 そもそもnamazuの仕組みがわかっていなかったのと、ググっても出てくる記事はどれも古いのでなかなかに悩まされました。 結果的にはxpdfとxpdf-japanese、kakashi、namazu-2.0とnamazu-2.3(PHPのダイナミックモジュールnamazu.soを作る目的)を再コンパイルしたらいけました。 コンパイルされているソフトウェアはサーバー移行する際に、パスとコンパイル時に必要なモジュールに気をつけようと思います。 以上。

うちの会社には事業の一つとして、レンタルサーバー事業のインフラ周りの運用や構築があります。 運用は私が率先として実施しているので、よくこんなお問い合わせを受けることがあります。 – ユーザーさんからある宛先にメールしたけど、届いていないようだから調査してほしい。 – メールがエラーで返ってきてしまった。 – 迷惑メールが大量に送信されている可能性がある。 – メーリングリスト宛に送ったら、一部の宛先にとどかない。 などなど、今回はメールだけ書きましたが所謂レンタルサーバーにありがちなお問い合わせが多数上がってきます。 調査するときはとってもアナログでそれぞれのサーバーにログインして、シェルのワンライナーをコピペしまくるわけです。 とっても非効率なので、なんとかならないものかと調べてたところfluentdにたどり着きました。 そこで、まずはログを集約して、perlなりシェルスクリプトで調査を楽にすることを目的として検証することに。 これがとても便利で、かなる簡単に導入することができるのがわかり、本番サーバーの幾つか限定して導入してみました。 容量に余裕ありまくるバックアップサーバーを受け口として、ログを転送させてみてます。 fluentdはリアルタイム性が低い代わりに、サーバー負荷を減らし、ある程度バッファにためてログを転送してくれます。 これはインフラエンジニア的にはすっごい助かりますね。iowaitで死んだとかたまにあるので、ログ集約で負荷とかかけたくないですし。 実際に動作みてもイイ感じです。 バッファためるので本当に取れてるか不安になりますが、ちゃんと取れてます。 はい、その通り。 できたらmongodbにつっこんだり、elastic searchに渡してkibanaで表示させたりしたいですが、まずは集約して使ってみることですね。 細かい話しはいずれ。 以上です。

fluentdを使いはじめたのですが、apacheログを別のサーバーへ転送させてみてる場合、apacheログがローテーションされてもちゃんとローテーションされるのか検証してみました。（とっても初心者なのでこんな検証からやりはじめてます。。。） 環境 Vagrantで稼働しているCentOS6のサーバー2台 送信元が192.168.33.10、受信側が192.168.33.11 送信元のtd-agent.conf type tail path /var/log/httpd/*access_log pos\_file /var/log/td-agent/access\_log.pos tag httpd.access format apache2 type forward host 192.168.33.11 受信側のtd-agent.conf type forward type copy type file path /var/log/td-agent/web01/httpd_access.log 検証 送信元のapacheログを強制的にローテーション。 # logrotate -f /etc/logrotate.d/httpd するとtd-agent.logには下記のようなinfoログが吐かれます。 2015-11-07 18:47:42 +0900 [info]: detected rotation of /var/log/httpd/stage.example.com-access_log; waiting 5 seconds 2015-11-07 18:47:42 +0900 [info]: ected rotation of /var/log/httpd/www.example.com-access_log; waiting 5 seconds 2015-11-07 18:47:43 +0900 [info]: following tail of /var/log/httpd/www.

ちょっとVagrantのことで調べ物していたところ、こんな記事を見つけました。 http://www.kunitake.org/chalow/2012-11-02-1.html まとめると、CentOS5系の名前解決とCentOS6系からの名前解決のIPv4とIPv6の結果について、応答の順番が変わることで、名前解決に時間がかかる場合があるということです。 CentOS5系はAAAAレコード(IPv6)の要求を実行して、応答結果を受けて、その後にAレコード(IPv4)の要求->応答だったようです。 しかしCentOS6系からはAレコードとAAAAレコードを投げて、その後にそれぞれの要求が返ってくるようです。 しかし、Firewallの中には同じポートのクエリを同じセッションとみなして、IPv6が設定されていないサーバーへの応答ができないことで、IPv4の応答も返さず、Aレコードのクエリを再送するということらしいです。 なにはともわれ、検証してみることにします。 ◆オプションをつける前 # cat /etc/redhat-release <–CentOS6系であることを確認 CentOS release 6.7 (Final) # cat /etc/resolv.conf <–まずはオプション無し nameserver 8.8.8.8 nameserver 8.8.4.4 # yum clean all <–キャッシュを削除 # time yum search php54 –enablerepo=epel,repo <–PHPを検索 ※3回ともyum clean allを実施 [1回目] real 0m9.618s user 0m2.430s sys 0m0.215s [2回目] real 0m6.825s user 0m2.435s sys 0m0.244s [3回目] real 0m9.713s user 0m2.430s sys 0m0.209s ◆オプションをつけた後 # echo “options single-request-reopen” » /etc/resolv.conf # cat /etc/resolv.conf