1プロセスが同時に開けるファイル数を増やす

■1プロセスが同時に開けるファイル数を増やす
 以前LinuxがOSとして同時に開けるファイル数を増やす手段は紹介したが、今回は1プロセスが同時に開くことができるファイル数を増やす方法のメモ。ユーザ単位の設定になるので注意。

Linuxサーバチューニングメモ
http://blog.isnext.net/issy/archives/190

 とあるパフォーマンステストを行っていたところ、プロセスが開けるファイル数を超えたというエラーが頻発したため、以下の手法で対応した。CentOSでは標準で1プロセスが同時に開けるファイル数は1024。OSのfile-maxは最近のバージョンではかなり大きな数字になっているのに、こちらの値は結構前から1024のままらしい。そこでこの値を修正する。

■現在の状態を確認する(確認したいユーザでログインすること)

  1. # ulimit -Sa
  2. core file size          (blocks, -c) 0
  3. data seg size           (kbytes, -d) unlimited
  4. scheduling priority             (-e) 0
  5. file size               (blocks, -f) unlimited
  6. pending signals                 (-i) 32621
  7. max locked memory       (kbytes, -l) 32
  8. max memory size         (kbytes, -m) unlimited
  9. open files                      (-n) 1024 ←同時ファイル数
  10. pipe size            (512 bytes, -p) 8
  11. POSIX message queues     (bytes, -q) 819200
  12. real-time priority              (-r) 0
  13. stack size              (kbytes, -s) 10240
  14. cpu time               (seconds, -t) unlimited
  15. max user processes              (-u) 32621
  16. virtual memory          (kbytes, -v) unlimited
  17. file locks                      (-x) unlimited

■一時的に同時ファイル数を増加させる(増加させたいユーザで実行)

  1. # ulimit -n 4096

■恒久的に同時ファイル数を増加させる

  1. # vi /etc/security/limits.conf
  2. root soft nofile 4096
  3. root hard nofile 4096

rootの同時ファイル数を増加したい場合上記のように追記する。

,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

CentOSサーバの負荷試験中の記録取得方法

■CentOSサーバの負荷試験中の記録取得方法
iowaitに大きな影響を与えるファイルシステムの負荷試験の最中に実マシンだけでCPUの負荷状況の記録をできるだけiowaitに影響しない形式で記録取得する方法。

CPUの稼動状況を2秒おきにn回取得する (英語で)
# LANG=C sar -u 2 n > /dev/shm/cpu.log

ロードアベレージを2秒おきにn回取得する (英語で)
# LANG=C sar -q 2 n > /dev/shm/cpu.log

取得した値をグラフツールなどで加工すればより見やすく比較できる。

tmpfs(オンメモリに書くためディスクのiowaitの影響を受けない)に書き込むため、再起動するとデータが消えてしまう。注意。メモリの少ないマシンではオススメしない。

sarコマンドは -oオプションでログを書き出すことができるが、バイナリログでサイズもかなり大きくなるので、その方法は取らず上記のやり方を選択した。

, ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (1 投票, 平均値/最大値: 5.00 / 5)
Loading...

Linuxサーバにおけるパフォーマンス高速化のための設定
CentOS5、Ubuntu、Debianで実行してみたもの。効果あった気がする。

■ディスクチューニング
参考URL
http://www.itmedia.co.jp/enterprise/articles/0707/19/news012.html
http://www.avant-tokyo.com/linux/hdparm.html

hda表示=IDE
sda表示=SCSIorSATA

sdaの場合には以下のいくつかのパラメータは無効

# hdparm -Tt /dev/hda 読み出しテスト
# hdparm -v /dev/hda パラメータ確認
# hdparm -c3 /dev/hda 32bitモード処理
# hdparm -u1 /dev/hda 割り込み処理対応
# hdparm -d1 /dev/hda DMA有効化
# hdparm -i /dev/hda HDが同時に読み込めるセクタ数
# hdparm -m16 /dev/hda 同時読み込みを16に設定
# hdparm -a1024 /dev/hda readaheadを1024に設定する
 -a128、-a256、-a512、-a1024、-a2048 測定結果のよいものを使う
