改めて知っておきたいRed Hat Enterprise Linux 4 管理編第4回

ブートパラメータによるOSチューニング

それではRHEL4における基本的なOSのチューニングについて、設定ファイルとOSが提供するサービスレベルで解説します。

LinuxはOS起動時にブートパラメータと呼ばれる値をカーネルに渡すことにより、OSの挙動を変化させることが可能となっています。ハードウェアの設計仕様と密接な関係を持っているため、適切な値が設定されていないと起動に失敗したり、OSの挙動が不安定になります。したがって、値を変更する前には必ずブートパラメータに設定された値を確認しなければなりません。

ブートパラメータの確認方法を以下に示します。

# cat /proc/cmdline

	ro root=LABEL=/ rhgb quiet maxcpu=4

上記パラメータは/boot/grub/grub.confファイルでも確認することができます。

# cat /boot/grub/grub.conf

	#boot=/dev/cciss/c0d0

	default=0

	timeout=5

	splashimage=(hd0,0)/grub/splash.xpm.gz

	hiddenmenu

	title Red Hat Enterprise Linux AS (2.6.9-5.ELsmp)

	        root (hd0,0)

	        kernel /vmlinuz-2.6.9-5.ELsmp ro root=/dev/VolGroup00/LogVol00 rhgb quiet

	        initrd /initrd-2.6.9-5.ELsmp.img

	title Red Hat Enterprise Linux AS-up (2.6.9-5.EL)

	        root (hd0,0)

	        kernel /vmlinuz-2.6.9-5.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet

	        initrd /initrd-2.6.9-5.EL.img

CPUのNX保護機能に関する問題と回避策

ブートパラメータは、ハードウェアに備わっている機能とOSが持つ機能の両方に影響を与えるため、非常に重要なパラメータです。このパラメータの設定次第でOSの挙動やドライバ、アプリケーションの動作に影響を与える場合もあります。

影響を与える典型的な例には「CPUのNX保護機能に関する問題と回避策」があります。

Xeon CPUとOpteron CPUではNX保護機能が搭載されています。この機能はCPUレベルでバッファオーバフロー攻撃を防ぐもので、この機能が有効になっているとOS上で動作するドライバやアプリケーションに影響が発生しますので、CPUとOSのバージョンの両方に注意してください。

NX保護機能を搭載したCPUとOSの組み合わせで正常動作しなくなる可能性があるものとして、HPでは以下の2つを確認しています。

hpasmドライバ
Java環境を使ったアプリケーション

表5：NX保護機能を搭載したCPUとOSの組み合わせで正常動作しなくなるもの

これらの環境を使ったアプリケーションについてNX保護機能搭載のCPUとOSの組み合わせで利用する場合、カーネルパラメータを変更する必要があります。現在ではドライバやアプリケーション側でNX保護機能環境下でも動作するようにコーディングされているものがほとんどですが、もしNX保護機能に対応していないドライバやアプリケーションを利用する場合にはカーネルパラメータ変更が必要となります。

NX保護機能をRHEL4のOSのカーネルパラメータで無効にするには、以下のように/boot/grub/grub.confファイル内のkernel行にnoexec=offを記述してシステムを再起動します。

title Red Hat Enterprise Linux AS (2.6.9-5.ELsmp)

	 root (hd0,0)

	 kernel /vmlinuz-2.6.9-5.ELsmp ro root=/dev/VolGroup00/LogVol00 rhgb quiet noexec=off 

	 initrd /initrd-2.6.9-5.ELsmp.img

RHELではRHEL3 Update3(kernel 2.4.21-20.EL)から NX保護機能が装備されており、RHEL4以降も装備されています。OSが稼動している状態でNX保護機能が有効になっているかを確認するには、/var /log/dmesgファイルの中身にNXという文字列が存在するかを確認します。

# grep NX /var/log/dmesg

	NX (Execute Disable) protection: active

もしこの中に「NX (Execute Disable) protection: active」という文字列が存在する場合はNX保護機能が有効なことを示しています。

このNX保護機能はCPUのリビジョン番号とOSやドライバの設計の組み合わせに依存するため、動作障害の原因を追求することが困難になりがちです。特にハードウェアの機能に関係するような問題が発生する場合は、ハードウェア側の不良を疑ってしまいますが、実はハードウェアが備えている新機能が OSやドライバ側で未対応であるという場合によく発生するケースなのです。

この記事をシェアしてください

RHEL4におけるシステム管理とSIMについて

バックナンバー

この記事の筆者

古賀政純

日本ヒューレット・パッカード株式会社プリセールス統括本部ソリューションセンター OSS・Linux担当シニアITスペシャリスト

兵庫県伊丹市出身。1996年頃からオープンソースに携わる。2000年よりUNIXサーバーのSE及びスーパーコンピューターの並列計算プログラミング講師、SIを経験。2006年、米国ヒューレットパッカードからLinux技術の伝道師として「OpenSource and Linux Ambassador Hall of Fame」を2年連続受賞。プリセールスMVPを4度受賞。現在は、日本ヒューレットパッカードにて、Linux、FreeBSD、Hadoop、Dockerなどのサーバー基盤のプリセールスSE、文書執筆を担当。Red Hat Certified Virtualization Administrator, Novell Certified Linux Professional, Red Hat Certified System Administrator in Red Hat OpenStack, Cloudera Certified Administrator for Apache Hadoopなどの技術者認定資格を保有。著書に「Docker実践ガイド」「CentOS 7実践ガイド」「Ubuntu Server実践入門」などがある。趣味はレーシングカートとビリヤード。

古賀政純のプロフィールを見る