20190708のLinuxに関する記事は4件です。

[Oracle] SEND_BUF_SIZEとRECV_BUF_SIZE設定時のWindowサイズの変化

カーネルパラメータ

  • net.core.rmem_max
  • net.core.wmem_max

と、
sqlnet.ora(またはtnsnames.ora)に指定する以下のオプション

  • SEND_BUF_SIZE
  • RECV_BUF_SIZE

両方ともTCP受信/送信バッファの最大値を設定するパラメータとあり、SEND_BUF_SIZE/RECV_BUF_SIZEを設定する意義がわからなかったので、検証してみた。

結論からいうと、[SEND|RECV]_BUF_SIZEの設定有無にかかわらずnet.core.[r|w]membmaxを上限にWindowサイズが自動調整された。ただし、[SEND|RECV]_BUF_SIZEを指定した場合は、設定した値までWindowサイズがどんどん増加していく。net.core.[r|w]membmaxのみの場合は、ある程度のサイズで収束する。

検証環境

環境1
- OEL 6.10 (UEK4)
- DB 11.2.0.4 (環境2へDBリンク)

環境2
- CentOS 6.10
- DB 11.2.0.4
環境1と環境2の間でDBリンクを張る。環境1と環境2の間のレイテンシ(ping応答時間)は30ms程度
環境1にSQL*Plusでログインし、環境2のテーブルをDBリンクを使用してSelectする。
環境2側で、tcpdumpを取得し、Windowサイズの変化を見る。

結果

赤線が設定なし。青線がRECV_BUF_SIZEを1MBに設定。オレンジがRECV_BUF_SIZEを2MBに設定した場合のWindowサイズの変化。RECV_BUF_SIZEを設定した場合は、初期値は一緒だけど、指定した値までどんどん上昇していくのがわかる。
image.png

windowサイズは、tcpdumpのwin列に2のwscale乗をかけた値で算出。wscaleはスリーウェイ・ハンドシェイクからキャプチャしないと値を取得できないので注意

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

tailコマンドでワイルドカードを使用する

コマンド

$ tail *.log
  • 拡張子が.logのファイルをtailコマンドで表示する

出力結果

$ tail *.log
==> 2019_fuga.log <==
aaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbb
ccccccccccccccccccccccccc
ddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeee

==> 2019_hoge.log <==
aaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbb
cccccccccccccccccccccccccccc
dddddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeeeeee
  • 出力ファイルは、 ==> ファイル名 <== のように区切られて表示される
    • ==> ファイル名 <== の下に出力されたものが、そのファイルの中身

その他

  • catコマンドでも同様にワイルドカードを使用する事が可能
$ cat *.log
aaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbb
ccccccccccccccccccccccccc
ddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeee
aaaaaaaaaaaaaaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbbbbbbbbbbbbbb
cccccccccccccccccccccccccccc
dddddddddddddddddddddddddddd
eeeeeeeeeeeeeeeeeeeeeeeeeeee
  • catコマンドだと区切りが表示されない
    • catコマンドでワイルドカードはあまり使用途はなさそう

参考

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ls -la folder/. と ls -la folder/*の違い

毎回再帰処理を実装する時にググっているので備忘録程度に記録。chmodとかで権限の処理をする時とかにこういうの考える必要があったりする。

ls -la folder/.

  • カレントディレクトリのfolder自体の設定も表示される
  • folderはそのまま表示。再帰的に表示はされない
ubuntu@ip-192-168-1-209:~$ ls -la folder/.
total 12
drwxrwxr-x  3 ubuntu ubuntu 4096 Jul  8 12:22 .
drwxr-xr-x 10 ubuntu ubuntu 4096 Jul  8 12:21 ..
drwxrwxr-x  2 ubuntu ubuntu 4096 Jul  8 12:22 folder2
-rw-rw-r--  1 ubuntu ubuntu    0 Jul  8 12:22 test_cd.txt

ls -la folder/*

  • folder直下に置いてあるファイルシステムが再帰的に表示
  • カレントディレクトリのfolder自体の設定は表示されない
  • 再帰的に表示したfolderは設定も表示される
ubuntu@ip-192-168-1-209:~$ ls -la folder/*
-rw-rw-r-- 1 ubuntu ubuntu    0 Jul  8 12:22 folder/test_cd.txt

folder/folder2:
total 8
drwxrwxr-x 2 ubuntu ubuntu 4096 Jul  8 12:22 .
drwxrwxr-x 3 ubuntu ubuntu 4096 Jul  8 12:22 ..
-rw-rw-r-- 1 ubuntu ubuntu    0 Jul  8 12:22 test.txt
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

特定時間帯のgzファイルを収集しtarで固める

特定日時のログファイルを集めてtarで固めるコマンド

特定のサーバ群・日にち・時間のログファイルを取得する際の
シェルのコマンドです。

障害調査において、一つだけファイルがあれば十分ということは少なく、
同時間帯に他のサーバにも異常な出力が無かったかを確認するために
周辺のログを収集する必要があることがほとんどです。

以下の環境で特定時間帯のログを取得する

無題.png
※各srv配下には/var/log/console.logs*gzがありますが表記を割愛しています。

◆要件:2019年06月01日深夜3時台のconsole.logファイルを、サーバ1・2群の1~4号機より全て取得し、tarで固めて任意のディレクトリに格納する。

このとき、ファイルパスは以下の2か所で分岐します。
- サーバ1・2群
- サーバ1~4号機
従って、目的のファイルを全て収集するためには正規表現による
2回の範囲指定が必要となります。

ファイルパスの基本的な形は以下のようになります。
/data/[日付]/[サーバ名]/var/log/[ファイル名]

コマンドとしては、findで目的のファイルを見つけ、それをxargsで
tarコマンドに渡します。

コマンド

まずは目的の場所に目的のファイルがあるかどうかを事前に確認します。

⇒ファイル名でファイルを検索する
find /パス/ -name "ファイル名"

⇒これを今回の環境に適用
find /data/20190601/srv{1,2}a10{1,2,3,4}/var/log/ -name "console*0300.gz"
※srv1とsrv2の両方から取得したいので{}で括ってコンマで刻みます。
※101~104号機から取得したいので末尾1桁を{}で括ってコンマで刻みます。
※「.logs~日付」を指定しない全てのファイルという意味でワイルドカードを使用します(日付指定は「20190601」ディレクトリ配下である時点で不要です)。

⇒対象のログを圧縮して固める
find /data/20190601/srv{1,2}a10{1,2,3,4}/var/log/ -name "console*0300.gz" | xargs tar -cvf /var/tmp/20190601_log.tar
※オプションc:アーカイブを新規に作成する
※オプションv:処理の詳細情報を表示する
※オプションf:アーカイブファイルのファイル名を指定する

以上。
何か誤り等あれば指摘して頂けると幸いです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む