# hdparm -k1 /dev/hda 設定を書き込み

■ディスク書き込みの削減
Linuxではファイルを読んだ時にもatimeを更新するため更新しない設定をすることで、書き込み量を減らす。
この設定はディスクにSSDを採用している際に特に有効。

/etc/fstabのマウントオプションとして「noatime」を指定する
# vi /etc/fstab
LABEL=/ / ext3 defaults,noatime 1 1 ←noatimeを追記

再マウントする
# mount -o remount /

mountコマンドでnoatimeが有効になっていることを確認
# mount
/dev/hda1 on / type ext3 (rw,noatime)

■I/Oスケジューラの変更
CentOS等では標準でcfqが採用されているが、データベース運用等をしている場合にはdeadlineが望ましい。

# echo deadline > /sys/block/hda/queue/scheduler
/sys/block/以下は使用しているディスクに合わせて変更

#cat /sys/block/hda/queue/scheduler
noop anticipatory [deadline] cfq ←となっていればOK。

/etc/rc.d/rc.local に以下を追記して再起動時にも適用されるようにする
echo deadline > /sys/block/hda/queue/scheduler

■プロセススワップの抑制
スワップが発生するとレスポンスが落ちるので、ファイルシステムキャッシュのためにプロセスがスワップしないよう設定を追加する。

/etc/sysctl.confに以下を追記する
vm.swappiness = 0

■/proc/sys/以下のパラメータ変更
カーネルのパラメータを修正してパフォーマンスを上げる。()内は参考値
マシン環境で最適値は異なるので試行錯誤する必要あり。

同時に開けるファイル数を増やす
/proc/sys/fs/file-max(131072)

同時スレッド数を増やす
/proc/sys/kernel/threads-max(131072)

ネットワークの送受信可能速度を上げる
/proc/sys/net/core/wmem_default(65536)
/proc/sys/net/core/wmem_max(1048576)
/proc/sys/net/core/rmem_default(65536)
/proc/sys/net/core/rmem_max(1048576)

プロセッサが一度に処理するパケット量を増やす
/proc/sys/net/core/netdev_max_backlog(4096)

tcpのtime_waitを保持できる上限を上げる
/proc/sys/net/ipv4/tcp_max_tw_buckets(131072)

利用可能な内部通信socketを増やす
/proc/sys/net/ipv4/ip_local_port_range(16384 65535)

設定を起動時に自動設定するためには以下に記述する
/etc/sysctl.conf

