fstabにてディレクトリの権限、ユーザを設定するオプション

/etc/fstabの書式

 

 <file system>        <dir>         <type>    <options>             <dump> <pass>

 

オプションに

uid=1001,gid=1001,mode=0775

 

uid=1001(apache) gid=1001(apache)のとき

drwxrwxr-x apache apache のディレクトリがマウントできる。

 

 

また急にtmpfsのディレクトリ作ってと言われたら。。

ルートユーザになる

$su –

設定バックアップ

#cp –p /etc/fstab /etc/fstab.20140512

ディレクトリ作成

#cd /home/apache/

#mkdir hoge;chmod 775 hoge;chown apache:apache hoge

設定変更

#vi /etc/fstab

以下追記

none  /home/apache/hoge  tmpfs defaults,size=32m,uid=1001,gid=1001,mode=0775  0 0

 

事前確認

#df –hT

マウント

#mount –a

事後確認

#df –hT

【AWS】Default Termination Policyとは

The default termination policy uses the following steps to identify an instance to terminate:

  1. Before Auto Scaling selects an instance to terminate, it first identifies the Availability Zone that has more instances than the other Availability Zones used by the group. If all Availability Zones have the same number of instances, it identifies a random Availability Zone.

  2. Within the selected Availability Zone, it identifies the instance that was launched using the oldest launch configuration.

    Auto Scaling calls the DescribeLaunchConfiguration action on the instances in an Auto Scaling group. It then uses the time in the CreatedTime field to identify the instance with the oldest launch configuration.

  3. If more than one running instance was launched using the oldest launch configuration, it identifies the instance within that subset that is closest to the next instance hour.

    By selecting the instance that is closest to the next instance hour, Auto Scaling maximizes the hours your instances run while minimizing the billable instance-hours.

  4. If more than one instance is closest to the next instance hour, it selects a random instance from that subset.

 

１．オートスケールがターミネートするインスタンスを選択する前に、オートスケールグループが使用しているAvailabilityZoneのなかで一番多くのインスタンスを持っているZoneを特定します。もしインスタンス数がZone間で同じであるならば、ランダムでZoneが決められます。

 

２．Zoneが決まったら、最も古いローンチコンフィグファイルを使用してローンチされたインスタンスを特定します。

オートスケールはDescribe Launch Configurationを呼び出します。そしてCreateTimeフィールドの値を使用して一番古いLaunch Configを特定します。

 

３．一つ以上のインスタンスが古いローンチコンフィグを使っていたら、instace hour(課金)に最も近い部分集合を選びます。

それによって、オートスケールは最少の支払額でインスタンスのランニング時間を最大化する

 

４．一つ以上のインスタンスがinstace hour(課金)に最も近い場合、あとはランダム

 

【シェル】netstatの情報を10分間隔でとり続けるシェル

サーバでCLOSE_WAIT状態になるコネクションがあることが判明。一晩だけ、コネクションの状況を確認するためのシェルを書いた。

 

$while true;do echo -n `date` ;echo -ne "\t" ; netstat -a | greo CLOSE_WAIT | wc-l ;sleep 600 ;done  >> /tmp/netstat.log  &

[1]　6430

 

※while true ;do  ○○　;done構文　無限ループ　○○し続ける

※echo -n `date`　日付を改行なしで出力

※echo -ne "\t"　tabスペース出力

※netstat -a | greo CLOSE_WAIT | wc-l 　CLOSE_WAITの数数える

※sleep 600 600秒待つ

※ &　プロセスをバックグラウンドで実施

 

朝終わったら、プロセスID6430をkillする

$kill 6430

 

apacheの勉強した内容

ServerRoot  :Apacheのインストールされているディレクトリ

 

PidFile：デーモンのプロセス ID をサーバが記録するためのファイルを指定する

 

Timeout　：下のイベントについて、リクエストを失敗させるまでにサーバが待つ時間

・GETリクエストを受け取るのにかかる総時間

・POSTやPUTリクエストにおいて、次のTCPパケットが届くまでの待ち時間

・レスポンスを返す際、TCP の ACK が帰ってくるまでの時間

 

KeepAlive：クライアントとの接続を持続する(ON)か、1つのリクエストごとに接続を切断する(OFF)かを設定

一連のページアクセスを行うときも複数のリクエストと応答で構成されている。OFFにしておくと、一連のページアクセスの中でも接続と切断をすることになり、処理性能が悪化する。

 

MaxKeepAliveRequests　：　KeepAlive接続で許可されるリクエストの数

 

 

◆待ち受けプロセス数の調整

Apacheは複数のプロセスで動作する。それぞれのプロセスがアクセスを待ち、複数のアクセスを同時に処理できるような構造になっている。

プロセス数が多すぎるとOSがプロセスの処理するのが大変で、性能劣化

プロセス数が少なすぎると処理できるアクセスが少なる。

 

 

◆prefork

StartServers ：起動時に生成されるhttpdプロセスの数

MinSpareServers：待ち受け中のhttpdプロセスの最小個数

MaxSpareServers：待ち受け中のhttpdプロセスの最大個数

ServerLimit:

MaxClients 

MaxRequestsPerChild

 

