ホーム > Server

Serverのアーカイブ

ApacheのMaxClientsの設定とその挙動をまとめてみた

Check

ApacheのMaxClientsの設定とその挙動、mod_proxyの設定との関係について、なんとなくの理解だったので、まとめてみた。

環境

  • CentOS 5.6
  • Apache 2.2.3

MaxClients

MaxClientsを超えたコネクションがあった場合

ListenBacklog の設定までキューにたまる、とドキュメントにはあるが、実際に接続してみると、なぜかそれ以上に接続できた。
リクエストの処理を実行している(リクエストを受信し処理している)コネクションは、MaxClientsの値まで数、同時に処理されている(これをアクティブな接続と呼ぶことにする)。
リクエストの処理が開始された時点で、以下のエラーログが出力される。

[error] server reached MaxClients setting, consider raising the MaxClients setting

このログが出力されるには以下の条件がある。

  • コネクションのみの場合は出力されない。
  • 起動から初めて、MaxClientsを超えた時にだけログが出力される。
  • reload(sighup)後、MaxClientsを超えた時にはログは出力されない。
  • restart(sigterm)後、MaxClientsを超えた時にログが出力される。

アクティブなコネクションがMaxClientsの数ある状態から、MaxClients以下になった場合、待ちとなっていたコネクションが順次処理される。それ以外の接続は待ち状態のまま。

mod_proxy max

設定値についての注意点

  • preforkの場合、常に1となる。
  • workerの場合、設定が有効となる。ただし、1プロセスあたりのバックエンドへのコネクションのmax値。つまり、バックエンドサーバーとの最大接続数は以下の式で求められる数となる。

    ServerLimit * max

1プロセスあたりの接続数がmaxを超えた場合

  • retry * timeoutの間、待ちになる
  • retry * timeoutを超えた場合503が発生する

maxを超えた接続がある状態で、max 以下になった場合

順次実行される

DTI ServersMan@VPS Entryでunixbenchしてみた

Check

とってもいまさらな感じですが、DTIのServerMan@VPS Entryで、unixbenchを動かしてみました。

BYTE UNIX Benchmarks (Version 5.1.2)

System: dti-vps-srv06: GNU/Linux
OS: GNU/Linux — 2.6.18-164.15.1.el5.028stab068.9 — #1 SMP Tue Mar 30 18:07:38 MSD 2010
Machine: i686 (i386)
Language: en_US.utf8 (charmap=”UTF-8″, collate=”UTF-8″)
CPU 0: Intel(R) Xeon(R) CPU L5520 @ 2.27GHz (4522.1 bogomips)
Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
18:40:46 up 11 days, 2:20, 1 user, load average: 0.29, 0.10, 0.02; runlevel