, , ,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (まだ評価されていません)
Loading...

 □パフォーマンスチューニングのテクニック

  ・まずは状況把握
   原因の推測のための情報収集
   各種ツールの利用
   ボトルネックをひとつづつ潰す

  ・パフォーマンス指標
   スループット
   レスポンスタイム
   スケーラビリティ
   上記の組み合わせ

  ・スロークエリログの分析
   5.1からは0.x秒単位でログ指定が可能
   頻繁に記録されるslowログから対応する
   mysqldumpslowで統計処理して見極め
   クエリアナライザの利用(高機能版mysqldumpslow)
    MySQL Enterprise Monitor + MySQL Proxy
    Proxyでクエリと統計を収集、Monitorで記録分析表示

  ・EXPLAINで解析
   遅いクエリをチェックしていく
   EXPLAIN typeでALL、index、index_subqueryが出たら注意
   key_lenが大きすぎるとNG
   indexを使っていない場合にはつけてみる
    (テーブルにindex多すぎるとかえって遅くなるので注意)
   INサブクエリは遅いので、JOINで書き直す
   EXPLAIN Extraで以下の値が出たら注意
    Using temporary:indexを使う
    Using filesort:頻発よくない複合indexを検討
    Full scan on NULL key:値によってパーテショニング検討
    Using join buffer:index使ってないところにつける

  ・show profileで解析
   処理の順番を測定し処理毎の時間を出せる
   テスト環境など別のタスクのない状況で行う
   使い方

  1.     mysql> SET profiling=1;
  2.     mysql> 解析したいクエリ実行
  3.     mysql> SHOW PROFILE;

   履歴表示

  1.     mysql> SHOW PROFILES;
  2.     mysql> SHOW PROFILE FOR 1; 何番目かの履歴
  3.     mysql> SET profiling_history_size=100; 履歴保存数設定

   表示オプション

  1.     mysql> SHOW PROFILES ALL; 全表示
  2.     CPU CPU使用率
  3.     SWAP スワップしたかしないか など

  ・show statusで統計情報表示
   show session status 現在セッションの情報表示
   show global status サーバ全体の状況
   以下のように利用する

  1.     mysql> FLASH STATUS;
  2.     mysql> SET profiling=1;
  3.     mysql> 解析したいクエリ実行
  4.     mysql> SHOW PROFILE;
  5.     mysql> SHOW SESSION STATUS;
  6.     mysql> SHOW GLOBAL STATUS;

   注意すべきパラメータ
    Create_tmp*;テンポラリ作成が多いとNG
    Handler_*;indexを使わない行アクセスが多いとNG
    Key_*:キャッシュミス率が高いときはNG
    Qcache_*:クエリキャッシュのヒット率が悪い時は無効に
    Select_*;遅いSELECTがわかる、FULL JOINが出ていたら無くす

  ・show innodb statusで分析
   CREATE TABLE innodb_monitor(a int) ENGINE INNODB; で有効
   再起動すると消える
   mysql> SHOW INNODB STATUS\G; とすると見やすい
   注意すべきパラメータ
    SEMAPHORE:ロック状況がわかる OS waitが多いとNG
    LOG:消費量がわかる
    BUFFER POOL AND MEMORY:ヒット率でサイズ調整必要
  ・クエリを書き換える
   検索条件がOR:index MergeがNG時はUNION DISTINCTで解決
   適合indexがない:マルチカラムの場合、左から順に指定必須
    1,2,3 の時 1,2と1,2,3は有効、1,3と2,3は無効
   JOINではLIMIT効かないので注意
   INサブクエリはJOINで書き直す

  ・テーブルデフラグ
   OPTIMIZE TABLEで解決
   連続データはパーテショニングしやすい(ログとか日付で連続する)
   パーテショニングしたデータはフラグメントしない、削除が高速

  ・パラメータチューニング
   innodb_buffer_pool_size;空きメモリの7割くらい割当する
    index以外もキャッシュされる
   innodb_log_file_size/innodb_log_file_in_group:INSERTが高速になる
    が128M程度でOK
   key_buffer_size:空きメモリの3割程度
    (MyISAMはindexしかキャッシュしない)
   セッションパラメータは256kbで十分 
    大きくても2Mくらいで(メモリ使いすぎる)
   
 □システム全体でパフォーマンス対策

  ・MySQLのバージョン
   5.0以上を利用する 5.0と5.1は8コアまでスケール可能(innoDB)

  ・ハードウェア
   64bitマシンを導入する(メモリ空間重要)
   ライトキャッシュ付きハードRAID推奨(キャッシュあればRAID5もOK)
   IOPSの高い構成を(SSDもあり!)

  ・OS
   64bit推奨になる
   LinuxではI/Oスケジューラに注意 noop deadline推奨
   noopはinnoDBで利用するのに適している
   I/Oキューの数値を上げる デフォルト128、10000?

  ・データベースエンジン
   innoDBはinsert bufferがあるのでログ等にも向く
   MyISAMはHDD性能に依存する 限界性能低い
    でもSSDならinnoDBより速くなる
   innoはHDDでもSSDでも限界性能があまり変化しない

  ・データベースパーテショニングを利用する
   アクセスする全てのインデックスがメモリ上にあれば高速に動作
   インデックスを細かくするためパーテショニングを使う(5.1以降必須)
   innoDBでもMyISAMでも効果がある

,
とりあえず付けておく無駄ではなかったなまぁまぁ読めたちょっと役に立ったかなかなり良かったかも (1 投票, 平均値/最大値: 1.00 / 5)
Loading...