 |
1980年代～1990年代のUNIXはOSとしての性能に問題が多かった。特にハードウエアの進歩に比べてOSの性能が追随せず，アドレス空間の貧弱さやソフトウエア的なバッファ不足によってアプリケーションの性能が上がらないという問題があった。システム・エンジニアはnbufサイズやプロセステーブル・サイズなど，カーネル内のパラメータを変更し，チューンアップすることによってアプリケーションの性能を上げようと努力していた。
CやC＋＋といったコンパイル言語を駆使するプログラマは，UNIXの知識と経験が豊富である。OSの記述言語と同じ言語でアプリケーションをプログラミングしているわけだから，アプリケーションのパフォーマンスや信頼性を上げるために，OSのカーネル・パラメータを操作するのはいとも簡単なことだったのである。
一つのアプリケーションが持つことのできるファイル・ディスクリプタ数の上限，メモリー・アドレス空間にマッピング可能な最大ページ数，ネットワーク・ドライバやソケットのバッファ・サイズ，プログラムが生成できる最大スレッド数など，システムコール・オプションやアプリケーション側で操作不可能なシステム・リソースの割り当て値などを変更していた。また，カーネルではないが，ディスク入出力性能向上のため，1ブロックあたりのセクター数を変更したり，ネットワークのフレームサイズを大きくしてジャンボフレームを使えるようにしたりということもやっていた。
当時のシステム管理者，運用担当者は独自の情報源や自らの経験を基にOSのカーネルやドライバ，ハードウエア・ボード上のジャンパ設定，クロック素子の交換など，システムをカスタマイズし，やっとの思いでシステムを運用していた。ある意味，独自のカスタマイズによってシステムの問題を解決し，性能を向上させたということはそのエンジニアのノウハウであり，その当時は歓迎すべき努力と成果だったのだ。
しかし，今，小規模のシステムで限定した期間だけ稼働するアプリケーションを除くと，OSのパラメータを変更してアプリケーションを実行させることは非常に危険な実装である（図）。
 |
| 図●カーネルをチューニングすることのデメリット |
カーネル・チューニングは引き継がれない
開発と運用の分業が進み，業務用やWebサイト用のアプリケーションにかかわるプログラマとシステム・オペレータとは別人である。それぞれ別々の部署が担当する。プログラマが開発中に行ったシステムのチューンナップが正確にその意図を含めシステム・オペレータに伝えられるかどうかは保証の限りではない。また，アプリケーションを引き渡した直後であれば，プログラマとシステムを引き継いだオペレータとの間にコンセンサスが取られていたとしても，時間が経ち，プログラマ，システム・オペレータとも，該当するアプリケーション担当から離れてしまったりすることもある。元々あった開発時点の問題やその検討の結果，チューニングの意図といった事項が霧散してしまい，引き継いだプログラマやオペレータにカーネル・チューニングの意図が伝達されないことになる。何か問題があったとしても，それが元々のシステム側障害なのか，アプリケーションのバグなのか，それともチューニングによる副作用であるのかが判断しにくくなるのである。
カーネルのバージョンが変わると逆に弊害になる
ハードウエアやOSは進化していくものである。一つ前のバージョンにあった問題が次のバージョンで解決されている場合も多々ある。前のバージョンの問題点を解決するために施したカーネルのチューニングが次のバージョンでは逆に弊害となるケースも多い。
ある時点で限定されたハードウエアの性能を極限まで引き出すことを目的としてカーネルにチューニングを施すのであろうが，システムの長期的な運用，現実的な運営組織の変遷までを考慮し，継続した運用を維持するためには，カーネル・チューニングに関するドキュメンテーション作業や教育，引き継ぎ，システム管理マニュアルなどの作成を伴う。結果的に運用コストやアプリケーションのアップグレード・コストが増大する場合が多い。
このように，現在ではプログラマやオペレータがカーネル・レベルのチューニングを独自に行ってシステム・パフォーマンスを上げるという行為は，ともすれば自己満足に終わり，安易に行うと組織的，法人的にはデメリットが多くなるのである。
障害の原因にもなる
また，MTUサイズやデータリンク層のフレーム・サイズなど，インタープロセス以外の通信部分にまで変更を加えると，システムやアプリケーションだけではなく，エンドノードとの中間にあるネットワーク・デバイス次第によって通信障害を引き起こす。OSのデフォルト値は，最適な値ではなく，最も標準的な値，つまり相互互換性率が最も高い値であるという認識が必要である。
プログラマやシステム・オペレータは安易にOSをチューニングするのではなく，アプリケーションの性能向上は極力スタンダードな状態のOS上でも引き出せるよう，まずはシステム設計の見直しや，コードの最適化に注力すべきなのだ。カーネルのチューニング，ハードウエアの増強など，長期的，経済的に影響を及ぼしそうな部分に手を加える事は最終手段と認識せねばなるまい。
止むを得ずカーネルをチューニングする場合には，その根拠，評価結果，変更点に関する元々の機能，説明，変更後の効果査定結果（パフォーマンス評価）など，詳細なレポートを残さなければならないことを肝に銘じておきたい。この作業を怠ると，よかれと思って施したカーネル・チューニングが，後日大規模な障害，もしくはシステム，サービスに対して多大なるダメージを与えるかもしれない。
|
