Tuning:タグのアーカイブ|ネットマーベラス(株)データアップロード詳しい開発実績など(非公開)....主要取引先(非公開)....お見積り出し(IP認証+Oauth)隠しノウハウ、隠し資料など(IP認証+Oauth)インターネット上のアクセスボリュームUPをお約束します。担当者Windowsのネットワークチューニングは幾つかの設定ポイントがあり、前回のトピックスではMTUの適正値による速度改善を行ったが今回の記事では、受信データのバッファサイズを変更して速度改善を行う方法を解説したいと思う。interfaceでコマンドの操作を行ってゆきます。このコマンドでTCPのハンドリングを行うパラーメタの一覧を最初に行い、状態の確認ができたところでパラメータを変更する手順で作業を行ってゆきましょう。この設定は変更後にリブートが必要です。dca=enabledこの設定は変更後にリブートが必要です。この設定は変更後にリブートが必要です。netdma=enabledこの設定は変更後にリブートが必要です。Updateが進まなくなった場合の対処や大型Update後のゴミ掃除。いう類の意味に近い「キーワード」を探すことでしょう。実はこの設定値を見つけて、値を大きくした所で必ずしもサーバの処理能力は向上しません。これは何故でしょうか?。サーバはあくまでもLinuxのOS上で動いているプログラムのひとつに過ぎません。答えはプログラムのリソース制限を制御するのはやはりOSのリソースに関わるカーネル設定に関係してきます。送信可能なメッセージの最大長、メッセージキューidの最大値、メッセージキューの大きさ等です。ここでは以降の内容を説明しながらチューニングの考え方を解説していきます。Descriptorと最大接続数の関係メモリの効率化DISKのチューニング最大同時接続数に関するパフォーマンスチューニング「同時接続数を増やすことの良さってなんだろう?」そう考える人もいることでしょう。この値を増やすということは、サーバからのサービスをほとんど待たずに受けられるということです。体感上、おそらくスピードが速くなったと感じる人もいるはずです。実際は速くはなっていなくても、サービスの結果が短い時間で得られるとそのような錯覚をもってしまうのです。これは、すなわち顧客満足につながる内容にほかなりません。Descriptorは、サーバに対し多くのクライアントがアクセスする際、サーバプロセスがハンドル(制御)できるコネクションの数と関わりのある重要な設定です。Descriptorと最大接続数の関係C言語でプログラムを組んだことが、ある方ならご存知のかたもいると思いますが、ファイルをオープンする際にopen関数で、最初に設定する第一引数がこれに相当します。プロセス、プログラムが複数のファイルや標準入出力をオープンし、書き込んだり、読み込んだりするのを間違えないように、区別するための識別子として使っているものです。UNIX/Windowsの特徴です。write関数を使ってデータを書き込んであげると、これが結果的に送付先にデータを送信する行為と同等となります。接続とFileDescriptorは、密接な関係にあります。FileDescriptorあり」です。これを呪文のごとく、頭に叩き込みましょう。それでは、本題のチューニングのやり方です。次の1~2はどれも同じ結果が得られます。若干使いかたがことなるので、特徴を捕まえて使用してください。/etc/rc.sysinitとか/etc/rc.localに記述すると毎回起動時に自動的に実行します。一度設定すると起動時に実行されます。コマンドラインでその場限りで値を変えるのに最適な方法です。実験の際、評価として値を色々変えてみるのには便利です。64000まめ知識(inode)今は、もう使わなくなったカーネルパラメータのチューニングに次の設定があります。inodeもディスクのディレクトリツリーの枝の本数を決める要素であるため、同時接続数が増えると、当然この値も圧迫してきます。この設定はカーネル2.2時代までは使っていましたが、2.4以降は不要です。一部のチューニングサイトの情報では、まだ根強く残っていますが、実質書いたところで全く影響はありません。/proc/sys/fs/inode-maxここで、このような設定があったことを書いてある理由ですが、やはり接続が一つ増えるとファイルも少なくとも1つ以上生成されます。この感覚は、様々なトラブルシューティングを行うフェーズで必ず役に立つはずです。メモリの効率化メモリ空間の調整)実は、あまり知られていませんがデフォルトで扱えるLinuxのメモリ管理範囲はカーネルバージョンの変遷とディストリビューションにより微妙に違いがあります。一昔前はデフォルトは880MByteとなっていました。このような場合1GByte以上のメモリを搭載しようとしたらまずカーネルをコンパイルする必要があります。下記の設定はカーネル2.4及び2.6の両方で使うことができます。上記の拡張により、搭載メモリを使いきれるようになったら、次に考えなくてはならないのは、SWAPの調整です。SWAPINGの頻度を調整することは困難でしたが、現在のカーネル2.6以降ではswapinnessを使ってswapの頻度を制御できるようになりました。swappinessに設定できる値は0~100となっています。値が大きいほどSWAPの頻度が多くなります。60で設定されていますが、256MBの搭載マシンであればデスクトップでは20以下でもよいかもしれません。仮にサーバでもマシンが使っているメモリ容量の統計をとって平均的なメモリのトップ位置を知っているなら、この値を低くして調整してみることも良いでしょう。以降にswapの頻度を変更するにあたって方法を示します。/proc/sys/vm/swappiness起動時のスクリプトに組み込んで実行するのでも良いでしょう。/etc/sysctl.confmalloc()を使ってメモリーを確保しようとする場合の挙動として、腑に落ちない点があるとお思いの方も多いと思います。/proc/meminfo」等から確認できるメモリーの空き容量を、大幅に超えて確保できてしまうという現象。システムがSWAP領域を確保している場合は当然の挙動ですが、SWAP領域を確保していないシステムでも同様の現象が発生します。値は0から100まで使用できますがこの値を小さくすることで頻度が低くなります。<br>【スレッドの調整】マルチスレッドという言葉は、かなり一般的に定着してきたので、ここではおさらい程度に解説しておきます。最近のサーバプログラムでは大半がマルチスレッド方式のプログラムであることが多くなっています。そのためサーバのチューニングを行う大前提として、OSのスレッドに関するチューニングが必要になってきます。それではマルチプロセスとマルチスレッドの挙動はどこがちがうのか考えてみましょう。マルチプロセス方式のプログラムは複数起動してもメモリの共有は行わないのです。マルチスレッドは起動したプロセスの中でスレッドと言う単位の処理でプログラムを実行し、これを並行して処理を行い、この際メモリを共有して処理を行うことができるのです。これは言い換えるとメモリ上に共通で使用するデータが存在した場合どちらが有利なのか想像できるでしょう。マルチスレッドの方が効率が良いにきまっています。起動時のオーバヘッドやメモリ空間の消費でもプロセス方式より有利と言われているため、このことより最近のサーバは軒並みスレッド方式のものが多くなっています。サーバによってはプロセス方式の方が安定しているという意見もあります。私個人の意見としてはサーバ間連携が発生する場合にお互いにマルチプロセス方式なのか、マルチスレッド方式になっているかの統一が大前提と考えています。発生するコネクションに対し相手の受けるコネクションの本数が一致していなければ結果的に失敗してしまうからです。セッション管理の仕方も関係します。2.xの二つのバージョンが現役で存在しているサーバも中にはあります。以降ではスレッドのチューニング行うにあたって必要となる関連パラメータを確認する。結局の所、スレッドの値を大きくしてもプロセスのメモリ消費量はホールドできる最大コネクション数や一プロセスあたりの共有メモリ容量の設定で総合的に考える必要があります。スレッドの根幹となるパラメータ)下記のパラメータは/proc配下のリソース値を直接書き換えるか、sysctl.confを書き換えて変更します。threads-maxshmallshmnishmmaxmsgmaxmsgmnimsgmnb【threads-maxについて】/proc/sys/kernel/threads-maxはシステム全体で扱えるスレッドの最大値を示しています。これを考える際に1プロセスあたりのスレッド最大値も理解する必要があります。要するに1プロセスで全てのスレッド数を扱えるわけではないからです。確認方法としてはglibcのソースコードをオープンしそこにコーディングされている値が1プロセスあたりのスレッドの最大値です。私が過去に経験しているケースでは一般的に1024で定義されているようです。共有メモリ空間の値を指し示しています。shmmniは1プロセスごとの共有メモリセグメント(メモリブロック)の数の上限を示しています。サーバに様々なアプリケーションが存在し共有メモリを使う際は、個々のアプリケーション毎に設定はできないので、全てのアプリケーションで網羅できるように値を設定を修正する必要がでてくるかもしれません。送信可能なメッセージの最大長、メッセージキューidの最大値、メッセージキューの大きさを指定できます。メモリオーバコミットへの対処アプリケーション開発をされている人はよく、メモリー消費に気を使って開発されている方も多いかと思いますが、C言語でプログラムを組まれている方であればよく使う関数malloc()関数の問題で悩まれるケースがあるはずです。何をいいたいのかというとmalloc()が現在の使用リソースを越えてメモリを取得しようとすることです。swapの利用があればそれも問題ないのですが、最近ではswapを使わずメモリを増やしてマシンを構成する場合もしばしばあります。こんな時でもメモリオーバコミットの現象が発生する場合があります。ここでは、このような現象に対応するための情報を提供します。対処方法)カーネルのパラメータを変更し対処を行います。100)実は、overcommit_memoryは計算されている範囲がとても微妙というか、計算範囲外部分があるためその部分も考慮に入れて設計しなくてはいけないのです。使用量にカウントされるデータセグメントヒープスタック使用量にカウントされないテキストセグメントMMUが消費するメモリkernelが消費する各種メモリバッファーキャッシュ・ページキャッシュのサイズtmpfsが消費するメモリこう考えると、かなり予測がつかなくなってきます。いってvm.overcommit_ratioに決定的な値を設定するには運用テスト等で実験して不具合がでないか何度か設定しなおしが必要なのかもしれません。下記のように仮に設定したとして話を進めていきます。下記例は計算するとわかると思いますがswapパーティションサイズでしかmalloc()お許さないということになります。vm.overcommit_memory=2確認方法は直接/proc配下のカーネルパラーメータを叩いて確認しましょう。/proc/sys/vm/overcommit_memoryちなみに、上記パラメータの設定の際どのような値を設定するべきかなのですがmanページを抜粋すると以下のように書かれています。常にオーバーコミットし、チェックしない。常にチェックし、オーバーコミットしない。してしまうリスクを引き起こす。