Akira's Tech Notes

Java/JVM | GNU/Linux | Emacs/Lisp | 知的好奇心駆動

header-icon
ネイティブでない日本語で思い付くことや気になることをダラダラ書く、体裁とかは気にしない。読みづらいと感じた時に随時更新する。

[tips][Java]メモリswapによる無応答

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にエラーログを通知する機能が持っていないため監視通知のし掛けが必要で す。

  1. journaldログをsyslogに転送し、従来のsyslog監視方法を適用する
  2. 独自のスクリプトで実現する

自宅のサーバは下記スクリプトでエラーログの通知機能を実現しています。

/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/0hourlyMAILTO 項目にて指定する。

$ 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システム時刻について

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))に設定されてしまう。

[調査]URLパラメータデコード処理について

URLパラメータの日本語文字が化けたので、APサーバのURLパラメータデコード処理について 調べました。

[メモ]デバッグ版OpenJDKのビルド

今まで、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のスタックサイズについて

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ソケット受信バッファーのサイズ

以下LinuxプラットフォームでJBossASアプリケーションサーバの話です。

次のケースに置いて、Acceptorスレッドやワーカスレッドの働き状態が悪くなるため、クライ アントから送信されてデータがサーバ側のTCPソケット受信バッファーに溜まる。バッファーが 一杯になるとパケット受信ができなくなる、TCPレーヤでパケット再送が起きる。

  • サーバが過負荷状態でCPU時間がAcceptorスレッドやワーカスレッドに回らない場合
  • FullGCによるJBossASサーバの一時停止

この記事はTCP受信バッファーのサイズの実測値を調査致します。

[まとめ]JBoss as 7過負荷時TCPコネクションの振る舞い

1 前提事項

本記事は以下の環境を前提とする。

  • Linux/x86_64
  • JBoss AS 7