自宅サーバをRHEL5.3にアップデートしたところ、特に問題は無かったのだけれど、いくつか変わったところと注意点が。
自分向けのメモでもあるんだけど、iSCSI Enterprise TargetのSPECファイルにはdepmod -aを実行するように書いていないので、それを修正するか新しいカーネルのリリース後、RPMパッケージをリビルドする際には忘れずに実行すること。
＃追記
depmod -Aはするようになっているけど、depmod -aはmanを見ても出てない。
module-init-tools-3.3-pre3/depmod.c
1066 switch (opt) {
1067 case 'a':
1068 all = 1;
1069 break;
1070 case 'b':
1071 basedir = optarg;
1072 skipchars = strlen(basedir);
1073 break;
1074 case 'A':
1075 maybe_all = 1;
1076 break;
1077 case 'F':
1078 system_map = optarg;
1079 break;
1080 case 'e':
1081 print_unknown = 1;
1082 break;
1083 case 'v':
1084 verbose = 1;
1085 break;
1086 case 'u':
1087 case 'q':
1088 case 'r':
1089 break;
1090 case 'C':
1091 config = optarg;
1092 break;
1093 case 'h':
1094 print_usage(argv[0]);
1095 exit(0);
1096 break;
1097 case 'n':
1098 doing_stdout = 1;
1099 break;
1100 case 'V':
1101 printf('%s %s\n', PACKAGE, VERSION);
1102 exit(0);
1103 default:
1104 badopt = argv[optind-1];
1105 }Undocumentedなのかぁ…。-Aでは役に立っていない所を見ると、SPECの%postは-aにするべきじゃないかと。
RHEL5.3のmcstransdは、同僚に手伝ってもらって自分が書いたパッチが入ったのでメモリーリークが直って、5.2でのメモリの使い方と大きな違いが(^^ゞ
5.2でSELinuxをEnforcing/Permissiveにしていると、cachedがすごいことになる。8GBのうち7GBぐらいcachedになる（そして下手するとOOM killerが走る）。これを解決するために、sysctl -w vm.drop_caches=1とかしてたんだが、5.3ではこの必要が無い。x86_64だけれど、たぶんRHEL4 x86_32の10%増しぐらいのメモリ使用量で動作しているんじゃないかと。このことはしばらくしたら某誌で書くつもり。
上の件、正確にはmcstransdのメモリーリークではないので、service mcstransd stopしてもダメ。詳細はBZ457179
mod_perlもしくはhttpdのパフォーマンスが上がったような気がする。というのはMovable Typeでエントリーを追加した時のレスポンスが心なし良くなったような。そんなことがあると思っていないので、データを取っていなかったから、どこが違うのかよく分からないけれど。Oprofileでデータを集めておくべきだったかなぁ。
