Table of Contents
1 環境
業務用の開発サーバ
項目 | スペック |
---|---|
CPU | Intel(R) Core(TM)2 Duo CPU E8400 3.00GHz |
Core数 | 2 |
Memory | 7G弱 |
OS | Red Hat Enterprise Linux Server release 5.8 (Tikanga) |
Middleware | java 1.7.0_75 |
Weblogic 10.3.5.0 | |
Oracle BPM Suite 11g (メモリを多めに割り当てた:6Gぐらい) | |
※他にものもの結構乗っている |
2 現象
- 特定のWeblogic管理対象サーバから応答が時々遅い(数秒程度)
- Full GCが起きると状況が悪化し、FullGCが終わらない
[tips][Linux]journaldエラーログをメールで通知する
systemdを採用しているdistroのシステムログがjournaldを一元管理してくれる。
ただし、journaldにエラーログを通知する機能が持っていないため監視通知のし掛けが必要で す。
- journaldログをsyslogに転送し、従来のsyslog監視方法を適用する
- 独自のスクリプトで実現する
自宅のサーバは下記スクリプトでエラーログの通知機能を実現しています。
/etc/cron.hourly/journal_error
#!/bin/sh # 一時以内のエラーログを標準出力と/var/log/journal_errorファイルへ出力する journalctl -o short-iso -p err --since -1hours 2>/dev/null | tail -n+2 | tee -a /var/log/journal_error
journalctl コマンドを駆使して1時間以内のエラーログを標準出力に出力するスクリプト。
これをcronの時間単位ジョブディレクトリ /etc/cron.hourly
に登録する。
あとはcronのメール通知機能を有効化するだけです。
cronのメール通知先は /etc/cron.d/0hourly
の MAILTO
項目にて指定する。
$ cat /etc/cron.d/0hourly # Run the hourly jobs SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=<<メールの送信先をここに書く>> 1 * * * * root run-parts /etc/cron.hourly
[まとめ]Linuxシステム時刻について
Table of Contents
Linuxシステム時刻に関わる知識やリソースのまとめです。
1 ハードウェアクロック/システムクロックの違い
クロック種別 | 説明 |
---|---|
ハードウェアクロック | * マザーボード上のICによって提供される時計です。 |
* 通常は電池でバックアップして駆動されるので、電源をお落としても時計が進みます。 | |
* RTC(Real Time Clock)、BIOS、CMOSクロックとも呼ばれる。 | |
システムクロック | * Linux カーネルの内部に存在している時計で、 タイマ割り込みによって駆動されている |
* Linux システムは起動時に一度だけハードウェア・クロックを参照し、 システム・クロックを設定する。 | |
* 精度の高いクロック、1GHz以上のCPUの場合1クロックは1ナノ秒のなります。 | |
* 時刻は1970/01/01T00:00:00からの経過時間を秒単位/ナノ秒単位で保持される。 |
ハードウェアクロック持っていないボードも存在する。RaspberryPiボードはその一つです、 RTCが必要な場合、別途RTCモジュールを導入しなければいけません。2
RaspberryPiで hwclock
コマンドでハードウェアクロックを参照すると /dev/rtc
デバイ
スがない旨のメッセージが表示された。
$ sudo hwclock --debug hwclock from util-linux 2.26.2 hwclock: cannot open /dev/rtc: No such file or directory No usable clock interface found. hwclock: Cannot access the Hardware Clock via any known method.
RaspberryPiはNTPサーバから時刻同期のし掛けが必要です。そしないとシステムクロックが POSIXにおける紀元時刻(Epoch; 1970-01-01 00:00:00 +0000 (UTC))に設定されてしまう。
[メモ]JavaBeans仕様を再認識する
Table of Contents
勉強メモ
[調査]URLパラメータデコード処理について
Table of Contents
URLパラメータの日本語文字が化けたので、APサーバのURLパラメータデコード処理について 調べました。
[メモ]デバッグ版OpenJDKのビルド
Table of Contents
今まで、JVM中身の調査は SystemTap + java-1.x.x-openjdk-debuginfo.x86_64
利用してい
たが。もう少しJVMの中身を踏み込みたいのでデバッグ版JVMをビルドしてみました。
http://hg.openjdk.java.net/jdk7/jdk7/raw-file/tip/README-builds.html の手順でビルドし
てもいいのですが、トライ・アンド・エラーで時間が取られそうなので、自分が使っている
Arch Linux
環境で一番手取りの早い手順で行いました。
[調査]JVMのスタックサイズについて
Table of Contents
1 環境
本記事の内容は以下環境を前提としています。
- GNU/Linux x86_64
- OpenJDK 64-Bit 1.7.0_xx
2 JVMのスタック領域について
-Xss
、 -XX:ThreadStackSize
パラメータ値と ulimit -s
リソースリミット制限値を混
乱している記事を見受けたため、HotSpotの中身を調べることにしました。
結論を先に、
ulimit -s
のスタック最大サイズ制限値は親プロセスであるJVMランチャーのみ適用される。- JVMランチャーやJavaAPIから起動されたJavaスレッドのスタックサイズは
-Xss
か-XX:ThreadStackSize
の値が適用される。 - JVMランチャーから起動されたイニシャルスレッドのスタックサイズは
-Xss
パラメータの み制御できる、つまり-Xss
の適用範囲は-XX:ThreadStackSize
より広い - JNI経由で外部からJVMにアタッチしたスレッドのスタックサイズはJVMの管理対象外である。
[調査]JBossASソケット受信バッファーのサイズ
Table of Contents
以下LinuxプラットフォームでJBossASアプリケーションサーバの話です。
次のケースに置いて、Acceptorスレッドやワーカスレッドの働き状態が悪くなるため、クライ アントから送信されてデータがサーバ側のTCPソケット受信バッファーに溜まる。バッファーが 一杯になるとパケット受信ができなくなる、TCPレーヤでパケット再送が起きる。
- サーバが過負荷状態でCPU時間がAcceptorスレッドやワーカスレッドに回らない場合
- FullGCによるJBossASサーバの一時停止
この記事はTCP受信バッファーのサイズの実測値を調査致します。
[メモ]JBoss ASでBytemanを使う
Table of Contents
ミドルウェアの内部動作をトレースするためによく使うので手順を残しておきます。