◆# worker

ServerLimit        ：サーバプロセス数の上限値（Apache が起動できるプロセス数の上限）

ThreadLimit        ：プロセス毎のスレッド数の上限値。

StartServers       ：初期サーバ数（Apache の起動時に生成するプロセス数）

MaxClients        ：最大同時接続クライアント数（各プロセスのスレッドの合計値）

　　　　MaxClients = ServerLimit × ThreadLimit

MinSpareThreads    ：アイドルスレッド（リクエスト処理を受付られる状態のスレッド）の最小数。

MaxSpareThreads　：アイドルスレッド（リクエスト処理を受付られる状態のスレッド）の最大数   

ThreadsPerChild    ：プロセス当りのスレッド数

MaxRequestsPerChild　：子プロセスが稼働中に扱うリクエスト数の上限。

 

 

 

ExtendedStatus ：server-statusハンドラを実行する際に現在処理しているURLやリソースに関する情報も合わせて取得する。

 

 

 

sarとかKsarとか,てっとり早く知りたい人用のまとめ。

SarとかKsarとか知らない人用のメモ。

 Sarとは

各種システムのリソース消費量を、通常10分間隔(※2)、最短1分間隔で表示できます。mpstatとともにsysstatパッケージに同梱されています。取得できるデータはCPU使用率ばかりでなく、NIC, Disk, NFS等様々なデータを取得できます。

http://heartbeats.jp/hbblog/2013/10/10-commands.html

よってインストールはsyssatを行う。以下。（おそらく入ってる。確認は→yum list installed |grep sysstat）

sar (sysstat)のinstall

私の場合、yumでインストールしましたが、 sourceforgeからsrcも取得できるようです。

# yum -y install sysstat

http://sourceforge.jp/projects/freshmeat_sysstat/releases/

 

sarコマンド使うならsysstatを知らないと！

sysstatは、定期的にサーバーの情報をバイナリ（機械が処理しやすい形式）で保存する為のツールです。

sysstatで収集される情報は、CPUの負荷、ディスクI/O、メモリの使用状況、ネットワークデバイスの情報など実に多岐に渡ります。

サーバーに何らかの問題が発生したときに、その際に起きていた情報を見ることで何が原因になっているかを突き止める際に、sysstatは便利です。

sysstatは複数のコマンドで形成されています。

sa1 ： 指定の時間ごとにサーバーの情報を収集し、「saXX」ファイル（XXは日にち）を出力する

　　　　 ※ 内部的にはsadcというコマンドが読み出されて収集しています

sa2 ： sa1の統計情報ファイル（saXX）を1日の結果としてレポート（sarXXファイル）に纏め上げる

sar ： sa2で出力されたレポートを人が見て分かる形に出力する。または、リアルタイムにサーバー

　　　　情報を収集し出力する。

 

http://ameblo.jp/itboy/entry-10035725081.html

 

 sar（sysstat）は、過去のCPUなどの情報を取得できる。（実はちゃんと保存しててくれる）

「/var/log/sa」や「/var/adm/sa」などにあるsar日付ファイル

コマンド例

#cd /var/log/sa

#sar 　←その日のCPU情報が出る

#sar -f sa19 　←19日のCPU情報がでる

 

Ksarを使って、速攻でグラフ化。

過去の情報が載っているsa日付ファイルを、Ksarというソフトで展開すると一気にグラフ化してくれる。めっちゃ便利。

kSar

ダウンロードは以下

http://sourceforge.net/project/showfiles.php?group_id=179805

事前実行されているSaファイル（/var/log/sa/sa*）をファイルに吐くもしくはSarコマンドを実行してテキストに出力します。

Saファイルを出力する。（sa22をテキストに出力する場合）

# cd /var/log/sa
# LANG=C
# sar -A -f sa22 > sa22.txt

http://d.hatena.ne.jp/GARAPON/20090323/1237772247

 

cat sa22.txt sa23.txt sa24.txt  > saAll.txt

※グラフ化したい期間のsa日付.txtをcatコマンドで一つのファイルに結合する。

 

このcatAll.txtをKsarで展開してあげると3日間のグラフ化が行われる。

sarで取得できる全ての情報のグラフ化ができる。

knife-soloのインストールでつまづいたのでメモ

 

エラー内容。

vagrant@localhost ~]$ gem install knife-solo

ERROR:  While executing gem ... (Gem::FilePermissionError)

    You don't have write permissions into the /usr/lib/ruby/gems/1.8 directory.

[vagrant@localhost ~]$ sudo gem install knife-solo

Building native extensions.  This could take a while...

ERROR:  Error installing knife-solo:

ERROR: Failed to build gem native extension.

 

/usr/bin/ruby extconf.rb

mkmf.rb can't find header files for ruby at /usr/lib/ruby/ruby.h

Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/yajl-ruby-1.1.0 for inspection.

Results logged to /usr/lib/ruby/gems/1.8/gems/yajl-ruby-1.1.0/ext/yajl/gem_make.out

 

ちなみに環境は

ruby -v (ルビーのバージョン)1.8.7

gem --version(ジェムのバージョン）1.3.7

 

 

対策

sudo yum install ruby-devel