————————————————————————
Benchmark Run: 金 9月 24 2010 18:40:46 – 19:14:15
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables 4156504.7 lps (10.0 s, 7 samples)
Double-Precision Whetstone 2138.6 MWIPS (10.3 s, 7 samples)
Execl Throughput 1461.9 lps (29.5 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks 172170.9 KBps (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks 46631.5 KBps (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks 368636.3 KBps (30.0 s, 2 samples)
Pipe Throughput 313563.3 lps (10.0 s, 7 samples)
Pipe-based Context Switching 98627.6 lps (10.0 s, 7 samples)
Process Creation 4646.2 lps (30.0 s, 2 samples)
Shell Scripts (1 concurrent) 1579.2 lpm (60.0 s, 2 samples)
Shell Scripts (8 concurrent) 224.7 lpm (60.2 s, 2 samples)
System Call Overhead 258911.3 lps (10.0 s, 7 samples)

System Benchmarks Index Values BASELINE RESULT INDEX
Dhrystone 2 using register variables 116700.0 4156504.7 356.2
Double-Precision Whetstone 55.0 2138.6 388.8
Execl Throughput 43.0 1461.9 340.0
File Copy 1024 bufsize 2000 maxblocks 3960.0 172170.9 434.8
File Copy 256 bufsize 500 maxblocks 1655.0 46631.5 281.8
File Copy 4096 bufsize 8000 maxblocks 5800.0 368636.3 635.6
Pipe Throughput 12440.0 313563.3 252.1
Pipe-based Context Switching 4000.0 98627.6 246.6
Process Creation 126.0 4646.2 368.7
Shell Scripts (1 concurrent) 42.4 1579.2 372.5
Shell Scripts (8 concurrent) 6.0 224.7 374.5
System Call Overhead 15000.0 258911.3 172.6
========
System Benchmarks Index Score 335.3

まー、予想通りな感じ。490円/月で十分ですな。

yumでエラーが出た時の対処法 その2

Check

前回のエントリーで、yumのエラーについて簡単に書いたが、もう少し詳細を記録する。

このblogは、DTIのServersMan@VPSというサービスの上で動作している。
メモリ256MB、ディスク10GBで490円/月額というびっくりな値段だ。
VPSというだけあって、root権限ももらえて、アプリも自由に入れられ、普通のホスティングサービスとは一線を画す。
CPUや、1サーバーあたりのユーザー数等は明記されていないが、今のところかなり快適だ。
だがしかし、256MBのメモリだけはいかんともしがたい。
このblog、WordPressを動かすために、apache、PHP、mysqlを動作させる必要があるが、
まず、yumでのインストール につまづいた。
yumを実行すると、以下のようなエラーが発生。

Loaded plugins: fastestmirror
Repository ‘vz-base’ is missing name in configuration, using id
Repository ‘vz-updates’ is missing name in configuration, using id
Determining fastest mirrors
Traceback (most recent call last):
File “/usr/bin/yum”, line 29, in ?
yummain.user_main(sys.argv[1:], exit_code=True)
File “/usr/share/yum-cli/yummain.py”, line 309, in user_main
errcode = main(args)
File “/usr/share/yum-cli/yummain.py”, line 178, in main
result, resultmsgs = base.doCommands()
File “/usr/share/yum-cli/cli.py”, line 349, in doCommands
return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds)
File “/usr/share/yum-cli/yumcommands.py”, line 626, in doCommand
return base.search(extcmds)
File “/usr/share/yum-cli/cli.py”, line 799, in search
for (po, keys, matched_value) in matching:
File “/usr/lib/python2.4/site-packages/yum/__init__.py”, line 1813, in searchGenerator
for sack in self.pkgSack.sacks.values():
File “/usr/lib/python2.4/site-packages/yum/__init__.py”, line 661, in
pkgSack = property(fget=lambda self: self._getSacks(),
File “/usr/lib/python2.4/site-packages/yum/__init__.py”, line 501, in _getSacks
self.repos.populateSack(which=repos)
File “/usr/lib/python2.4/site-packages/yum/repos.py”, line 232, in populateSack
self.doSetup()
File “/usr/lib/python2.4/site-packages/yum/repos.py”, line 79, in doSetup
self.ayum.plugins.run(‘postreposetup’)
File “/usr/lib/python2.4/site-packages/yum/plugins.py”, line 179, in run
func(conduitcls(self, self.base, conf, **kwargs))
File “/usr/lib/yum-plugins/fastestmirror.py”, line 181, in postreposetup_hook
all_urls = FastestMirror(all_urls).get_mirrorlist()
File “/usr/lib/yum-plugins/fastestmirror.py”, line 333, in get_mirrorlist
self._poll_mirrors()
File “/usr/lib/yum-plugins/fastestmirror.py”, line 376, in _poll_mirrors
pollThread.start()
File “/usr/lib/python2.4/threading.py”, line 416, in start
_start_new_thread(self.__bootstrap, ())
thread.error: can’t start new thread

このエラーは、どうもメモリ不足の時に起きるようだ。
そこで、メモリを確認すると以下。

Total: 262144k
Used: 142392k
Free: 119752k

現時点で、主に、
sshd, syslogd, xinetd, crond, mysqldが動作しているが、mysqldが136MBもメモリを使っている。
そこで、mysqldのメモリ節約設定を行う。
/etc/my.cnfを編集し、

skip-innodb

とし、再起動した。
すると、mysqldが47MBに激減。

Total: 262144k
Used: 53056k
Free: 209088k

これで、apacheやPHPも快適だ。
他にも、apacheの利用しないモジュールを外したりすることで、メモリを節約する設定とする。

yumでエラーが出た場合の対処法

Check

VPS環境で、yum installやyum updateであまり見たことの無いようなエラーが大量に出た場合、メモリ不足を疑ってみる。

メモリ256MBで、主なサービスとして、apache、mysql、sendmailが動作している状態ではyumは起動時にエラーを出した。
もちろん、各サービスを停止してから実行すればよいのだが、メモリ節約 を試してみる。やってみたことは以下。

  1. apacheの使っていないモジュールをロードしない
  2. sendmailをpostfixに変更
  3. mysqlで、InnoDBをoffに

一番効果があったのが、3のInnoDBをoffにすること。/etc/my.confに、「skip-innodb」とどこかに書けばOK。
もちろん、InnoDBが使えないということは、トランザクション等使えないということだけど、mysqlだからいいよね。

ホーム > Server

Tag cloud
Amazon
いろいろ

ページの上部に戻る