スペックアップ時のパラメータ周り
こんにちは、技術部のKです。
今回はサーバのスペックアップ時の考慮点や、普段エンジニアがどのようなパラメータチューニングをしているかなどを紹介したいと思います。
オンプレミスと比べてクラウドサーバだとスペックアップ、つまりCPUやメモリの増設が容易かつ柔軟に可能になっています。
皆様もサーバ運用において、アクセス増加等や処理能力の増大を目的として、スペックを適宜変更する運用をしているかと思います。
パラメータの重要性について
ですが、単純にCPUやメモリを増やしただけでは、そのパフォーマンス効果を発揮できないことはご存じでしょうか?
Apache、Nginx、MySQL等の各種サービス、またOS自体にも様々なパラメータ制限が標準で存在します。
リソースを食いつぶさないように上限が決まっているのです。
ですので、そのスペックに見合った設定値の引き上げを考慮し、適切なチューニングが必要となってきます。
一例として、サーバへのアクセス増加に備えることを目的としたスペックアップ場合に、
・どんな観点で、どのようなチューニングが必要なのか?
を見ていきたいと思います。
チューニングするパラメータの項目
先に書いてしまいますが、以下のような観点が挙げられます。
・各サービスの接続数上限
・オープンファイル数の上限
・TCPコネクションのソケット枯渇対策
注:Linux系OSのお話です。
何やらたくさんあるな…と感じるかと思います。
見ていきましょう。
Apache、MySQLパラメータ
ApacheやMySQLには、最大同時接続数というパラメータがあります。
Apacheだと、MaxClients や MaxRequestWorkers
Nginxだと、worker_connections
MySQLだと、max_connections
それぞれこの最大値に到達すると、いわゆる 詰まる という状態になり、処理が滞留することになります。
チューニングの観点としては、
増加したメモリサイズに対して、最大値をどこまで引き上げられるか?
となります。
もちろん闇雲に引き上げるのではなく、
例えばApacheですと、正確にはプロセスの最大個数ですので、1つ1つのプロセスのメモリ使用量を考慮しつつメモリが逼迫しない数値を計算の上、設定していきます。
もちろん、これらのパラメータだけ調整すればいいというものでもありませんが、この辺りのパラメータに関してはお客様でもよく目にするものかと思います。
ここからは少し見落としがちな部分になります。
オープンできるファイル数上限(ファイルディスクリプタ)
小規模な運用の場合はあまり気にせずとも問題にはなりませんが、こちらもスペックアップ時に引き上げることがあります。
そもそもファイルディスクリプタとは?
ファイル記述子…
プログラムがアクセスするファイルや標準入出力などをOSが識別するために用いる識別子…
WEB検索では何やら難しい言葉がつらつらと出てきますが
1プロセスが同時に使用できるファイルの最大数と理解していれば差支えは無いようです。
Apacheを例とすると上述の接続最大数1024以上に引き上げる場合に考慮します。
以下のように標準で1024となっています。
# cat /proc/`pgrep --parent 1 -f httpd`/limits
Limit Soft Limit Hard Limit Units
...........................................................................
Max open files 1024 262144 files
...........................................................................
この時点で1プロセスが同時に使用できるファイル?となりますが、仮にApacheの1プロセスを見ていくと、1プロセスでログファイルや、TCPソケット、プロセス同士を繋ぐpipeなどで同時に複数のファイルを使用していることが分かります。
# ps aux | grep http
root 5624 0.0 2.5 485940 26036 ? Ss 06:45 0:02 /usr/sbin/httpd -DFOREGROUND
apache 5630 0.0 1.9 486208 19676 ? S 06:45 0:00 /usr/sbin/httpd -DFOREGROUND
apache 5631 0.0 1.9 486208 19432 ? S 06:45 0:00 /usr/sbin/httpd -DFOREGROUND
apache 5632 0.0 1.9 486208 19428 ? S 06:45 0:00 /usr/sbin/httpd -DFOREGROUND
apache 5633 0.0 1.9 486200 19516 ? S 06:45 0:00 /usr/sbin/httpd -DFOREGROUND
apache 5634 0.0 1.9 486208 19688 ? S 06:45 0:00 /usr/sbin/httpd -DFOREGROUND
apache 6051 0.0 1.9 486208 19680 ? S 07:10 0:00 /usr/sbin/httpd -DFOREGROUND
apache 32476 0.0 1.9 486200 19500 ? S 15:50 0:00 /usr/sbin/httpd -DFOREGROUND
# ls -l /proc/5624/fd/
合計 0
lr-x------ 1 root root 64 9月 29 06:45 0 -> /dev/null
lrwx------ 1 root root 64 9月 29 06:45 1 -> socket:[221751671]
l-wx------ 1 root root 64 9月 29 06:45 10 -> pipe:[221751719]
l-wx------ 1 root root 64 9月 29 06:45 11 -> /var/log/httpd/testdomain.com.error_log
l-wx------ 1 root root 64 9月 29 06:45 12 -> pipe:[221751720]
l-wx------ 1 root root 64 9月 29 06:45 13 -> /var/log/httpd/ssl_error_log
l-wx------ 1 root root 64 9月 29 06:45 14 -> /var/log/httpd/access_log
lr-x------ 1 root root 64 9月 29 06:45 15 -> pipe:[221751721]
l-wx------ 1 root root 64 9月 29 06:45 16 -> pipe:[221751721]
l-wx------ 1 root root 64 9月 29 06:45 17 -> /var/log/httpd/testdomain.com.access_log
l-wx------ 1 root root 64 9月 29 06:45 18 -> /var/log/httpd/ssl_access_log
l-wx------ 1 root root 64 9月 29 06:45 19 -> /var/log/httpd/ssl_request_log
l-wx------ 1 root root 64 9月 29 06:45 2 -> /var/log/httpd/error_log
lrwx------ 1 root root 64 9月 29 06:45 3 -> socket:[221751680]
lrwx------ 1 root root 64 9月 29 06:45 4 -> socket:[221751681]
l-wx------ 1 root root 64 9月 29 06:45 5 -> /var/log/httpd/modsec_debug.log
l-wx------ 1 root root 64 9月 29 06:45 6 -> /var/log/httpd/modsec_audit.log
lrwx------ 1 root root 64 9月 29 06:45 7 -> socket:[221751692]
lrwx------ 1 root root 64 9月 29 06:45 8 -> socket:[221751693]
lr-x------ 1 root root 64 9月 29 06:45 9 -> pipe:[221751719]
少なくとも接続最大数の数倍にする例が多いです。
TCPコネクションのソケット枯渇対策
こちらは以下のカーネルパラメータ、と言われるOSレベルのパラメータです。
説明がなかなか難しいですが、以下の解釈をしております。
net.core.somaxconn ……………… 接続確立済のTCPコネクション数の上限値 (ESTABLISHED状態の接続上限値)
net.ipv4.tcp_max_syn_backlog … 処理待ちのTCPコネクション数の上限値 (SYN_RECEIVED状態の接続上限値)
こちらも標準では低い値になっていますので、大量の接続が見込まれる場合は引き上げをすることでソケット枯渇を防ぐ、つまりTCPコネクションの取りこぼし防止になります。
最後に
以上、今回は割と一般的に考えられる観点を見ていきました。
※各パラメータの変更方法は割愛しています。
しかし、実はこれで万事OKということではありません。
パフォーマンス効果を発揮するにはスペックに併せて各種様々なパラメータの最適化が必要となってきます。
お客様でも障害発生時や高負荷時のボトルネック発見に手こずっていたりしておりませんでしょうか?
経験が豊富な弊社であれば、様々な事例から最適なパフォーマンスを引き出すことが可能です。
ぜひ弊社にお任せ下さい。
どうぞ今後ともネットアシストをよろしくお願い致します。