---
# System prepended metadata

title: Apacheチューニング指標

---

# Apacheチューニング指標

現状：
サーバのスペックは高いが、適切にサーバのパフォーマンスが出せていない。
![](https://i.imgur.com/AT7xyaO.png)

### Topによって解析をしていく。

load averageが常に１以上だったならチューニングの必要性あり！
```
load average: 3.22, 3.22, 3.19
```
![](https://i.imgur.com/pmDZadD.png)

> 1~3黄色信号。このあたりで重さを感じ出します。軽微なチューニングでストンッと0.3-0.5あたりに落ちる場合も多い。

CPUも1部のCPUのみが使用されている。

- ゾンビのプロセスが時より発生する。1 zombie
- rubyが使用しているPIDで3つほど張り付いてるプロセスがある。

## 解決策

どこかでサーバの最適化をしないといけない。
Apacheなのか、プログラムなのか（並列処理）、サーバを増やして負荷分散するのか（Dokcer,ECS）？

### Apacheチューニング
- マシン上でpassengerが利用できるメモリ量 = 124g

- 実際のメモリ使用ではなくて仮想メモリの値を採用する。
→理由はスワップを使用すると遅くなるから。

- VIRT: Virtual Image。確保された仮想メモリ全て。スワップしたメモリ使用量を含む。

該当のPIDの一例↓
```
29237 ec2-user   20   0 1109M  512M  9716 S 99.8  0.4
```

- Passengerが使用できるマシン上のメモリ消費率75%

### 計算式
- PassengerMaxPoolSizeを指定するにあたって計算する。
実メモリ
(124000*0.75) /512 ≒ 180
スワップ
1109Mなので、単純計算*2≒　360

- 現在の設定値：
PassengerMaxPoolSize 150

適切な値っぽいが、PassengerMaxPoolSizeがうまく作用しているとは言えない。

- プロセスとスレッドの関係。
PID:29237は1プロセスで4スレッド使用していた。![](https://i.imgur.com/TvpkgUf.jpg)


```
29237 ec2-user   20   0 1109M  512M  9716 S 99.7  0.4 28:30.35 ├─ Passenger AppPreloader: /home/websites/bapi_staff (forking...)
29252 ec2-user   20   0 1109M  512M  9716 S  0.0  0.4  0:00.02 │  ├─ Passenger AppPreloader: /home/websites/bapi_staff (forking...)
29246 ec2-user   20   0 1109M  512M  9716 S  0.0  0.4  0:00.00 │  ├─ Passenger AppPreloader: /home/websites/bapi_staff (forking...)
29245 ec2-user   20   0 1109M  512M  9716 R 100.  0.4 26:36.57 │  ├─ Passenger AppPreloader: /home/websites/bapi_staff (forking...)
18451 ec2-user   20   0 1109M  512M  9716 S  0.0  0.4  0:01.67 │  └─ Passenger AppPreloader: /home/websites/bapi_staff (forking...)
```



[参照](https://www.cc.kyushu-u.ac.jp/scp/support/faq/faq005.html)

- 該当のbapi_staffプログラムソースコードを把握していないので、適切なメモリアクセスとキャッシュを判断できない。

### 検討
- 適切なスレッドは建てられないが、消去法で少なくスレッド立てる

- Apache設定スレッドは30
```
ThreadsPerChild 30
```
- スレッドの超過に応じてプロセスが建てられる設定10のプロセス？
```
MaxClients 300
```
- PassengerMaxPoolSize
```
PassengerMaxPoolSize 180
```

- PassengerUseGlobalQueue
これが必要だと思う。
> 処理が長いリクエストの後続のキューのリクエストは、他のインスタンスキューが空いた状態になってもずっと待たされることになります。


### チューニングのポイント

- 複数の項目をチューニングする場合のポイントです。

>バックエンドの値をフロントエンドと同等かそれ以上にします。バックエンドで処理が詰まるとフロントエンドで待ち合わせやエラーが発生するためです。
例えばApacheのMaxClientsを30にしているにもかかわらず、Railsアプリケーションの最大プロセス数PassengerMaxPoolSizeを10にしている場合などです。実装に依存するかもしれませんが、topコマンドで確認したところ、Ruby on RailsのプロセスがApacheのスレッド数を超えることはありませんでした。

これがPassengerMaxPoolSize 150がうまく作用していない理由なのではないかと推測する。